www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overloading the assignment operator, right now!

reply Georg Wrede <georg.wrede nospam.org> writes:
Overloading of the assignment operator is not allowed in D.

But no problem, we can do it right now, in spite of it.

Just overload the opCatAssign operator instead, and use ~= where = would 
be used.

This way we might gather enough use cases to really know whether it is 
good or bad in practice.

The ~= looks peculiar enough to stick in the eye, and therefore the 
chances of mixups and misunderstandings are small. Since both writing 
the overloads and using the operator are exactly the same as with the 
"real" assignment operator overload, the lessons learned are immediately 
applicable if we later want to reconsider the omission of it.

Of course, I'm not suggesting using this in published code, or example 
code! But for "private" code, this may be an interesting addition to the 
mental toolbox.

I think it is quite unusual to concatenate two "free standing" objects. 
Concatenation is only used with strings, or to join objects to arrays, 
or two arrays to each other. Therefore using this operator (as a 
substitute for the regular assignment operator) in a non-array context 
should not bring too much of a mental strain for the reader.

---

One could use any binary operator here, but it is much simpler if the 
same one is used by all programmers.
Sep 14 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:

 Overloading of the assignment operator is not allowed in D.


Overloading the assignment operator in a language where objects are 
manipulated through references would be a bit weird, wouldn't it?  It 
would almost require the creation of a new assignment operator meant 
specifically for copy semantics, similar to how we have '==' and 'is' 
for identity vs. equality comparisons.


Sean
Sep 14 2006
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:

 Georg Wrede wrote:

 Overloading of the assignment operator is not allowed in D.


 
 Overloading the assignment operator in a language where objects are 
 manipulated through references would be a bit weird, wouldn't it?  It 
 would almost require the creation of a new assignment operator meant 
 specifically for copy semantics, similar to how we have '==' and 'is' 
 for identity vs. equality comparisons.
 
 
 Sean


That might be just the right thing to do (to have a copy operator), just 
as we have those two comparison operators.

One possible prominent advantage, in terms of things that Walter likes, 
(but that others such as me and others don't care that much about) is: 
ease of porting from C++ to D.
Whereas a 'pointer to C++ class' translates easily and directly into a 
'D class', the same is not for a 'C++ class', because it is a value 
type. If the C++ class doesn't use inheritance you might just get away 
with porting it to a D struct, but that likely won't be the case. You 
will have to make a translation that is not direct, and thus bothersome 
and/or error-prone. Having such a copy operator would allow for a direct 
translation, I think.
One must be wary of what Oskar mentioned: that the assignment operator 
is not the only assignment, there is also the implicit assignment of a 
function call's argument passing. I think this can be easily solved by 
having the function call use the copy operator, if it is overloaded, for 
argument creation. Hum.., now that this is mentioned, how does it work 
in C++? Does C++ do it that way?



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 22 2006
parent Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:

 One must be wary of what Oskar mentioned: that the assignment operator 
 is not the only assignment, there is also the implicit assignment of a 
 function call's argument passing. I think this can be easily solved by 
 having the function call use the copy operator, if it is overloaded, for 
 argument creation. Hum.., now that this is mentioned, how does it work 
 in C++? Does C++ do it that way?


Pretty much.  For example:

     class C
     {
     public:
         C(int i) : x(i) {}
         C(C const& o) : x(0) {}
         int x;
     };

     void f1(C val)  { printf("%d\n", val.x); }
     void f2(C* val) { printf("%d\n", val->x); }
     void f3(C& val) { printf("%d\n", val.x); }

     C c(1); f1(c); f2(&c); f3(c);

All of the above functions pass their parameters by value (just as in D) 
but only the f1 has C as a parameter.  f2 and f3 accept a pointer and a 
reference to C, respectively.  So calling f1 will create a copy of C via 
C's copy ctor, while f2 and f3 will copy the address of C and end up 
referencing the original object.  So executing the above should print:

     0
     1
     1


Sean
Sep 22 2006
prev sibling next sibling parent J Duncan <jtd514 nospam.ameritech.net> writes:
Georg Wrede wrote:

 Overloading of the assignment operator is not allowed in D.
 
 But no problem, we can do it right now, in spite of it.
 
 Just overload the opCatAssign operator instead, and use ~= where = would 
 be used.
 
 This way we might gather enough use cases to really know whether it is 
 good or bad in practice.
 
 The ~= looks peculiar enough to stick in the eye, and therefore the 
 chances of mixups and misunderstandings are small. Since both writing 
 the overloads and using the operator are exactly the same as with the 
 "real" assignment operator overload, the lessons learned are immediately 
 applicable if we later want to reconsider the omission of it.
 
 Of course, I'm not suggesting using this in published code, or example 
 code! But for "private" code, this may be an interesting addition to the 
 mental toolbox.
 
 I think it is quite unusual to concatenate two "free standing" objects. 
 Concatenation is only used with strings, or to join objects to arrays, 
 or two arrays to each other. Therefore using this operator (as a 
 substitute for the regular assignment operator) in a non-array context 
 should not bring too much of a mental strain for the reader.
 
 ---
 
 One could use any binary operator here, but it is much simpler if the 
 same one is used by all programmers.


I agree, I have been using =~ in some cases for assignment for close to 
a year now. Its decent, and it works. And as we were discussing on #D 
one day, its ironic that a decision made by walter designed to 
un-obfuscate code might end up causing developers to implement 
work-arounds like this, resulting in MORE obfuscated code......

go figure... :)
Sep 14 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Georg Wrede wrote:

 Overloading of the assignment operator is not allowed in D.
 
 But no problem, we can do it right now, in spite of it.
 
 Just overload the opCatAssign operator instead, and use ~= where = would 
 be used.
 
 This way we might gather enough use cases to really know whether it is 
 good or bad in practice.


