Assuming that is your exact code, then the primary problem is that you cannot both define and initialize members of a class like that. You have to initialize them in the constructor's initializer list.

The secondary problem, once the above is "solved", is that you should be very careful when you pass this to a member's constructor. The member's constructor is executed before Application's constructor, so the Application object you're passing to the Airplane's constructor is not fully constructed yet. I don't know if it is outright undefined, or simply just undefined to touch the parts that has yet to been initialized so that you can arrange the member carefully to avoid accessing uninitialized parts.

The tertiary problem is (or rather, may be) a design problem: why does the Airplane have to know about the Application?

Assuming that is your exact code, then the primary problem is that you cannot both define and initialize members of a class like that. You have to initialize them in the constructor's initializer list.

This changes with C++11, which allows brace-or-equal-initializers for member variables. Though as the name suggests you need to use either braces or = in order to specify out of constructor initializers. However, not as many compilers as I would like support this syntax now.

[quote name='Brother Bob' timestamp='1351720559' post='4995961']
Assuming that is your exact code, then the primary problem is that you cannot both define and initialize members of a class like that. You have to initialize them in the constructor's initializer list.

This changes with C++11, which allows brace-or-equal-initializers for member variables. Though as the name suggests you need to use either braces or = in order to specify out of constructor initializers. However, not as many compilers as I would like support this syntax now.
[/quote]
I thought that way of initializing members was only allowed for compile-time or constant expressions, or perhaps even expressions with members that has been initialized already, since you cannot pass any parameters (unless you want to correct me again). That would make it useless in this particular case. But seems like this is indeed allowed, and that makes sense also, so there you go: +1 for that.

I'm not sure what you mean by "cannot pass any parameters". If you are saying that you can't pass any of the parameters from a constructor to a brace-or-equal-initializer, then no, the you can't. The class member initializers are used in the default case, if no member initializers are used for that member in a constructor's member initialization list. However, that's not what the code in the OP was doing. Otherwise, class member initializers have no restrictions on the complexity of the expressions used as initializers for non-constexpr member variables that I can find in the standard (admittedly, the semantics for brace-or-equal-initializers are spread out over something like five different sections so I may I have missed one). In particular, member functions are explicitly fair game as it talks about how virtual functions called work just like other virtual functions called in constructors and the class is specifically noted to be a completed type within the scope of a brace-or-equal-initializer so any expression involving any of the class' member variables are also fair game (unfortunately, this also means members that haven't been constructed yet).

As you said, I meant that you cannot (as I understood it) get any parameters from the constructor to the initializer. I just thought that there's not a lot you can do other than giving a default value, given that you cannot compute anything object-specific that needs object-specific parameters you typically pass to the constructor. However, they seem to be more a bit more flexible then I had first assumed.

I suppose you could pass parameters indirectly. You could have the constructor initialize a member variable using parameters and then reference that member variable in the initializers for other member variables. Ex: constructor initializes a count variable and the member initializer allocates memory based on that count. I wouldn't want to maintain that kind of code, but I don't think there's anything in the standard to prevent it.