Re: copy constructor needed? - C# Discussion Boards

Re: Control Designer & Child Controls Issue

24-Sep-03 8:50

No, not anymore.

Did you try getting the IComponentChangeService and overriding how controls are added? There are also virtual methods on the designer classes that allow you to do this. They get called when a component is added. In your designer, override one of these methods and re-site the component. This doesn't rely on runtime code which could be the problem.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----

scott@otech.com24-Sep-03 9:02

scott@otech.com

24-Sep-03 9:02

I've tried that. This is the code I've got. Perhaps I'm doing something wrong...

<br />
  Public NotInheritable Class XPanderDesigner<br />
        Inherits System.Windows.Forms.Design.ParentControlDesigner<br />
<br />
        Private m_BorderPen As New Pen(Color.FromKnownColor(KnownColor.ControlDarkDark))<br />
        Private m_XPander As XPander<br />
        Private WithEvents m_ICCService As IComponentChangeService<br />
<br />
        Public Sub New()<br />
            m_BorderPen.DashStyle = Drawing.Drawing2D.DashStyle.Dash<br />
        End Sub<br />
<br />
        Public Overrides Sub Initialize(ByVal component As System.ComponentModel.IComponent)<br />
            MyBase.Initialize(component)<br />
            m_XPander = CType(Me.Control, XPander)<br />
        End Sub<br />
<br />
        Protected Overrides Sub OnPaintAdornments(ByVal pe As PaintEventArgs)<br />
            MyBase.OnPaintAdornments(pe)<br />
            pe.Graphics.DrawRectangle(m_BorderPen, 0, 0, m_XPander.Width - 2, m_XPander.Height - 2)<br />
<br />
        End Sub<br />
<br />
        Private Sub m_ICCSerivce_ComponentAdding(ByVal sender As Object, ByVal e As System.ComponentModel.Design.ComponentEventArgs) Handles m_ICCService.ComponentAdding<br />
            Dim b As XPanderLinkLabel<br />
<br />
            '            If TypeOf (e.Component) Is XPanderLinkLabel Then<br />
            m_ICCService.OnComponentChanging(m_XPander, Nothing)<br />
            m_ICCService.OnComponentChanging(m_XPander.pnlLinks, Nothing)<br />
            e.Component.Site = CType(m_XPander.pnlLinks, ISite)<br />
            m_XPander.pnlLinks.Controls.Add(DirectCast(e.Component, XPanderLinkLabel))<br />
            m_ICCService.OnComponentChanged(m_XPander.pnlLinks, Nothing, Nothing, Nothing)<br />
            m_ICCService.OnComponentChanged(m_XPander, Nothing, Nothing, Nothing)<br />
<br />
            '           End If<br />
        End Sub<br />
    End Class<br />

pnlLinks is the internal child control of the main user control m_Xpander that I want to be the true parent of the controls dropped onto the XPander. When I drag & drop in designmode with this code it parents the controls to the XPander, and not the internal panel of the xpander.

copy constructor needed?

berndg23-Sep-03 2:59

berndg

23-Sep-03 2:59

Recent convert from C++. Coding in C#, do I need defining copy constructors?

The documentation to Object.MemberwiseClone() suggests the answer is No, but I'd be grateful for confirmation or correction.

TIA,
Bernd

Heath Stewart23-Sep-03 3:12

23-Sep-03 3:12

Short answer: it depends.

First, there's nothing wrong with copy constructors. It's not commonly done in .NET because other, more common facilities exist (like implementing the ICloneable interface). This way, you can simply do MyObj o2 = (MyObj)o1.Clone(); (depending on whether you use a implicit or explicit interface declaration - something new to .NET). In your implementation of ICloneable.Clone, then, you can decide how to clone one object to another however you want.

Object.MemberwiseClone(), however, does a shallow copy. What this means is that all intrinsic types (int, long, bool, etc.) are copied while all reference types (almost everything else) are merely referenced by the new object and, if you change a reference type in one object it will be changed in the other. A collection is a good example: if o1 has a collection and you use Object.MemberwiseClone, then o2 will have a reference to the same collection. If you add or remove a member of that collection in either object, it will be reflected in the other because it is the same collection. If you set the collection member to null in one object, however, the other object will still hold on to a reference of it, so if you use this approach, be sure to clean everything up properly.