<snip>

Why do you have to think in C++ when coding in D?
Sep 14 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Hasan Aljudy wrote:

 Georg Wrede wrote:
 

 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it is 
 good or bad in practice.


 
 <snip>
 
 Why do you have to think in C++ when coding in D?


I don't. Do you?

Seriously, if you look back in the archives, I've been pretty voluminous 
in my support of several ideas and opinions. Getting assignment operator 
overload hasn't been one of them.

Then again, some other people have really wanted it, and I stumbled on a 
method to try it out with, which I wrote here. Now they can try it out, 
without Walter having to make changes to the language.
Sep 14 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Georg Wrede wrote:

 Hasan Aljudy wrote:
 

 Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it 
 is good or bad in practice.



 <snip>

 Why do you have to think in C++ when coding in D?


 
 <snip> 
 Then again, some other people have really wanted it,


<snip>

so my point still stands.
Sep 14 2006
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Georg Wrede wrote:

 Hasan Aljudy wrote:

 Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it 
 is good or bad in practice.


 <snip>

 Why do you have to think in C++ when coding in D?


 
 I don't. Do you?
 
 Seriously, if you look back in the archives, I've been pretty voluminous 
 in my support of several ideas and opinions. Getting assignment operator 
 overload hasn't been one of them.
 
 Then again, some other people have really wanted it, and I stumbled on a 
 method to try it out with, which I wrote here. Now they can try it out, 
 without Walter having to make changes to the language.


There is more to it than having an operator to overload. You want to be 
able to overload both assignment and copying.

Given

struct T { ... opCatAssign(T t) {...} }
void func(T t) {...}
T a,b;

You take care of

	a ~= b;

but not

	func(b);

where a copy is created too.

/Oskar
Sep 15 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Fri, 15 Sep 2006 09:57:53 +0200, Oskar Linde wrote:


 Georg Wrede wrote:

 Hasan Aljudy wrote:

 Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it 
 is good or bad in practice.


 <snip>

 Why do you have to think in C++ when coding in D?


 
 I don't. Do you?
 
 Seriously, if you look back in the archives, I've been pretty voluminous 
 in my support of several ideas and opinions. Getting assignment operator 
 overload hasn't been one of them.
 
 Then again, some other people have really wanted it, and I stumbled on a 
 method to try it out with, which I wrote here. Now they can try it out, 
 without Walter having to make changes to the language.


 
 There is more to it than having an operator to overload. You want to be 
 able to overload both assignment and copying.
 
 Given
 
 struct T { ... opCatAssign(T t) {...} }
 void func(T t) {...}
 T a,b;
 
 You take care of
 
 	a ~= b;


  Yes, with  'a.opCatAssign(b);'
 

 but not
 
 	func(b);
 
 where a copy is created too.


Are you saying that a simple struct reference in a function call just does
a shallow copy of the struct, but that sometimes you might need to do a
deep copy instead?

