Pimpl and potential alternatives

Started by
10 comments, last by Hodgman 8 years, 8 months ago

Can't you just


char[StorageSize] _storage;
And work with it the same way?

Provided you add some boilerplate to deal with alignment, yes.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement
I tend to use "the 'this' pointer is a pimpl" as posted in these other threads.

http://www.gamedev.net/topic/648046-hiding-private-methods-and-variables-in-a-class/

http://www.gamedev.net/topic/640501-pimpl-for-renderer-class/


I've also used bioglaze's "StorageSize" approach occasionally (and yes, the CPP should contain static_assert(Interface::StorageSize == sizeof(Implementation));

I find that one the most useful when working on structures that are immediately usable after being copied to RAM from disk (i.e. in-place / parseless deserialization) because you're already being very careful about exaxt sizes/offsets/alignments in those situations :lol:

I don't worry about it at all. Private variables being visible in headers is no different than a module-based languages such as Java, where *everything* is in one file.

It definitely doesn't have to be used everywhere, so probably shouldn't be used by default... But using it at "module" boundaries can be very important - e.g. to keep GL contained inside your 'renderer' module.

It's a massive issue for compile times (not everything can be forward-declared, implementation-hiding is oft required to keep include-chain-reactions under control) and is almost essential when doing cross-platform work that involves multiple different implementations, each of which include different system and 3rd party headers.

e.g. IMHO, you should never include an OS or middleware header in one of your own public headers (keep them isolated to your private implementation). Doing so ends up exposing huge sections (potentially all) of the high level game code to these OS/Middleware headers... Which can massively bloat compile times (an extra 100k lines of code per CPP isn't unlikely) and cause headaches when porting due to libraries that pollute the global namespace and then accidentally get used by your game code (which shouldn't have ever included it).

This topic is closed to new replies.

Advertisement