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;
}

http://harmful.cat-v.org/software/c++/I_did_it_for_you_all

NO EXCEPTIONS

huh what?

>    virtual void print() = 0;
WHBTC

>>1
You shouldn't call virtual functions from constructors. In C++ a base function is called (in your case throwing a "pure virtual call" exception), in C# or Java the correct function is called, yet it may perform incorrectly as the derived class fields are not initialized yet. Except those which are initialized using inplace initializers, because C# specifically with this in mind does two-phase initialization, with first initializers called from derived to base and then constructors from base to derived.


Also if you find it "just too fucking complicated" (and can't even identify the real cause of the complexity, blaming it all on C++) I recommend you to learn LISP, read SICP and never ever do actual programming again.

Well fuck C++, I'm going back to C#. C++ feels like fucking stone age, man.

In C++ a base function is called (in your case throwing a "pure virtual call" exception)
This is intuitively recognizable as the “wrong” behaviour by almost anyone. It seems that C++ was designed by implementation, rather than implemented to a design.

designed by implementation, aka hacking.

>>7
You might be surprised, but the C++ way is in fact more theoretically sound, consistent, pure and simple, if you take some time to understand how it works. Wow, never thought I'd ever say that.

The idea is that the constructor of class `T` constructs an instance of class `T`. Full stop. To construct an instance of class `T` means to ensure all invariants of the said class. The type of `*this` during construction of the instance of class `T` is `T`. Obvious, isn't it? Also, there ain't such thing as an "abstract" class, every class should allow creation of its instance.

Then, if you actually wanted to construct an instance of class `Derived : T`, it's like you take a fully constructed instance of class `T`, extend it with your fields and use the constructor of `Derived` to ensure the invariants promised by the `Derived`. Just like in Smalltalk, I guess. The fact that the implementation used compile time information to allocate enough memory to avoid copying and stuff is an implementation detail. As are the hairy details of how this works in case of multiple inheritance.


Then C# is like, well, man, the real invariants are that everything is initialized with zeroes, yeah, live with it. Oh, wait, we can also guarantee that your initializers will all run and initialize `readonly` fields, ain't that nice? They will run from derived to base because it's easier to implement, by the way. Then your constructors will run, well, they are, like, initializers, but we call them constructors because that feels good, don't worry, man, it's OK. There you can ensure _your_ invariants. Also you can call virtual methods, but then they will dispatch to yet uninitialized parts of your class, with no invariants _of yours_ established, but you should just be cool about that. Like, as if you know what you're doing and don't use your invariants there, because they are illusory anyway, heard about Veil of Maya? All world is an illusion, just take it easy, man.


Unsurprisingly, the C# way is easier to use.

>>8
This is intuitively recognizable as the “wrong” behaviour by almost anyone.

Noncommutativity of matrix multiplication is intuitively recognizable as the “wrong” behaviour by almost anyone too.

It seems that C++ was designed by implementation, rather than implemented to a design.

Wrong, setting up the correct vtableptr and then just running all constructors would be easier to implement.

>>11
Noncommutativity of matrix multiplication is intuitively recognizable as the “wrong” behaviour by almost anyone too.
Are you implying that no one without an academic degree should program in C++?

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

>>12
Actually, if C++ is really the appropriate tool for the job, you're either a game programmer, or you want people with either a degree or equivalent practical experience.

>>13
This is one of the best posts I've ever read on /prog/. I... HBMT by a good post?

Also, are there any developments with Sepplesox or is the committee being typical and jacking off to book royalties?

SSDD aka 'Design by Committee', Sepples will always be viewed as bureaucratic design monstrosity despite anything that showcases its features.

_______________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
We hold life to be sacred, but we also know the foundation of life consists in a stream of codes not so different from the successive frames of a watchvid. Why then cannot we cut one code short here, and start another there? Is life so fragile that it can withstand no tampering? Does the sacred brook no improvement?

>>15
Maybe that's because it's your post.

>>18
I can insure you that I am no anus!

I feel dirty trying it. Regardless, I am >>15 and I certainly not >>13.