3 ms·
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
by gjulianm 3y ago
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.
- falcrist 3y ago> 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.
- lelanthran 3y ago> 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.
- gjulianm 3y agoOut 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.
- lelanthran 3y agoPretty much. All the casting and hackiness isn't visible to the caller, and the implementation still maintains its ABI when the private stuff changes.