The C Programming Language: Myths and Reality
I see where you're coming from but IMO this "Cheshire cat" idiom to hide the implementation details is not exactly like private, it fact it can do things that private can't do, and doesn't do things private does.<p>The advantage of hiding your state behind an opaque struct with builders and accessors is that you can change the size and layout of said struct without it being a breaking API change. The code remains binary compatible even, no need for a recompile if you're shipping a shared lib. This is something just using private members doesn't achieve since with private members the compiler still knows and uses the layout of the struct, it just forbids access to it.<p>That's why you can even find C++ libraries use this idiom even though C++ obviously has `private`. It's about having a stable, opaque API.<p>On the other hand because of this added indirection, there's usually a greater performance hit to accessing these opaque structs since code can't be inlined. With private since the compiler can still see inside the struct, it's able to more aggressively optimize the code. You can also store the objects directly on the stack without requiring malloc.<p>IMO the right way to have private members in C structs is... to document that members shouldn't be touched directly, perhaps using a special naming convention or embedding the publicly-accessible members in a dedicated sub-struct to prevent confusion.