So, it really depends on your needs. Do you want the cloned object to have a shallow copy (i.e., a reference) of objects or a deep copy (i.e., completely different copy) where everything is a completely different object? If so, I would recommend implementing the ICloneable interface for consistency and better support, but there's nothing wrong with using a copy constructor - heck, if you want, do both! Just make use of the copy constructor in your implementation of ICloneable.

Alvaro Mendez23-Sep-03 4:43

Alvaro Mendez

23-Sep-03 4:43

Great answer Heath (got my 5).

Now, comparing these 2 lines:

MyObj o2 = (MyObj)o1.Clone(); 
MyObj o2 = new MyObj(o1);

Syntactically I'd prefer to use the second line (with the copy ctor) to copy the object. It seems clearer -- you're creating a new object based on another one.

So I ask, why bother with implementing ICloneable and overriding Clone and then having to cast the result? I guess I just don't understand what you mean by "consistency and better support" as the benefits. Do you have specific cases where implementing ICloneable is expected/required, such as for a collection class?

Thanks,
Alvaro

Hey! It compiles! Ship it.

Heath Stewart23-Sep-03 5:39

23-Sep-03 5:39

There's nothing wrong with either method, I just prefer implementing ICloneable because it's consistent with everything else in .NET and "Microsoft's way of doing things". Poke tongue | ;-P

You can actually eliminate the need for a cast by having your own Clone() method and implementing ICloneable explicitly:

public class MyClass : ICloneable
{
  // ...
  public MyClass Clone()
  {
    // Create the clone and return.
  }
  object ICloneable.Clone()
  {
    return this.Clone();
  }
}

Explicit interfaces are great in many cases, especially when you have to define a method that is defined in an interface already, or implementing two or more interfaces that may have the same members. They also come in handy for typed expressions like above. Several of your ICollection implementations in the BCL do this very thing to, at the very least, give you the appearance of a typed return and to prevent you from having to cast.

As I said, though, you could use both ways::

public class MyClass : ICloneable
{
  // ...
  public MyClass(MyClass orig)
  {
    // Create this clone from the original.
  }
  public MyClass Clone()
  {
    return new MyClass(this);
  }
  object ICloneable.Clone()
  {
    return this.Clone();
  }
}

You get the best of both worlds, then.

Another reason, which I use in a complex and abstract tree "framework" in the app I architected for work, is for treating object instances depending on what they implement. While recursing through a tree during various operations (such as cloning a tree) I determine if the object (so remember, I have no idea if a copy constructor exists for the Type without using quite a bit of reflection and many extra calls) implements ICloneable. If it does, I clone it. If it doesn't, I use a tab bit of reflection to create a new instance and do a memberwise clone (shallow copy). Most of the objects in the tree implement ICloneable, so I don't revert to reflection often and will most likely remove that functionality in a future version. The tree objects facilitate cloning by checking certain member fields for cloneability and do things in a similar matter. This creates a large chunck of functionality that never has to deal with any specific types in either the base class or the various child classes for a very nice OO design.

This is just one example where using the interface helps, but it's not required. It just depends on circumstances (checking for a copy constructor for the conditions above would be more expensive) and personal preferences (like I said, I like to remain consistent with most aspects of whatever API/framework I'm writing with/for).

Because it is so easy to do (see the second code example above), I would recommend doing both the copy ctor and implement ICloneable if you do, indeed, want to include a copy ctor. The extra IL would be trivial / negligable and it would allow for better flexibility.

Alvaro Mendez23-Sep-03 10:37

Alvaro Mendez

23-Sep-03 10:37

I'm a little alarmed about your ICloneable.Clone implementation. It just calls Clone, which would seem to indicate an endless recursive call to itself. Does putting this. in front of it tell the compiler to call the other version?

