Yes, that's usually how it goes, each header/source is like a "class". And usually, what you have is a "main" struct that represents the "class" itself. In this case that main struct can't have both private and public fields.

> And usually, what you have is a "main" struct that represents the "class" itself.

Yes that tracks with the work I've done. It could even be so simple that only one value needs to be exposed through a getter (along with a couple "methods").

An ADC in an embedded system could operate like that.

> Yes, that's usually how it goes, each header/source is like a "class". And usually, what you have is a "main" struct that represents the "class" itself. In this case that main struct can't have both private and public fields.

You can, in a defined way (i.e., no invoking of UB). I just didn't put that in.

Out of curiosity, how would you do it? The ways I've seen require using another "public" struct and either casting public to private or using a nested pointer, each with their set of problems. In either case, it's still a bit hacky and still each struct is all-or-nothing public or private.

Pretty much. All the casting and hackiness isn't visible to the caller, and the implementation still maintains its ABI when the private stuff changes.

That's how I read it.

Clearly you can abstract away the parts of data that the API should not see.

Brings back memories of CS101 back in 1992.

They called this "modular programming" where "classes" were represented by opaque pointers and actions could only be performed on those pointers using the functions defined in the module.

In the production C code I've written that makes use of modules with interfaces that define public and private variables and functions, I tend to avoid using pointers where reasonable. I'd prefer to either give access to the variable or provide getter and setter functions.

What's the benefit of "opaque" pointers?

For background, my C code is almost entirely on microcontrollers. So I'm looking at it from that point of view. If you're talking about event-based applications running inside a full operating system, I've always stepped up to something like C#, so I don't have much experience with function pointers for that kind of work.

For those accustomed to always using open source, the idea of hiding the implementation must seem odd.

But consider the position of developer who implements a shared library that is distributed in binary form only. In this case, the benefit of opaque pointers for the development of a library is that the implementation remains private at the source level. One could, of course, reverse-engineer the binary but few people would do it.

If you define your structures in a public header -- and this includes C++ classes and templates with private members -- one can easily see the implementation and, with a few casts, start munging the guts of your objects and baking in a hard requirement on a specific layout and / or version of your library.

Ok I see what you're saying. Closed source libraries can make use of this idea.

yes, there is no benefit on micrcontrollers where everything is usually compiled together as one image (ok, I imagine you COULD design a microcontroller firmware with dynamically loadable sections... but let's not think about that).

But for dynamic linking, this is how you avoid breaking ABI while maintaining forward flexibility.

This is what Niklaus Wirth was getting at, in his "push back" on conventional class-based OOP. In Pascal/Object Pascal, they are called "units", as oppose to "modules". In his Oberon/Oberon-2, they are called modules.