What about ...

  func( T x := b);

assuming for the sake of this example that ':=' is the (deep) copy
operator?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
15/09/2006 6:06:49 PM
Sep 15 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:

 On Fri, 15 Sep 2006 09:57:53 +0200, Oskar Linde wrote:
 

 Georg Wrede wrote:

 Hasan Aljudy wrote:

 Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it 
 is good or bad in practice.


 <snip>

 Why do you have to think in C++ when coding in D?


 I don't. Do you?

 Seriously, if you look back in the archives, I've been pretty voluminous 
 in my support of several ideas and opinions. Getting assignment operator 
 overload hasn't been one of them.

 Then again, some other people have really wanted it, and I stumbled on a 
 method to try it out with, which I wrote here. Now they can try it out, 
 without Walter having to make changes to the language.


 There is more to it than having an operator to overload. You want to be 
 able to overload both assignment and copying.

 Given

 struct T { ... opCatAssign(T t) {...} }
 void func(T t) {...}
 T a,b;

 You take care of

 	a ~= b;


 
   Yes, with  'a.opCatAssign(b);'
  

 but not

 	func(b);

 where a copy is created too.


 
 Are you saying that a simple struct reference in a function call just does
 a shallow copy of the struct, but that sometimes you might need to do a
 deep copy instead?
 
 What about ...
 
   func( T x := b);
 
 assuming for the sake of this example that ':=' is the (deep) copy
 operator?
 


I vote:
No for copy operators.
Specially no for the ugly and cumbersome-to-type := operator.

Yes for auto-generated copy methods/properties. (both deep and shallow)

T x = b.dup.deep;
T y = b.dup.shallow;
Sep 15 2006
next sibling parent reply Derek Parnell <derek psyc.ward> writes:
On Fri, 15 Sep 2006 20:19:48 -0600, Hasan Aljudy wrote:


 Derek Parnell wrote:

 On Fri, 15 Sep 2006 09:57:53 +0200, Oskar Linde wrote:
 

 Georg Wrede wrote:

 Hasan Aljudy wrote:

 Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it 
 is good or bad in practice.


 <snip>

 Why do you have to think in C++ when coding in D?


 I don't. Do you?

 Seriously, if you look back in the archives, I've been pretty voluminous 
 in my support of several ideas and opinions. Getting assignment operator 
 overload hasn't been one of them.

 Then again, some other people have really wanted it, and I stumbled on a 
 method to try it out with, which I wrote here. Now they can try it out, 
 without Walter having to make changes to the language.


 There is more to it than having an operator to overload. You want to be 
 able to overload both assignment and copying.

 Given

 struct T { ... opCatAssign(T t) {...} }
 void func(T t) {...}
 T a,b;

 You take care of

 	a ~= b;


 
   Yes, with  'a.opCatAssign(b);'
  

 but not

 	func(b);

 where a copy is created too.


 
 Are you saying that a simple struct reference in a function call just does
 a shallow copy of the struct, but that sometimes you might need to do a
 deep copy instead?
 
 What about ...
 
   func( T x := b);
 
 assuming for the sake of this example that ':=' is the (deep) copy
 operator?
 


 
 I vote:
 No for copy operators.
 Specially no for the ugly and cumbersome-to-type := operator.
 
 Yes for auto-generated copy methods/properties. (both deep and shallow)
 
 T x = b.dup.deep;
 T y = b.dup.shallow;


Oh I see ...  ":=" is obviously more ugly and more cumbersome than
".dup.deep". Don't know how I didn't see that.

And we would implemented as ????

  class Foo
  {
     Foo dup()
     {
         Foo deep()
         { ... }

         Foo shallow()
         { ... }
      }
  }

Amazingly simple, no?

