www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Copy constructor in D. Why it is necessary to have it.

reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
http://www.everfall.com/paste/id.php?m46jrb36o7qu

This is a short example. It has all the comments inside. Since "in" keyword
tells the compiler to make a copy of an class object - a new object is created.
But constructor for this object is not called(you can check it). In my opinion
it is a big issue and needs to be improved.
Sep 30 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 30 Sep 2008 23:37:50 +0400, Eldar Insafutdinov  
<e.insafutdinov gmail.com> wrote:

 http://www.everfall.com/paste/id.php?m46jrb36o7qu

 This is a short example. It has all the comments inside. Since "in"  
 keyword tells the compiler to make a copy of an class object - a new  
 object is created.
No, that's not true. No heap activity is done under the hood, a copy of /pointer/ is passed (as opposed to a copy of /instance/). In means that changes to the variable won't be visible to the caller: void foo(in TreeIter it) { it = null; // makes local change } An important thing to note is that `in` is not recursive (as const or invariant).
 But constructor for this object is not called(you can check it). In my  
 opinion it is a big issue and needs to be improved.
No, it shouldn't generate heap activity unless really needed. In this case do the following: void foo(const(TreeIter) it) { auto itCopy = it.clone(); // do whatever you wish with a copy. } But in general, a const reference should be enough to you.
Sep 30 2008
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Denis Koroskin Wrote:

 On Tue, 30 Sep 2008 23:37:50 +0400, Eldar Insafutdinov  
 <e.insafutdinov gmail.com> wrote:
 
 http://www.everfall.com/paste/id.php?m46jrb36o7qu

 This is a short example. It has all the comments inside. Since "in"  
 keyword tells the compiler to make a copy of an class object - a new  
 object is created.
No, that's not true. No heap activity is done under the hood, a copy of /pointer/ is passed (as opposed to a copy of /instance/). In means that changes to the variable won't be visible to the caller:
In my particular case changes are made to the data behind the pointer - and they are not copied because, only pointer itself is copied. In C++ when you call a function like this: foo(TClass instance); copy constructor is called to create a proper copy of an object. "in" keyword means exactly the same I guess? it makes a local copy of an object, so that variable is not supposed to be modified. But in my case since I use a binding to a C-library - the real data is behind the pointer. foo() cannot modify the class fields themself, but since pointer both in variable and local copy point to the same data - the semantics of "in" doesn't work.
     auto itCopy = it.clone();
Why copy it manually if language tends to do it so by providing appropriate keyword. I should only write a copy constructor for my data and let to do the rest to the compiler.
Sep 30 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Eldar Insafutdinov:
     auto itCopy = it.clone();
Why copy it manually if language tends to do it so by providing appropriate keyword. I should only write a copy constructor for my data and let to do the rest to the compiler.
In D all objects are managed by reference. So when you copy automatically, you are just copying its reference, that's a pointer fully managed by the GC. If you want a copy of the data of an object you ask so to it. This simplifies collections and reduces the number of copies, improving performance. Instead of "clone()" I suggest "dup", that's the standard in D. Bye, bearophile
Sep 30 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to bearophile,

 Eldar Insafutdinov:
 
 auto itCopy = it.clone();
 
Why copy it manually if language tends to do it so by providing appropriate keyword. I should only write a copy constructor for my data and let to do the rest to the compiler.
In D all objects are managed by reference.
BTW note that structs ARE pass by value.
Sep 30 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 1, 2008 at 5:34 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Eldar Insafutdinov:
     auto itCopy = it.clone();
Why copy it manually if language tends to do it so by providing appropriate keyword. I should only write a copy constructor for my data and let to do the rest to the compiler.
In D all objects are managed by reference. So when you copy automatically, you are just copying its reference, that's a pointer fully managed by the GC. If you want a copy of the data of an object you ask so to it. This simplifies collections and reduces the number of copies, improving performance. Instead of "clone()" I suggest "dup", that's the standard in D.
It has been pointed out though, that dup is a "shallow copy" in D's built-in usage. If you want a deep copy operation, there is no precedent in the base language, I believe. Clone is a good one to standardize on for deep copies, I think. --bb
Sep 30 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 It has been pointed out though, that dup is a "shallow copy" in D's
 built-in usage.  If you want a deep copy operation, there is no
 precedent in the base language, I believe.  Clone is a good one to
 standardize on for deep copies, I think.
I see. Probably the more readable & intuitive names are "copy" and "deepcopy". But "dup" is already present, so it has to be accepted, I presume. What about "deepdup" for the deep version instead? :-) It's more easy to remember its meaning (and I presume it's not that commonly used to deserve a very short name). Bye, bearophile
Sep 30 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 1, 2008 at 5:55 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Bill Baxter:
 It has been pointed out though, that dup is a "shallow copy" in D's
 built-in usage.  If you want a deep copy operation, there is no
 precedent in the base language, I believe.  Clone is a good one to
 standardize on for deep copies, I think.