So if I have,

MyClass m1 = new MyClass();
 
m1.Clone();                        // 1
object o = m1.Clone();             // 2
MyClass m2 = (MyClass)m1.Clone();  // 3

What does each call to Clone actually end up calling?

Thanks,
Alvaro

Hey! It compiles! Ship it.

Heath Stewart23-Sep-03 10:47

23-Sep-03 10:47

First of all, I always type the implicit this. to help distinguish what's an instance member and what's a variable, just like I type the class name even for static members. It's basically just a way I manage my code. It makes absolutely NO difference when it compiles. The IL instructions are the same in either case.

Second, the seemingly self-recursive cloning: doesn't happen. Are you familiar with explicit interface implementations? Notice how I used the interface name in the last Clone method: object ICloneable.Clone()? That means that you must cast the object (or define the object reference as that interface) in order to call that particular method. In the explicit interface implementation, I called this.Clone(); which is the Clone method of my class. If I did ((ICloneable)this).Clone(), then that would definitely be a problem! That is not what I did, however. Trust me, it works.

Try throwing together a quick class that does this. Compile it and examine the IL (don't decompile - the IL is what you want to look at for this): it should show you what's being done.

You don't necessarily have to implement ICloneable as an explicit interface. I only did it because someone (might have been you - don't remember) complained that you have to cast the return value of Clone. By having another Clone method on your class that returns the proper type, you won't have to worry about it. Heck, you don't even need to implement ICloneable, but that may throw-off developers that are thinking that you implement ICloneable when, in fact, you don't (and they didn't read your documentation, which happens far too often than not).

Alvaro Mendez23-Sep-03 11:01

Alvaro Mendez

23-Sep-03 11:01

Thanks for the explanation. "Explicit interface implementation" is definitely cool. Cool | :cool:

Heath Stewart wrote:
First of all, I always type the implicit this. to help distinguish what's an instance member and what's a variable, just like I type the class name even for static members.

Yes, I do the same for instance fields (well, in Java anyway; in .NET I use the m_ prefix for my fields.) But for instance methods I think this. is just overkill. Since global methods do not exist, it's clear that calling a method directly (without a something. in front it) means you're calling a member of the class.

Regards,
Alvaro

Hey! It compiles! Ship it.

Heath Stewart23-Sep-03 13:04

Webservice over SSL with multiple servers

23-Sep-03 13:04

It's all a matter of personal preference. It certainly doesn't hurt anything (like I said, whether or not you use this, it compiles to the same IL instructions). I use it merely for code-readability...well, that I can type "this." faster than hitting Ctrl+J! Smile | :)

While I think too many "developers" (see my personal message board for comments!) rely merely on IntelliSense for their stumbling around...er, coding...it the auto-complete does come in handy for coding faster and avoiding fewer spelling errors.

