Taking a copy of an object

[kris]

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 
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 ;)

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

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?