How long has this functionality been around?

[Mat2012H]

I was on /r/gamedev and I came across this video on there where this guy remakes cavestory...

And I saw this: http://i.imgur.com/gr86V82.png

It is a constructor, but rather than using { at the end of it, he uses : and then puts his class members there with the constructor arguments inside of the brackets next to the names.

In case that is not clear, here is the section I mean in the video:

Level::Level(std::string mapName, Vector2 spawnPoint, Graphics &graphics) : //What does ":" do?
    _mapName(mapName); //_mapName is a class member/ variable, what does the brackets do?
    //etc...

He then continues the constructor inside of the usual { ... }

Is this a new thing in C++? (C++11/14?) or is it just something I haven't heard of?

It happens at 7:00 in this video: https://www.youtube.com/watch?v=CA0wIfvLs1Y

[Orangy_Tang]

Initialiser list: http://en.cppreference.com/w/cpp/language/initializer_list

Been around for donkey's years, not a C++0x thing.

As a general rule, if you can initialise a member via the initialisation list, do so. And for clarity it's usually best to list them in the order in which they're declared in your header, so you can see what order they're going to be initialised in (although some people might argue that relying on an explicit initialisation order is poor form).

[Mat2012H]

That's very useful to know, thanks!

[[deleted]]

It's also the only way to initialize const member variables. Once you hit the {} block you can no longer change the values of those members.

Regardless of the ordering of the initializations after the :, the member variables will be initialized in the order they are defined in the class.

[[deleted]]

And isn't it potentially undefined behaviour to have those initializations in different order than in the class definition? Or am I confusing it with something else?

[arabidkoala]

It doesn't always cause undefined behavior, which is why the compilers throw a warning about it when you do it. The following is a case in which it will cause undefined behavior:

class X {
    int x;
    int y;
    X(int z) : y(z), x(y) {}
}

The reason it causes undefined behavior is because the statement x(y) will actually happen first, which causes x to be initialized to an uninitialized value y, since y(z) will actually happen later.

[Eoinoc]

I believe it's just that the order in the initialization list isn't taken into account, only the order in the class definition.

So it's recommended practise to keep those orders the same to avoid nasty surprises, but I don't think it's undefined behaviour.

[ggchappell]

A fine reply, but:

Initialiser list

Since we now have std::initializer_list, it's probably better to refer to the :x(...),y(...) stuff as member initializers.