Private: is not private

Can someone please explain to me why exposing your private state and implementation functions in c++ header files is encouraged? I'm not talking about mutability, but rather allowing other implementation files to see and be physically coupled to "private" implementation details exposed through the header e.g. (member datatypes and names). Is it just me who has a serious problem with this?

The only alternative i'm aware of is the pimpl idiom, which is definitely not an ideal solution. While it does give you complete encapsulation, it results in boilerplate code, and a runtime performance hit, which is ludicrous..

What kind of mental gymnastics do you have to do in order to convince yourself that private: is private?

pic related is the only book I've seen really address this issue

Attached: 2069013.jpg (300x388, 41K)

Sounds like a consequence of supporting multiple inheritance. C++ is pretty yikes in general tho, so it’s unsurprising.

agreed. I find myself jumping back and forth between c and c++, but ultimately ending up at C every time because of shit like this

>c++
thats a polymorphic virtual inherited templated boosted yikes from me

I have a tmp for that

>encouraged
Your biggest problem OP is that you are pretending cpp is object oriented language. Hint: its not. Cpp is wild west of languages where everything is possible.

The fact that something is possible or can gain you 0.1% faster code doesnt automatically mean you should use it. In almost all cases readibility of code is always higher on priority ladder than raw speed.

Dont give a damn about why its common. Pretend it isnt a thing and feel free to keep your private atributes and methods hidden.

but that's how c++ is marketed and taught.

I agree to an extent with your point that writing readable code trumps most other things, however, it also depends on your target platform and performance characteristics. As a core game engine developer, it's simply not acceptable to use something like the pimpl idom in the middle of a render tick, iterating through the visible set.

I also agree with your last point, however generally you have to work with other people who perhaps do not have that same view point and have constrained themselves to that OOP paradigm, and have been taught c++ by putting all of their "private" members in the header file, because that's the supposed standard c++ way to do things.

What i'm trying to do is get people to question whether they should be exposing this state and what the ramifications of doing that is. The usual answer i get is: "oh well it's private, no one can access it" which completely misses the point

From the average programmer's point of view, it doesn't matter. The point of private state/functions is to keep the intern from fucking with something they aren't supposed to, or to catch your own errors before it compiles. The features aren't meant to provide true security.

Okay. One way why people put private stuff into header is because some (maybe all?) compilers otherwise cant do inlines and other optimalisations. Which doesnt make sense if the compiler has access both to cpp and h file, but in some cases (DLL, static libraries) the compiler has access only to the header file.

And btw if you are writing such exotic stuff as 3D game engine (basicaly anything like pipeline), almost all OOP concepts has to go out of window because they are too slow. Many uni profesors will tell you that using GOTO is bad, but then they never even wrote html parser. This is similiar issue: theory VS practical world.

And he is correct, almost all fancy keywords like private, public in cpp are mostly for static / compile check. You can do literally anything in runtime with cpp. Nothing (often not even OS or virtulisation) can stop you from reading memory. Sometimes you can even read memory you didnt alocated which is the basic doom of all modern container based frameworks which promises "security".

based sepples dun give a fuk