ARGH !!!!!
-
There is no operator= overloading in C#. ARGH !!!!!! Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
-
There is no operator= overloading in C#. ARGH !!!!!! Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
Christian Graus wrote: There is no operator= overloading in C#. ARGH !!!!!! Use a copy constructor. They both achieve the same thing I guess. Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
-
Christian Graus wrote: There is no operator= overloading in C#. ARGH !!!!!! Use a copy constructor. They both achieve the same thing I guess. Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
Nishant S wrote: Use a copy constructor. They both achieve the same thing I guess. Not quite, but actually close enough for my purposes - thanks. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
-
There is no operator= overloading in C#. ARGH !!!!!! Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
Christian Graus wrote: There is no operator= overloading in C#. ARGH !!!!!! That's to be expected because C# is modeled after Java, and the designers of Java felt that there really wasn't a need for it except in the case of strings, which they implemented as part of Java...
-
Nishant S wrote: Use a copy constructor. They both achieve the same thing I guess. Not quite, but actually close enough for my purposes - thanks. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
Woah - so C# can pass objects by value? Sorry just downloaded the SDK and I am a bit behind! Davy http://www.LateDecember.com
-
Woah - so C# can pass objects by value? Sorry just downloaded the SDK and I am a bit behind! Davy http://www.LateDecember.com
Structs are passed by value, classes by reference. I wanted operator= to do a deep copy for an internal class. But I cannot do operator= even if it was a struct. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
-
There is no operator= overloading in C#. ARGH !!!!!! Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
-
Christian Graus wrote: There is no operator= overloading in C#. ARGH !!!!!! That's to be expected because C# is modeled after Java, and the designers of Java felt that there really wasn't a need for it except in the case of strings, which they implemented as part of Java...
In Java you cannot overload any operator, not just =. That's one of the reasons I find it weaker than C++. Best regards, Alexandru Savescu
-
In Java you cannot overload any operator, not just =. That's one of the reasons I find it weaker than C++. Best regards, Alexandru Savescu
just because one thing u should not judge a lang to be weak Every body knows that nothing is as powerful C++ certainly not JAVA...
-
Structs are passed by value, classes by reference. I wanted operator= to do a deep copy for an internal class. But I cannot do operator= even if it was a struct. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
For a deep copy, the ".NET way" is to implement ICloneable or as Nish suggested, a copy constructor. I recall talking about how to implement a strongly-typed version recently in the C# forum; maybe it was in our thread about casting. Anyway, I think the reason for this is because it the assignment is actually between references not the actual class. See below for a code comparison illustrating why this is true. C#
MyClass pMC = GetMyClassPointer(); MyClass pMC2 = pMC;M/C++MyClass* pMC = GetMyClassPointer(); MyClass* pMC2 = pMC;Assignment also behaves the same with structs except that it performs a shallow copy via the MemberwiseClone method (which unfortunately cannot be overriden). James "Java is free - and worth every penny." - Christian Graus [Edit: old habits die hard, thats all I'll say about my edit :-O] -
just because one thing u should not judge a lang to be weak Every body knows that nothing is as powerful C++ certainly not JAVA...
Pankaj Singh wrote: just because one thing u should not judge a lang to be weak He didn't; he said it was one of the reasons, personally I agree with him. James "Java is free - and worth every penny." - Christian Graus
-
and no templates X| X| X| Normski. - the next bit of code is self modifying ... jmp 0xCODE
True! :rolleyes: :rolleyes: Best regards, Alexandru Savescu
-
For a deep copy, the ".NET way" is to implement ICloneable or as Nish suggested, a copy constructor. I recall talking about how to implement a strongly-typed version recently in the C# forum; maybe it was in our thread about casting. Anyway, I think the reason for this is because it the assignment is actually between references not the actual class. See below for a code comparison illustrating why this is true. C#
MyClass pMC = GetMyClassPointer(); MyClass pMC2 = pMC;M/C++MyClass* pMC = GetMyClassPointer(); MyClass* pMC2 = pMC;Assignment also behaves the same with structs except that it performs a shallow copy via the MemberwiseClone method (which unfortunately cannot be overriden). James "Java is free - and worth every penny." - Christian Graus [Edit: old habits die hard, thats all I'll say about my edit :-O]Yes, I must admit that on reflection ( no pun intended ), operator = is a bad idea, because then you'd have no idea if you were getting a shallow copy or a deep one. Tell me about ICloneable ? It returns an Object, right ? I'm still pretty annoyed about the whole const thing though. I should put it in my sig. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
-
Christian Graus wrote: There is no operator= overloading in C#. ARGH !!!!!! That's to be expected because C# is modeled after Java, and the designers of Java felt that there really wasn't a need for it except in the case of strings, which they implemented as part of Java...
Nope. operator= is a lowly shallow assignment in Java too. You're probably thinking of operator+ for string concatenation. FreeBSD is sexy. Getting closer and closer to actually submit an article...
-
Christian Graus wrote: There is no operator= overloading in C#. ARGH !!!!!! That's to be expected because C# is modeled after Java, and the designers of Java felt that there really wasn't a need for it except in the case of strings, which they implemented as part of Java...
Martin Marvinski wrote: That's to be expected because C# is modeled after Java, and the designers of Java felt that there really wasn't a need for it except in the case of strings, which they implemented as part of Java... There's no operator overloading in Java. And C# isn't only modeled after Java it has stronger roots in C++ (than Java that is)
All of my opinions are correct, even when reality makes the mistake of disagreeing with me.
ASP.NET can never fail as working with it is like fitting bras to supermodels - it's one pleasure after the next - David Wulff -
Yes, I must admit that on reflection ( no pun intended ), operator = is a bad idea, because then you'd have no idea if you were getting a shallow copy or a deep one. Tell me about ICloneable ? It returns an Object, right ? I'm still pretty annoyed about the whole const thing though. I should put it in my sig. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
Christian Graus wrote: ( no pun intended ), har har :-D Christian Graus wrote: Tell me about ICloneable ? It returns an Object, right ? The ICloneable interface has only one member;
object Clone(). However you can use a feature of the CLR/C# to hide the interface implementation so that it is only available if specifically requested, this allows you to -- among other things -- have different return types on the methods and properties required by the interface. To do this, simply prepend the name of the member with the name of the interface you are implementing. In the case of ICloneable I think it is best to implement the interface in terms of the strongly-typed version. So that is what I will do below.public class Foo : ICloneable
{
.....public Foo Clone()
{
Foo foo = new Foo();// deep copy the members return foo;}
// Doesn't need the public modifier since
// it is an interface implementation doing
// so would be redundant
object ICloneable.Clone()
{
return Clone(); // Calls Foo.Clone()
}
}Now your code will most likely call Foo's public Clone method; where-as type-generic code will first inquire about ICloneable and call its method. This is how strongly typed collections are created so that they can still implement IList et al while maintaining that the collection uses
objects when needed. James "Java is free - and worth every penny." - Christian Graus -
Yes, I must admit that on reflection ( no pun intended ), operator = is a bad idea, because then you'd have no idea if you were getting a shallow copy or a deep one. Tell me about ICloneable ? It returns an Object, right ? I'm still pretty annoyed about the whole const thing though. I should put it in my sig. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
Forgot to reply to this bit :-O Christian Graus wrote: I'm still pretty annoyed about the whole const thing though. I should put it in my sig. This has come up quite a bit on the partitioned DOTNET lists. Currently some of the MS people have been inquiring for feedback and I believe the issues with const have come up. If you check out the DOTNET-CX list archives on July 17 a thread was started about implementing const objects; perhaps something came up there to give you an idea of a work around. James "Java is free - and worth every penny." - Christian Graus