Overloading/Inheritance issue

Steve Schveighoffer schveiguy at yahoo.com
Thu Aug 2 06:55:15 PDT 2007


Regan Heath Wrote:

> Steve gave an example in this very thread where the C++ behaviour can 
> cause errors for users/consumers of the classes so that would count as a 
> penalty for the C++ case.  Conversely you could argue that at least this 
> isn't a silent error as the problems Walter describe are (from memory - 
> pls correct me if I haven't remember it correctly).

OK, I was totally under the impression that C++ was the way I was saying D should be.  I was assuming that C++ got it right.  More than I can't believe that C++ is not right, I'm surprised I never had problems with it...

However, I think it should be changed.  Not sure if it will, as it seems there  is already a precedent.  In my opinion, the base class should be examined if the derived class does not provide a suitable match.  I can't see how this would cause too much of a performance hit, especially since the choice of the compiler at that point is to error out (current implementation) or continue searching (my proposition).  If the derived class can provide a suitable method, then it should be no more performance hit than the current implementation.

BTW, my example comes from a real world case... tango :)  If you look at tango.io.selector.EPollSelector it only implements select(float).  It is trying to rely on the AbstractSelector's select() to call the other version, but the author failed to include the alias statement.  Note that this essentially makes it seem like EPollSelector DOES NOT implement the ISelector interface, since ISelector calls for a select() method.  That is, unless you cast to an AbstractSelector or ISelector, which is my workaround.

-Steve



More information about the Digitalmars-d mailing list