Taking a copy of an object

Dave Dave_member at pathlink.com
Fri Aug 4 11:44:00 PDT 2006


kris wrote:
> Dave wrote:
>> kris wrote:
>>
>>> Dave wrote:
>>>
>>>> kris wrote:
>>>>
>>>>> Derek Parnell wrote:
>>>>>
>>>>>> On Thu, 03 Aug 2006 23:47:47 -0700, kris wrote:
>>>>>>
>>>>>>
>>>>>>> Does deep-copy really need an operator? I have to wonder whether 
>>>>>>> a simple naming-convention would do the trick instead  ... that 
>>>>>>> way, you'd never have a /default/ deep-copy, and usage mistakes 
>>>>>>> would produce a most welcome compile-time error.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not asking for a default deep copy. If you haven't defined one 
>>>>>> then its
>>>>>> a compile time error. How would a function/method work with arrays 
>>>>>> as .dup
>>>>>> only does a shallow copy. And how would it work in templates that 
>>>>>> use basic
>>>>>> types? An operator overcomes these issues by letting the compiler 
>>>>>> know what
>>>>>> the coder's intentions are and generate code accordingly. 
>>>>>
>>>>>
>>>>>
>>>>> True. If I have an array of char*, an array of class refs, or 
>>>>> something similar, and want a deep copy, then an operator might be 
>>>>> a fair option. But so would the ability to add methods to arrays 
>>>>> (for example), which would be far more powerful (and competitive 
>>>>> with C#) than one specific deep-copy facility.
>>>>>
>>>>> On the other hand, one has to wonder how often deep copy is 
>>>>> actually used? In 22 years of paid R&D (pretty much across the 
>>>>> spectrum too) I can recall using deep-copy perhaps less than half a 
>>>>> dozen times? As operations go, it's typically a rather expensive 
>>>>> one. Most folk seem to try and find a way around that instead? 
>>>>> Certainly it might be nice to have, but is it really more important 
>>>>> than, say, fixing static-arrays?
>>>>>
>>>>> You didn't say that, or rank deep-copy in any way, but one has to 
>>>>> wonder?
>>>>>
>>>>>
>>>>> All that aside, .dup() is still a better approach for shallow copy :)
>>>>
>>>>
>>>>
>>>> With all that in mind - if .dup was given an op overload for classes 
>>>> and structs, couldn't that then be used to do the deep copy when it 
>>>> was imperative?
>>>>
>>>> For example:
>>>>
>>>> class C // built-in .dup copies i and the reference to str
>>>> {
>>>>     int i;
>>>>     char[] str;
>>>> }
>>>>
>>>> class D // .dup is overloaded to do a default shallow and optional 
>>>> deep copy
>>>> {
>>>>     int i;
>>>>     char[] str;
>>>>     C opDup(bool deep = false)
>>>>     {
>>>>         C c = new C;
>>>>         c.i = this.i;
>>>>         if(deep)
>>>>             c.str = this.str.dup;
>>>>         else
>>>>             c.str = this.str;
>>>>         return c;
>>>>     }
>>>> }
>>>>
>>>> - Dave
>>>
>>>
>>>
>>> The issue I see, mixing deep & shallow copy like this, is that misuse 
>>> would have to be noted at runtime rather than at compile-time?
>>
>>
>> Yea that's a drawback. Just trying to figure out how things could be 
>> done with '.dup' and I was thinking along the lines of deep copy not 
>> being used all that often (so it could just be built into an opDup 
>> overload and always made intentional). Or if the class developer 
>> always intended a deep copy for some reason then they could just code 
>> that as well.
> 
> Aye. But does it cover Derek's concern of deep-copy for arrays and so 

Nope <g>

> on? I suppose one argument could be that since deep-copy seems to be 
> fairly rare, it's perhaps not really an issue to wrap the entity in an 
> aggregate ;)
> 

I would say - everytime I've seen 'deep' copies done on the elements of an array of objects there's 
some sort of iterator and loop involved. But of course that's with C++ that doesn't have any notion 
of .dup built in.

> Seems like the two are sufficiently different in terms of both meaning 
> and usage patterns; perhaps they should be isolated?
> 

I guess so, especially if you wanted to build something that would recurse through elements, like:

MyObject[] array;
...
array.dup;  // would .dup the array and call .dup on each element. Hmmm, how to copy just the array?
array.deep; // would .dup the array and call .deep on each element.

Something like that?

(Of course for arrays of value types the compiler would have to figure out that .dup and .deep do 
the same thing and don't recurse).

> BTW: one concern I'd have with a root-Object dup() method is the need to 
> cast the returned instance. Presumeably a more specific compiler 
> implementation (of object.dup) would sidestep that need for casting?

I agree.



More information about the Digitalmars-d mailing list