Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Deep copy
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-15 (15:46)
From: Eray Ozkural <erayo@c...>
Subject: Re: [Caml-list] Deep copy
On Monday 15 July 2002 18:27, Nicolas Cannasse wrote:
> Errr....
> You're supposing here that either the copy constructor is implemented by
> the class writer or then that you're using the default copy constructor
> which only copy fields, and then do not perform any deep-recursion... It's
> even worst because pointers are duplicated so you can get very-unsafe
> behavior...

You're right. A default deep copy probably wouldn't work for most applications 
:) That's why you usually have to write your own copy constructor in C++. 
Still it is a convenient thing to have a "clone" function that can do it. 
Even in the presence of recursive definitions and such it ought to be 

This could be useful when one has objects for data structures... Though it 
could be said it is a better style to use recursive types and the module 
system when you are doing complex data structures, cloning looks like one of 
those handy features that you expect from an object system.

> The "copy" notion is ambiguous, especially when you have mutable fields.
> Does the modification of such a field on a copy of an object do influence
> the original object ? Or is copy only the image of an object at a given
> time ? And what if the object manipulate opened streams ?
> Not so easy to resolve... I would recommand then to write a copy operator
> "by hand".

I think Michael made that clear. Oo.copy does a shallow copy, it provides that 
all members of the new object will have physical equivalence to the given 
object. Therefore, modifying a mutable field on a copy should influence the 
original one.

The best kludge here would be to write an external function for all types that 
need the deep copy as you suggest. He could write his own copy function 
instead of Oo.copy

Writing a copy method inside each class would look worse :)

Eray Ozkural <>
Comp. Sci. Dept., Bilkent University, Ankara
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: