C : Too much code
C++ : Too complex
C# : Too many classes
Perl : No compile time type checking
C++ : Too complex
C# : Too many classes
Perl : No compile time type checking
This. Plus very opinionated decisions in language design, like, "properties" are always bad, "operator overloading" is always bad, but hey, we certainly need "checked exceptions". No, thanks, no java for me...
#include <iostream>
class A {
public:
virtual void f() { std::cout << "A::f\n"; }
A() { f(); }
};
class B : public A {
public:
virtual void f() { std::cout << "B::f\n"; }
B() { f(); }
};
int main() {
B b;
return 0;
}
I would argue that this kind of code is illogicalAs for me, the behavior of Java is illogical
.In Java - yes, it's better not to write such code. But in C++ such code is quite normal (I think), and the behavior of such code in C++ is well defined (but I don't write such code).
And that's why, in the "C++ model", virtual calls in constructors and destructors don't work.Technically, when a constructor is called, the first operation is to initialize the vptr, the class does not know if there are classes derived from it, and the vptr must refer to the virtual function table of that class. When returning to the constructor of a derived class, that constructor shifts the vptr to its virtual function table.
Didn't you say the result is just calling the current class' version? Which would probably lead to a crash if it's unimplemented (null) in the current class, or do compilers catch that? Anyways, I don't like that kind of behavior, I think it's counter-intuitive. That doesn't mean I like Java's behavior either, because it creates an awesome opportunity to shoot your foot by working on uninitialized data (which you can of course avoid if you're aware, but still). IMHO, the only sane thing for a language (and compilers) to do would be to strictly disallow any call to virtual methods during construction (IOW, issue a compile-time diagnostic and refuse compilation). I'd argue code doing such a thing is a sign of a flawed, likely over-complicated, design, which you should fix.
My implementation in C is only slightly different, first thing done in every construction is indeed something similar (initialize a pointer to some "meta object", which contains a class name and the full vtable), but this starts at the most derived type (it was the most straight-forward thing to do in C). This little difference would in practice lead to Java's behavior. As C doesn't support OOP at the language level, I don't expect any compiler diagnostics here of course, I just don't write code doing virtual calls in the constructor.
Yes, that's exactly what I said: first in post 10, then in posts 15 and 17. Simply virtual calls in constructors/destructors become non-virtual/non-polymorphic. Therefore, in C++ the code given in post 10 is quite normal. As for Java, I will still stick to my opinion, which I expressed in post 10.
sbcl & racket are nice.
