On the richness of C++

[Sean Kelly]

== 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.


Sean