C++...huh what?!

Why won't this little app work? What's wrong? C++ is just too fucking complicated jeez

#include <iostream>
using namespace std;

class abstract {
public:
    void init() { print(); }
    virtual void print() = 0;
    abstract() { init(); }
};

class abc : public abstract {
public:
    virtual void print() { cout << "I am abc" << endl; }
};

int main(int argc, char* argv[]) {
    abc test;
    return 0;
}

>>12
I am impying that somehow when C++ tries to be theoretically pure and sound, the unwashed masses still cry out about the "design from implementation", kinda showing the depths of their unwashingness. Unwashness. Whatever.

What I was trying to convey was this:

1. Initialization and inheritance is a problem with no perfect solution.

2. The problem is with the programmers, who deduce the behavior from the most simple implementation they can imagine. Like, "alloc the memory, call all constructors, what could possibly go wrong?". Well, everything, but they don't know that and therefore are startled by the real behaviour and say stupid things like "It seems that C++ was designed by implementation, rather than implemented to a design".

3. As it was at the time C++ was designed, there were two solutions:

3a) do everything as Joe the Programmer would expect. I.e. just allocate the memory, point the vtableptr at the right place and run initializers. That are called constructors for some reason. Then Joe tries to call a virtual method from a constructor, try to use some pointer from it, catches a pagefault and can't do anything about it. Except creating his own Init() virtual method chain.

3b) Use the Scientifically Sound Shit, i.e. what I've said above, that the constructor of class Class constructs the instance of that very class and nothing else. Now Joe sees a pagefault, but at least he can slap his forehead and understand what's going on and create his virtual Init() method chain. And that's Scientifically Sound Shit, by the way.

4) The C# way. Allow the inplace member initializers (despite that they make it unclear where you should initialize a member, inplace on in a constructor). Say that they are always executed before any constructors. Now run the constructors in the expected way. Now,
4a) the programmer doesn't touch this shit. Everything works fine, as in C++ too.
4b) the programmer calls virtual method from a constructor and sees uninitialized member. He understands what's going on and initializes the member inplace. And wonders for a while about the reversed order of member initializers.
4c) He can't, so he has to invent his own virtual Init() chain.

The interesting thing is that C++ semantics are not useful at all. They restrict. They restrict unsuspectingly, like, a programmer can't expect that his runtime swaps vtableptrs with absolutely no benefit, except for higher-order abstract bullshite. And when we allow member initializers, the one-and-only vtableptr assignment becomes actually useful.

The moral of the story is twofold. Firstly, not all C++ faults are due to gradually accumulating implementation defects, sometimes it's Scientifically Sound Design Desisions. Secondly, using SSDD against common sense is wrong.