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 <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
