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 PAA31616; Mon, 2 Apr 2001 15:48:22 +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 PAA31628 for ; Mon, 2 Apr 2001 15:48:22 +0200 (MET DST) Received: from mumnunah.cs.mu.OZ.AU (mail-gate.cs.mu.oz.au [198.142.254.221]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f32DmFj29742 for ; Mon, 2 Apr 2001 15:48:16 +0200 (MET DST) Received: from murlibobo.cs.mu.OZ.AU (murlibobo.cs.mu.OZ.AU [128.250.29.17]) by mumnunah.cs.mu.OZ.AU with ESMTP id XAA29343; Mon, 2 Apr 2001 23:48:12 +1000 (EST) Received: (from fjh@localhost) by murlibobo.cs.mu.OZ.AU (8.8.5/8.7.3) id XAA18687; Mon, 2 Apr 2001 23:48:08 +1000 (EST) Date: Mon, 2 Apr 2001 23:48:08 +1000 From: Fergus Henderson To: Jean-Marc Alliot Cc: caml-list@inria.fr Subject: Re: Overloading again (Was Re: [Caml-list] Interfacing C++ and Ocaml) Message-ID: <20010402234808.A8780@murlibobo.cs.mu.OZ.AU> References: <3AC834B4.559806D0@recherche.enac.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3AC834B4.559806D0@recherche.enac.fr>; from Jean-Marc Alliot on Mon, Apr 02, 2001 at 10:13:40AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 02-Apr-2001, Jean-Marc Alliot wrote: > Well, I am going to be the black sheep again, but as an old ADA and C++ > programmer, I don't really want to see overloading pop up in ML. Incidentally, it's "Ada", not "ADA". > Overloading can become easily a source of mistakes. My favorite example > is the following. A few years ago, I was managing a project with C++ > code, and one of the programmer was using a third party library (the > author of this library was gone and had been replaced). And he had a > bug inside the following code fragment in that library: > > toto(titi *initp) > { > titi *p; > > for (p=initp;p!=NULL;p++) > { > ....... > } > > } > > And it took him a very long time to realize that the ++ operator had > been overloaded, somewhere in a .h file included in an other .h file, > and that instead of incrmenting the pointer, it was doing something > like p=p->next, with a next field incorrectly initialized somewhere. This example is a bogus example, since C++ doesn't allow that kind of overloading. C++ requires that every overloaded operator have at least one parameter whose type is a class, or a reference to a class, an enumeration, or a reference to an enumeration (see e.g. 13.1.1.2 in the C++ standard). In this case the argument has pointer type, so it can't call an overloaded operator. My opinion with regard to overloading is that what is really problematic about overloading in C++ is the *combination* of overloading and implicit conversions. Mercury supports overloading, without implicit conversions, in my experience it works fine. The main drawbacks are that (a) occaisionally you need to use explicit type annotations to resolve ambiguities and (b) sometimes the presence of overloading makes it harder for the type checker to issue good error messages. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr