Les Mikesell wrote:
Hi Les -
- how do I manage init of these structs, allocation of malloc()-ed
elements and free()-ing them to avoid leakage?
Carefully, of course, and in ways that let you allocate shared
memory or malloc()'ed as you choose.
Well C++ adds this idea of lifecycle functons associated with structs, a
constructor that preps it including allocations if needed, and a
destructor that is the one place you HAVE to free up allocations that
belong to the struct. The destructor is not normally called explicitly
but is fired whenever your struct is "freed" by any method. In this way
you can guarantee to in turn take care to free() anything that was
malloc()-ed on behalf of your struct instance.
It doesn't do anything you can't do by making decisions about your style
in C, but having this stuff in the language does make for more rigorous
and deterministic code; basically the language is on your side if you
leverage these features rather than being something you are constantly
managing by hand. The resultant sources are also smaller and clearer
since things are being done implicitly rather than explicitly.
I've just always thought of data and code as very different things
and both likely to contain their own sort of flaws. If you have
a bug in a function library you may be able to work around it. How
do you deal with a flaw in a class where the only way to access
the data in an object is broken?
Well, in a FOSS library you just fix the problem in the library and
that's the end of it. In the extreme case you have to make some kind of
ugly workaround, the object is in the end a struct in memory that has a
pointer to it, you can get what you need at one offset or another from
the object pointer.
-Andy
