The C Programming Language: Myths and Reality (1)

Re:The C Programming Language: Myths and Reality (1) by falcrist on Monday July 17, 2023 @02:56PM (#36762442)

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.

[ Parent | on HN ]

Re:The C Programming Language: Myths and Reality (1) by c-linkage on Monday July 17, 2023 @03:19PM (#36762704)

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.

[ Parent | on HN ]

Re:The C Programming Language: Myths and Reality (1) by falcrist on Monday July 17, 2023 @06:08PM (#36764733)

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

[ Parent | on HN ]

Re:The C Programming Language: Myths and Reality (1) by cozzyd on Monday July 17, 2023 @04:57PM (#36763979)

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.

[ Parent | on HN ]