I see. Probably the more readable & intuitive names are "copy" and "deepcopy". But "dup" is already present, so it has to be accepted, I presume. What about "deepdup" for the deep version instead? :-)
Heh, made me think .deeppoop when I first saw that.
 It's more easy to remember its meaning (and I presume it's not that commonly
used to deserve a very short name).
I like clone. It's used pretty commonly in other languages. I'd rather not follow up one slightly odd-ball name with an even more bizarre one. But it's not gonna be anything more than a convention anyway, so you're free to name it .deepdup if you like in your libraries. --bb
Sep 30 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 I like clone.  It's used pretty commonly in other languages.
Java?
 I'd rather not follow up one slightly odd-ball name with an even more
 bizarre one.  But it's not gonna be anything more than a convention
 anyway, so you're free to name it .deepdup if you like in your
 libraries.
If the D convention is clone I'll use clone! :-) Using different conventions is generally bad. Bye, bearophile
Sep 30 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 1, 2008 at 6:53 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Bill Baxter:
 I like clone.  It's used pretty commonly in other languages.
Java?
I've seen it used in C++ libs too.
 I'd rather not follow up one slightly odd-ball name with an even more
 bizarre one.  But it's not gonna be anything more than a convention
 anyway, so you're free to name it .deepdup if you like in your
 libraries.
If the D convention is clone I'll use clone! :-) Using different conventions is generally bad.
There is no real convention at this point. Has anyone seen a D library that contains a way to make deep copies of its objects? --bb
Sep 30 2008
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:
 On Wed, Oct 1, 2008 at 5:55 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Bill Baxter:
 It has been pointed out though, that dup is a "shallow copy" in D's
 built-in usage.  If you want a deep copy operation, there is no
 precedent in the base language, I believe.  Clone is a good one to
 standardize on for deep copies, I think.
I see. Probably the more readable & intuitive names are "copy" and "deepcopy". But "dup" is already present, so it has to be accepted, I presume. What about "deepdup" for the deep version instead? :-)
Heh, made me think .deeppoop when I first saw that.
 It's more easy to remember its meaning (and I presume it's not that commonly
used to deserve a very short name).
I like clone. It's used pretty commonly in other languages. I'd rather not follow up one slightly odd-ball name with an even more bizarre one. But it's not gonna be anything more than a convention anyway, so you're free to name it .deepdup if you like in your libraries. --bb
I use .clone also, but the difference in meaning between .clone and .dup may not be clear enough to say the former is a deep copy but the latter is shallow. Ouch, but we have invariant vs const already, so maybe it's OK. /sarcasm
Oct 01 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 But it's not gonna be anything more than a convention
 anyway, so you're free to name it .deepdup if you like in your
 libraries.
We've been informally calling it "deepdup". The advantage of that is it is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
Oct 01 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 We've been informally calling it "deepdup". The advantage of that is it 
 is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone". On the other hand there are some name changes that can improve D2: 1) invariant => immutable 2) .length => .size 3) .dup => .copy 4) .deepdup => deepcopy 1 and 2) are surely improvements. 3) "dup" is used quite commonly, so it deserves a short name, but "copy" is just one character longer, it isn't an abbreviation, and it's more readable, so I think it's not bad. And 4) is just the natural extension of the name 3). It doesn't deserve a very short name because it's not used often, so it's better to make it as readable as possible. Bye, bearophile
Oct 01 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"bearophile" wrote
 Walter Bright:
 We've been informally calling it "deepdup". The advantage of that is it
 is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone". On the other hand there are some name changes that can improve D2: 1) invariant => immutable
Yes
 2) .length  =>  .size