On second thoughts, no thank you.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Sep 16 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:

 On Fri, 15 Sep 2006 20:19:48 -0600, Hasan Aljudy wrote:
 

 Derek Parnell wrote:

 On Fri, 15 Sep 2006 09:57:53 +0200, Oskar Linde wrote:


 Georg Wrede wrote:

 Hasan Aljudy wrote:

 Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.

 Just overload the opCatAssign operator instead, and use ~= where = 
 would be used.

 This way we might gather enough use cases to really know whether it 
 is good or bad in practice.


 <snip>

 Why do you have to think in C++ when coding in D?


 I don't. Do you?

 Seriously, if you look back in the archives, I've been pretty voluminous 
 in my support of several ideas and opinions. Getting assignment operator 
 overload hasn't been one of them.

 Then again, some other people have really wanted it, and I stumbled on a 
 method to try it out with, which I wrote here. Now they can try it out, 
 without Walter having to make changes to the language.


 There is more to it than having an operator to overload. You want to be 
 able to overload both assignment and copying.

 Given

 struct T { ... opCatAssign(T t) {...} }
 void func(T t) {...}
 T a,b;

 You take care of

 	a ~= b;


   Yes, with  'a.opCatAssign(b);'
  

 but not

 	func(b);

 where a copy is created too.


 Are you saying that a simple struct reference in a function call just does
 a shallow copy of the struct, but that sometimes you might need to do a
 deep copy instead?

 What about ...

   func( T x := b);

 assuming for the sake of this example that ':=' is the (deep) copy
 operator?


 I vote:
 No for copy operators.
 Specially no for the ugly and cumbersome-to-type := operator.

 Yes for auto-generated copy methods/properties. (both deep and shallow)

 T x = b.dup.deep;
 T y = b.dup.shallow;


 
 Oh I see ...  ":=" is obviously more ugly and more cumbersome than
 ".dup.deep". Don't know how I didn't see that.


Of course it's more ugly, and yes, it's more combuersome to type, even 
though it looks "shorter". Typing := involves pressing "shift" and also 
involves pressing a button that's a bit too far away from one's fingers.


 
 And we would implemented as ????


I think that's not possible in D right now, but maybe if there was 
something like:

class Foo
{
     namespace dup  //or scope dup{ .... }
     {
         Foo deep() { ... }
         Foo shallow() { ... }
     }
}


 
   class Foo
   {
      Foo dup()
      {
          Foo deep()
          { ... }
 
          Foo shallow()
          { ... }
       }
   }
 
 Amazingly simple, no?


No, it's not.


 
 On second thoughts, no thank you.
 


You're welcome.
Sep 16 2006
prev sibling parent reply pragma <ericanderton yahoo.com> writes:
Hasan Aljudy wrote:

 
 I vote:
 No for copy operators.
 Specially no for the ugly and cumbersome-to-type := operator.
 
 Yes for auto-generated copy methods/properties. (both deep and shallow)
 
 T x = b.dup.deep;
 T y = b.dup.shallow;


The only problem with this is that you can't have a compiler-generated 
deep copy without taking on some serious consequences and/or risks. 
IMO, that's too much effort for a compiler author, for a feature that is 
so limited in use and scope.

Take this guy for example:

class TreeNode{
   TreeNode parent;
   TreeNode[] children;
}

What about cyclic references in networks of objects (.parent in above)? 
  You'd have to have some kind of monitor that keeps track of all the 
references consumed by the dup.deep() process, just to avoid cycles. 
Either it's an Object field that flags its status during a dup() or a 
massive array/map that keeps log of every object touched - either one 
can amount to some very serious space/time overhead.

A stub deep copy, one that lives on Object, isn't possible either since 
D doesn't have the reflection mojo to pull it off.  Even if it did, 
would you really want to generate a deep copy of an object network 
completely via reflection?  It'd be painfully slow.

Invariably, a custom-coded clone() or dup() of some kind that allows for 
deep copying on request is the best approach - take a look at how other 
languages (e.g. Java) shy away from implementing a deep copy directly 
into the language.

class TreeNode{
   TreeNode parent;
   TreeNode[] children;

   TreeNode clone(TreeNode copyParent){
     TreeNode copy = new TreeNode();
     foreach(child; this.children){
       copy.children ~= child.clone(copy);
     }
     copy.parent = copyParent;
     return copy;
   }
}

What's wrong with doing things like this?

