The plus plus

[Andy Green]

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