No. Size can imply the memory size, so an array of ints, I might expect size to return 4*length.
 3) .dup  =>  .copy
either works for me.
 4) .deepdup  =>  deepcopy
either works for me.
 3) "dup" is used quite commonly, so it deserves a short name, but "copy" 
 is just one character longer, it isn't an abbreviation, and it's more 
 readable, so I think it's not bad.
character length is not as important as clarity, but dup seems pretty clear to me. If it were copy vs. duplicate, I'd go with copy for brevity, but either is fine. -Steve
Oct 01 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
bearophile wrote:
 Walter Bright:
 We've been informally calling it "deepdup". The advantage of that is it 
 is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone".
Everyone has a different opinion :-)
 On the other hand there are some name changes that can improve D2:
 1) invariant  =>  immutable
Seconded.
 2) .length  =>  .size
No. To me, 'size' should return the number of bytes of something, not the number of elements. 'length' is appropriate for what's being returned.
 3) .dup  =>  .copy
.dup is fine as is, and I think it should always perform a deep copy. With D going the direction it is, shallow copies are of limited use and can therefore be called .shallow or something.
 4) .deepdup  =>  deepcopy
Invalid, assuming #3 above. Sean
Oct 01 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 01 Oct 2008 10:23:40 -0700,
Sean Kelly wrote:
 3) .dup  =>  .copy
.dup is fine as is, and I think it should always perform a deep copy. With D going the direction it is, shallow copies are of limited use and can therefore be called .shallow or something.
Deep copy is not possible without knowing the object structure. How about opDup? :)
Oct 02 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 5:51 AM, Sergey Gromov <snake.scaly gmail.com> wrote:
 Wed, 01 Oct 2008 10:23:40 -0700,
 Sean Kelly wrote:
 3) .dup  =>  .copy
.dup is fine as is, and I think it should always perform a deep copy. With D going the direction it is, shallow copies are of limited use and can therefore be called .shallow or something.
Deep copy is not possible without knowing the object structure. How about opDup? :)
How would that differ from a function called dup? Anyway, copying objects is definitely another place D's story is a little weak. The class/struct distinction does relieve some of the pressure, but eventually you will run into situations where you want to copy an object. In my code I've been creating polymorphic copy(Type obj) functions that copy from obj to this. Then implementing dup in terms of copies like: Type dup() { ret = new Type; ret.copy(this); return ret; } The language could potentially help by automating some of that and calling an opCopy automatically when "dup" is invoked. But the above isn't terribly onerous. Just to be explicit about my understanding of the issues: The basic problem with just having a dup() is that if Deriv derives from Base and both implement dup, there's no way for Deriv's dup to use Base's dup. Both will try to allocate a whole object of their own type. So dup can't usefully be extended using virtual functions. A copy function can, though. void Deriv.copy(Deriv obj) { // copy from objs fields this.xxx = obj.xxx ; // copy super's fields super.copy(obj); } Copying and construction in C++ always seems to be good topics for tricky interview questions, so there's likely more involved than what I've just said. --bb
Oct 02 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:
 Deep copy is not possible without knowing the object structure.  How 
 about opDup?  :)
An opCopy() / opDeepcopy looks useful (not opDup because in D special names are named about their meaning and not their syntax). In Python there are the standard special methods __copy__ and __deepcopy__ for that purpose (during deepcopying the system takes care of eventually present loops, this will be important in D too). Related to the copy, a opGetstate() / opSetstate() may be useful to serialize / deserialize objects on disk. In Python they of named __setstate__ / __getstate__, when they are present the pickle function uses them, otherwise it just reads/writes all the object attributes. Bye, bearophile
Oct 02 2008
prev sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
You have a procedural mind, Bearophile ;-)

"bearophile" <bearophileHUGS lycos.com> skrev i meddelelsen 
news:gbvmgr$19tu$1 digitalmars.com...
 Walter Bright:
 We've been informally calling it "deepdup". The advantage of that is it
 is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone". On the other hand there are some name changes that can improve D2: 1) invariant => immutable 2) .length => .size 3) .dup => .copy 4) .deepdup => deepcopy 1 and 2) are surely improvements. 3) "dup" is used quite commonly, so it deserves a short name, but "copy" is just one character longer, it isn't an abbreviation, and it's more readable, so I think it's not bad. And 4) is just the natural extension of the name 3). It doesn't deserve a very short name because it's not used often, so it's better to make it as readable as possible. Bye, bearophile
