4 ms·

I guess I'm reading the article a different way, because what I'm getting is that the author is suggesting the C analogue of a class is an entire header/source

I guess I'm reading the article a different way, because what I'm getting is that the author is suggesting the C analogue of a class is an entire header/source "module". That would make more sense, since you can use the header to craft an interface in which some components are public and some are private.

ricardo81 3y ago
That's how I read it. Clearly you can abstract away the parts of data that the API should not see.
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 ago
    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.
    - lelanthran 3y ago
      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.
c-linkage 3y ago
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.
- falcrist 3y ago
  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.
  - c-linkage 3y ago
    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.
    - falcrist 3y ago
      Ok I see what you're saying. Closed source libraries can make use of this idea.
  - cozzyd 3y ago
    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.
Tozen 3y ago
This is what Niklaus Wirth was getting at, in his "push back" on conventional class-based OOP. In Pascal, they are called "units", as oppose to "modules". In his Modula/Oberon, they are called modules. Many of the newer languages have modules or packages, but interface well with C, thus give the benefits of what the article was referring to. To include that various newer ones don't use class-based OOP, just as C doesn't.

ricardo81 3y ago

That's how I read it. Clearly you can abstract away the parts of data that the API should not see.

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 ago
  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.
  - lelanthran 3y ago
    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.

c-linkage 3y ago

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.

falcrist 3y ago
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.
- c-linkage 3y ago
  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.
  - falcrist 3y ago
    Ok I see what you're saying. Closed source libraries can make use of this idea.
- cozzyd 3y ago
  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.

Tozen 3y ago

This is what Niklaus Wirth was getting at, in his "push back" on conventional class-based OOP. In Pascal, they are called "units", as oppose to "modules". In his Modula/Oberon, they are called modules. Many of the newer languages have modules or packages, but interface well with C, thus give the benefits of what the article was referring to. To include that various newer ones don't use class-based OOP, just as C doesn't.