Now, I do think that providing a shallow-copy, dup(), as a member of 
Object is a no-brainer.  You can easily do this at the binary level via 
memcopy with little to no effort, and no real side-effects.  Plus it 
would make the current schism between objects and arrays a little less 
obvious (that is, make templates easier to code).
Sep 16 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
pragma wrote:

 Hasan Aljudy wrote:

 I vote:
 No for copy operators.
 Specially no for the ugly and cumbersome-to-type := operator.

 Yes for auto-generated copy methods/properties. (both deep and shallow)

 T x = b.dup.deep;
 T y = b.dup.shallow;


 
 The only problem with this is that you can't have a compiler-generated 
 deep copy without taking on some serious consequences and/or risks. IMO, 
 that's too much effort for a compiler author, for a feature that is so 
 limited in use and scope.
 
 Take this guy for example:
 
 class TreeNode{
   TreeNode parent;
   TreeNode[] children;
 }
 
 What about cyclic references in networks of objects (.parent in above)? 
  You'd have to have some kind of monitor that keeps track of all the 
 references consumed by the dup.deep() process, just to avoid cycles. 
 Either it's an Object field that flags its status during a dup() or a 
 massive array/map that keeps log of every object touched - either one 
 can amount to some very serious space/time overhead.
 
 A stub deep copy, one that lives on Object, isn't possible either since 
 D doesn't have the reflection mojo to pull it off.  Even if it did, 
 would you really want to generate a deep copy of an object network 
 completely via reflection?  It'd be painfully slow.
 
 Invariably, a custom-coded clone() or dup() of some kind that allows for 
 deep copying on request is the best approach - take a look at how other 
 languages (e.g. Java) shy away from implementing a deep copy directly 
 into the language.
 
 class TreeNode{
   TreeNode parent;
   TreeNode[] children;
 
   TreeNode clone(TreeNode copyParent){
     TreeNode copy = new TreeNode();
     foreach(child; this.children){
       copy.children ~= child.clone(copy);
     }
     copy.parent = copyParent;
     return copy;
   }
 }
 
 What's wrong with doing things like this?


I actually never thought about the problem. Thanks for clearing things out.


 
 Now, I do think that providing a shallow-copy, dup(), as a member of 
 Object is a no-brainer.  You can easily do this at the binary level via 
 memcopy with little to no effort, and no real side-effects.  Plus it 
 would make the current schism between objects and arrays a little less 
 obvious (that is, make templates easier to code).
Sep 16 2006
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
pragma wrote:

 Hasan Aljudy wrote:

 I vote:
 No for copy operators.
 Specially no for the ugly and cumbersome-to-type := operator.

 Yes for auto-generated copy methods/properties. (both deep and shallow)

 T x = b.dup.deep;
 T y = b.dup.shallow;


 
 The only problem with this is that you can't have a compiler-generated 
 deep copy without taking on some serious consequences and/or risks. IMO, 
 that's too much effort for a compiler author, for a feature that is so 
 limited in use and scope.
 


I don't think you cave have a compiler-generated deep copy, *at all*. At 
least for the proper notion of "deep copy".
When one speaks of a clone method, or of a "deep copy", what one means 
(or at least *should* mean), is a copy of the "abstract state" of the 
object. A *conceptual* copy of the the object.

Such "abstract state" might not coincide with the set of *all* 
objects/members that can be reached recursively from the target object. 
There might be members that are simply not part of the object's abstract 
state.
For example, consider some GUI Button widget class that has a member 
which is a reference to it's parent widget. If I want to clone/deep-copy 
this Button widget, should it clone it's parent widget too, and possibly 
the whole encompassing window?
Similar example: a Shape class, which would have a list of vertexes, 
color, position and a reference to a Renderer which is used for drawing. 
When a Shape is cloned, should all members be cloned, in particular the 
Renderer member as well? Likely not, because it is not part of the 
abstract state of Shape.

This notion of abstract state was actually picked up in that paper about 
Javari (immutability for Java), as some might have noticed. ;)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 22 2006
parent Kristian <kjkilpi gmail.com> writes:
On Sat, 23 Sep 2006 01:03:25 +0300, Bruno Medeiros  =

<brunodomedeiros+spam com.gmail> wrote:

 pragma wrote:

 Hasan Aljudy wrote:

 I vote:
 No for copy operators.
 Specially no for the ugly and cumbersome-to-type :=3D operator.

 Yes for auto-generated copy methods/properties. (both deep and shall=






ow)

 T x =3D b.dup.deep;
 T y =3D b.dup.shallow;


  The only problem with this is that you can't have a compiler-generat=




ed  =


 deep copy without taking on some serious consequences and/or risks.  =





 IMO, that's too much effort for a compiler author, for a feature that=




  =


 is so limited in use and scope.


 I don't think you cave have a compiler-generated deep copy, *at all*. =