Oct 01 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bent Rasmussen:
 You have a procedural mind, Bearophile ;-)
Is this a good or bad thing? :-) Bye, bearophile (lowercase)
Oct 01 2008
parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
I'm talking out of my ass, as superdan would say, Bearophile*. Although your 
preferred names sound a "tad" more "procedural" to me. Ass-talking "off" :-)

- bent*

* It's a variable name!

"bearophile" <bearophileHUGS lycos.com> skrev i meddelelsen 
news:gc0pcp$1rqq$1 digitalmars.com...
 Bent Rasmussen:
 You have a procedural mind, Bearophile ;-)
Is this a good or bad thing? :-) Bye, bearophile (lowercase)
Oct 02 2008
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Nobody liked my ".dupofearl" idea.
Why? :( Nothing can stop the .dupofearl ... -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Oct 01 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 2, 2008 at 7:48 AM, Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:
 Walter Bright wrote:
 Nobody liked my ".dupofearl" idea.
Why? :( Nothing can stop the .dupofearl ...
I think it's because it was too hard to tell if it was dup-of-earl or dup-o-fear---l. Beware! The Dup 'o Fear..l awaits you all with nasty big pointy teeth. --bb
Oct 01 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Thu, Oct 2, 2008 at 7:48 AM, Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:
 Walter Bright wrote:
 Nobody liked my ".dupofearl" idea.
Why? :( Nothing can stop the .dupofearl ...
I think it's because it was too hard to tell if it was dup-of-earl or dup-o-fear---l. Beware! The Dup 'o Fear..l awaits you all with nasty big pointy teeth. --bb
And when I dup you You will be my Duped, deep-duped of Earl We'll walk through my dupdom And the bits we will share
Oct 02 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 On Thu, Oct 2, 2008 at 7:48 AM, Tom S 
 <h3r3tic remove.mat.uni.torun.pl> wrote:
 Walter Bright wrote:
 Nobody liked my ".dupofearl" idea.
Why? :( Nothing can stop the .dupofearl ...
I think it's because it was too hard to tell if it was dup-of-earl or dup-o-fear---l. Beware! The Dup 'o Fear..l awaits you all with nasty big pointy teeth. --bb
And when I dup you You will be my Duped, deep-duped of Earl We'll walk through my dupdom And the bits we will share
Wow! You may not have a beard/mustache ( http://www.alenz.org/mirror/khason/why-microsoft-can-blow-off-with-c.html ), but D is destined to succeed simply because your nerdiness level beats everyone ;) Too bad you couldn't come to the Tango Conference... -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Oct 02 2008
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
bearophile Wrote:

 Eldar Insafutdinov:
     auto itCopy = it.clone();
Why copy it manually if language tends to do it so by providing appropriate keyword. I should only write a copy constructor for my data and let to do the rest to the compiler.
In D all objects are managed by reference. So when you copy automatically, you are just copying its reference, that's a pointer fully managed by the GC. If you want a copy of the data of an object you ask so to it. This simplifies collections and reduces the number of copies, improving performance. Instead of "clone()" I suggest "dup", that's the standard in D. Bye, bearophile
Ah ok, so when using "in" with class objects - it means that I can't modify the reference itself. So no copy occured. I was wrong.
Sep 30 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 1, 2008 at 6:01 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 bearophile Wrote:

 Eldar Insafutdinov:
     auto itCopy = it.clone();
Why copy it manually if language tends to do it so by providing appropriate keyword. I should only write a copy constructor for my data and let to do the rest to the compiler.
In D all objects are managed by reference. So when you copy automatically, you are just copying its reference, that's a pointer fully managed by the GC. If you want a copy of the data of an object you ask so to it. This simplifies collections and reduces the number of copies, improving performance. Instead of "clone()" I suggest "dup", that's the standard in D. Bye, bearophile
Ah ok, so when using "in" with class objects - it means that I can't modify the reference itself. So no copy occured. I was wrong.
In D1 'in' is a no-op. It just means pass the parameter normally. Which for classes means you're actually passing a pointer/reference to the class. I've done very little with D2, but in D2 I think 'in' on a parameter means 'const'. Or maybe "const final". --bb
Sep 30 2008