15 Oct
2017
15 Oct
'17
6:30 p.m.
Hi Max,
On Fri, Oct 13, 2017 at 11:57:51AM +0200, Max wrote:
While looking at osmocom/netif/datagram.h I've
noticed that it's organized
differently compared to other libosmo*. Most notably, it does not have structure
definitions, only brief declarations in datagram.h while the actual definition is in
datagram.c
This is correct. It's probably following the kind of learning curve that Pablo
was making with netfilter related libraries over time.
This effectively means that client code using the
library do not have access to
struct internals and have to use various "osmo_dgram_.x_set_*()" functions to
manipulate them.
correct.
This got me curious - what are the pros and cons of
this approach?
I can see the benefit of being able to change struct internals without changing the
API. I can also see the downside in having to define lot's of boilerplate
setter/getter functions.
I think that's about it. If you want to keep a long-term stable ABI +
API, then hiding the structure is the only sane approach. But yes, it
comes at a cost.
Is there a way to avoid or at least simplify
setter/getter
boilerplate?
I think it's called C++ with its ability to have private/friend/public members ;)
In C, I'm not aware of any simplification.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)