At  =


 least for the proper notion of "deep copy".
 When one speaks of a clone method, or of a "deep copy", what one means=


  =


 (or at least *should* mean), is a copy of the "abstract state" of the =


 =


 object. A *conceptual* copy of the the object.


[snip]


I agree. The compiler cannot know the abstract states of objects. Human =
 =

can make very good assumptions or guesses, but I think that one still ha=
ve  =

to look at the documentation to be 100% sure, in a general case at least=
.

So, you have to implement clone methods by yourself, which can be a lot =
of  =

work. I guess this is one of the reasons that objects in D are reference=
  =

types. Of course, nothing prevents you to implement clone functions by  =

yourself, but used in common 'calculations', it's cumbersome. Well,  =

sometimes you could use structs instead of classes, but not always. One =
 =

solution could indeed be a copy operator (which should be easy to type; =
 =

suggestions?). The copy operator would simply call the clone method if i=
t  =

exists.

But, copying value types around can be time consuming, though. For  =

example, in C++:

class HugeMatrix;

HugeMatrix func() {
     HugeMatrix a, b, c, d;
     ...
     d =3D (a + b) - c;
     ...
     return d;
}

'HugeMatrix' gets copied four times. Using references (as in D):

HugeMatrix func() {
     HugeMatrix a, b, c;
     ...
     d =3D (a.clone().add(b)).sub(c);
     ...
     return d;
}

copying is done only once. It's efficient, but not pretty.

Of course, one could use lazy copying in C++, but that cannot be  =

automatically implemented by the compiler. (Well, I remember reading a  =

paper where C++ templates were used in a bizarre way to get rid of  =

creating unnecessary temporaries in such calculations... where I put it.=
..)


Could it be possible that the compiler would do the following conversion=
:

"d =3D (a + b) - c;"
->
"d =3D (a.opClone().opAdd(b)).opSub(c);"

'd' would be marked as 'copyable object' in the class declaration, or  =

something, so that compiler will know that the 'opClone()' should be  =

called in such situations.
Sep 23 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 14 Sep 2006 17:30:29 +0300, Georg Wrede wrote:


 Overloading of the assignment operator is not allowed in D.
 
 But no problem, we can do it right now, in spite of it.


I'm happy to not have the assignment operator overloaded in D.

I'm unhappy that D doesn't have a copy operator. If it did, I'd like to
overload that!

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
15/09/2006 11:25:23 AM
Sep 14 2006
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Derek Parnell wrote:

 On Thu, 14 Sep 2006 17:30:29 +0300, Georg Wrede wrote:
 

 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.


 
 I'm happy to not have the assignment operator overloaded in D.


For classes I agree. Overloading reference assignment doesn't make much 
sense. For structs on the other hand, assignment means (shallow) copying 
and being able to define that behavior would be useful.


 
 I'm unhappy that D doesn't have a copy operator. If it did, I'd like to
 overload that!


But in a way it does have one such operator. I am thinking about []=.

struct Matrix {
	T* ptr;
	size_t w,h;
	...
	Matrix opSliceAssign(Matrix b) {...}
}

Matrix a,b;
...

a=b;   // Makes a refer to the same memory as b
a[]=b; // Copies the contents of b to a

/Oskar
Sep 15 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Fri, 15 Sep 2006 09:43:07 +0200, Oskar Linde wrote:


 Derek Parnell wrote:

 On Thu, 14 Sep 2006 17:30:29 +0300, Georg Wrede wrote:
 

 Overloading of the assignment operator is not allowed in D.

 But no problem, we can do it right now, in spite of it.







  ...

 I'm unhappy that D doesn't have a copy operator. If it did, I'd like to
 overload that!


 
 But in a way it does have one such operator. I am thinking about []=.
 
 struct Matrix {
 	T* ptr;
 	size_t w,h;
 	...
 	Matrix opSliceAssign(Matrix b) {...}
 }
 
 Matrix a,b;
 ...
 
 a=b;   // Makes a refer to the same memory as b
 a[]=b; // Copies the contents of b to a


This is still a workaround though as it doesn't really work for arrays
(it's just a shallow copy and you can't overload it), and doesn't work for
scalars (bad syntax).

However, a new operator that can be used with all types and can be
overloaded for structs, and classes would be a much better alternative,
especially with generic coding (templates/mixins) in mind.

Hopefully Walter will 'see the light' and schedule this useful concept into
v2 ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
15/09/2006 5:50:16 PM
Sep 15 2006