From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA17456; Mon, 15 Jul 2002 17:46:14 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA11158 for ; Mon, 15 Jul 2002 17:46:14 +0200 (MET DST) Received: from mail.interaktif.net.tr ([62.248.102.120]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6FFkCj01008 for ; Mon, 15 Jul 2002 17:46:12 +0200 (MET DST) Received: from abn166-176.ank-avrupa-ports.kablonet.net.tr (unknown [195.174.166.176]) by mail.interaktif.net.tr (Postfix) with ESMTP id 89EE51E654; Mon, 15 Jul 2002 18:44:30 +0300 (EEST) From: Eray Ozkural Organization: Bilkent University CS Dept. To: "Nicolas Cannasse" , "OCaml" Subject: Re: [Caml-list] Deep copy Date: Mon, 15 Jul 2002 18:40:25 +0300 User-Agent: KMail/1.4.5 References: <0489A7888F080B4BA73B53F7E145F29A1B0AF3@LANMHS20.rd.francetelecom.fr> <200207151802.44699.erayo@cs.bilkent.edu.tr> <000d01c22c14$2f99c590$9400a8c0@warp> In-Reply-To: <000d01c22c14$2f99c590$9400a8c0@warp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207151840.25312.erayo@cs.bilkent.edu.tr> Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 possible. 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 www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners