On the richness of C++

[Sean Kelly]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> == Quote from Frits van Bommel (fvbommel at REMwOVExCAPSs.nl)'s article
> > Sean Kelly wrote:
> > > With the vtbl checking in D, I think the above call will throw a "not implemented"
> > > message because D overrides one inherited "new" routine but not the "placement
> > > new" routine inherited from Object.  In fact, this has me wondering about the
> > > practicality of this sort of checking at all.  It seems a fairly straightforward
> > > design for the language to consider broken.
> > Actually, that doesn't apply to class allocators. Since no instance
> > exists yet, they don't do the vtable lookup; they're implicitly static.
> > And that means calling inherited class allocators, at least from outside
> > the class itself, is an error if a new one is defined.
> That's a slightly odd rule.  I'd think that explicitly calling obj.new() would be
> fine since doing so shouldn't mutate the instance.  Or did I misunderstand?
> > Also, I'm not sure if you can call an inherited allocator with 'super'
> > as you're trying to do in class D.
> Really?  Strange.  Hm... well upon further reflection, I think this may be a special
> case for methods in Object, since one could argue that anyone who only wants
> to override a subset of overloads should add empty forwarding overloads (ie.
> that call super) for the remainder, for clarity.  But the lack of compile-time
> checking still stinks... I'm still not sure it prevents more bugs than it creates.

Bah... forget everything I said.  You're right of course.  Someday I'll learn never
to post when tired.  It's just such a difficult rule to remember at the appropriate
times :-)

So for the record.  I do think the overload checking is a good idea--it just needs
to be clearly documented somewhere (if it isn't already).  And the 'super' thing
makes total sense--there's no instance so 'super' isn't technically valid.


Sean