Again, though, it's all a matter of personal preference. I know that this ( and Me, although I hate languages that "use me" Laugh | :laugh:

) is implicit (heck, I've been doing this a very long time) but I just personally find it easier to see what's what as I'm flying through code.

And, yes, explicit interfaces are definitely cool - sometimes even necessary (ex: interface member collisions). They can also help hide a lot of the implementation details and force developers using your library to treat your object as a specific interface rather than just your Type (hopefully forcing good OO development).

solidstore23-Sep-03 1:14

solidstore

23-Sep-03 1:14

We have four web servers each hosting our web service. We use DNS round robin to load balance across these four servers. In order to use SSL we have a certificate called for example, www.loadbalanced.com which is installed on all four machines. Things work beautifully.

However,

We now have a new internal application that needs to consume the web service over SSL but requires access to specific web servers, i.e. using they internal hostname, Unfortunely the SSL connection no longer works, I'm assuming this is because the hostname does not match the SSL certificate name. Can this be programmatically overriden? Just like clicking the security warning dialog box that appears when browsing a secure site using IE with a different hostname.

Many thanks in advance.

ps Alternative ways of depoloying the application to achieve the same affect also welcomed

Heath Stewart23-Sep-03 3:25

23-Sep-03 3:25

There doesn't seem to be any way to override it without implementing your own SSL handshaking. The fact that IE (or any web browser for that matter) allows you to do that isn't actually an accepted process since it means the certificate is not verifiable and be using an ADK to encrypt for a different server.

Now, I'm not sure about your network topology, but in our setup, the web servers sit on a DMZ and have different names internally and externally. SSL could be forced on the site for external use but not for internal use (controlled by the firewall). Since this app is internal, why not just let it talk to the servers insecurely? Heck, you don't even need a DMZ to accomplish this, it's just easier to tell IIS how to differentiate traffic in case you've set IIS up to force SSL for connections. If you haven't done this for the whole site, you don't need to do anything really. Just segment the services so that the ones your clients use are forced to SSL and the ones you use aren't. If this is an externally deployed web site, you could do the same thing but you should take a look at WS-Security to secure your services. This could even be used for client access, but puts more burden on the developers as opposed to IIS, so it isn't always desired.

solidstore23-Sep-03 3:54

solidstore

23-Sep-03 3:54

We have a similar topology with a DMZ but unfortunetly require ALL traffic to be secured with SSL (or other encryption) because of the sensitive data.
How do we 'tell IIS to differentiate traffic', do you mean set different SSL requirements on different virtual directories? what if our internal & external clients are using the same pages?
I'll have a read through WS-Security but I was hoping that IIS and ASP.NET could already handle this

Heath Stewart23-Sep-03 4:34

23-Sep-03 4:34

There are several ways you can do this. Our DMZ, for example, is on the reserved subnet 172.16. We have two IP addresses bound to it for different apps. You could, instead, bind two different IPs to each machine and have the firewall redirect to the appropriate IP based on whether or not the traffic is internal or external. Then in IIS, make two different Web apps pointing to the same directory. For the external web app, require SSL. For the internal web app, leave it as optional.

If you did use WS-Security, you could get around this by checking the remote machine's IP and and skip encryption and verification for that traffic. Again, though, this will leave you with some of the work, although WS-Security does make it easier than just using the crypto classes directly.

You may find, too, that WS-Security gives you some additional features that would be nice in your app, such as policies for requiring certain things. It will require some changes in both the client and server, but depending on your business model it may be better in the end.

The big problem is that the .NET BCL doesn't really have a way for overriding the SSL handshaking that I've ever seen. If the SSL cert doesn't verify, an exception is thrown. There doesn't seem to be a way to change that. Technically speaking, that's the way it should be (you wouldn't want to trust a certificate from the server with an ADK since that opens you up for a man-in-the-middle attack), but I can understand that it isn't always desired. Perhaps you can make a comment to the .NET team for future enhancements on the .NET section of MSDN.

Heath Stewart23-Sep-03 4:36

Re: Named Mutex (I think)

23-Sep-03 4:36

Oh, one more thing. VeriSign does offer domain certificates. I don't know exactly how they work since it's been a long time since I've looked into what they offer, but it might be worth checking out. I don't know if the certificate contains special OIDs or something, or if you can just buy bulk certificates, but each server could, potentially, be able to use different keys based on the requested Host header.

Named Mutex (I think)

James Simpson23-Sep-03 0:52

James Simpson

23-Sep-03 0:52

Hi,

If I want to serialize access to different resorces can I use a Named Mutex?

eg: I want to serialize access to a folder from different threads, can I do the following

Mutex oMutex = new Mutex(sFolderSpec);

oMutex.WaitOne()

oMutex.ReleaseMutex();

then in a different thread, have a different instance of the mutex, but with the same name

Mutex oMutex = new Mutex(sFolderSpec)
oMutex.WaitOne()

oMutex.ReleaseMutex();

I guess what I am asking is, Can I create the mutex in the function where I want the lock and dispose of it afterwards, and any other calls the same function by a different thread will lock until its released - or do I need an instance already created and accessible to each thread?

Thanks, James

James Simpson
Web Developer
imebgo@hotmail.com

Heath Stewart23-Sep-03 3:31