English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Interfacing C++ and Ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-02 (13:48)
From: Fergus Henderson <fjh@c...>
Subject: Re: Overloading again (Was Re: [Caml-list] Interfacing C++ and Ocaml)
On 02-Apr-2001, Jean-Marc Alliot <alliot@recherche.enac.fr> 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.
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 <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr