[thegrim000]

Well the very first item in the list is wrong so I stopped reading there. Have your interface between systems be pure abstract virtual classes so that changing private members in a concrete subclass doesn't propagate the change to the consumers.

[guenthert]

To expand on this, "In naturally written C++ code, changing the private members of a class requires recompilation of the code using the class." -- uh, the Pimpl pattern has been idiomatic C++ for a long, long time (http://www.gotw.ca/gotw/024.htm).

[taejo]

I assume that's exactly the unnatural way that's being referred to. The natural way to define a member variable is

Complextype m;

which has the fewest tokens, is the easiest to read, and doesn't require extra memory/lifetime management or library types that didn't even exist in the standard library for the first decades of the language (i.e. std::unique_ptr) so certainly weren't the originally intended way to declare members but are workarounds for a problem in the original language.

Of course, the solution to this (and some of the other problems discussed here) in other languages is often make everything a heap pointer under the hood, and there are good reasons not to do that!

[foofie]

> The natural way to define a member variable is (...)

No, that's not right at all. Your example is only a declaration of an incomplete type. You cannot do anything with it except.... Define a pointer to the incomplete type, and use that to keep the type definition hidden.

That technique is called pointer to implementation - pimpl. The thing you're complaining about?

[taejo]

OK, set me right. How do you declare a member variable "m" of type "Complextype" in C++?