The plus plus

[Andy Green]

Les Mikesell wrote:
> On Sat, 2006-11-11 at 12:10, Andy Green wrote:
> 
>>> 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.
> 
> Can you provide a date for the time people started making this
> claim and also the time that you considered the STL impementations

Not sure which claim you mean; on the first it has always been the case 
that having the source empowers you to fix things directly. 
Interestingly enough even MSFT gave the sources for MFC back in the 
1990s, it was not liberally licensed though.  But it did give this 
assurance you could fix yourself out of their trouble if you had to, and 
also enabled debgging into their libs.  Sort of early acceptance by MSFT 
of the upside of giving sources.

On the second again objects have always been fancy structs in memory, 
the compiler does most of the typing grunt work.  If you have a pointer 
to the start of the object and some dirty crisis workaround is needed 
you can get an ugly, norportable pointer to the member you need, private 
or not, with an offset to the object base pointer.  But such nastiness 
won't be needed if you have the sources for the lib which would be the 
case for stlport for example.

> for GNU and MS to be more reliable than something you would
> code by hand in C?  My opinion is probably outdated and based
> on needing some old versions of stlport embedded in our CVS
> repository for some historical reason or other.

I should think anyone implementing the STL felt that it was immediately 
as or "more reliable than something you would code by hand in C" with 
some justification, since they sat down and coded it by hand in C++.

Anyway it's the language features that I wanted to suggest give the 
payoff, what to pick out of the library is a whole other consideration. 
  Basically if you find your C is full of structs, especially ones 
composed of other structs and pointers to allocated memory and 
functions, making the relatively small move to having the structs as 
classes and leveraging the language features there will probably make 
your code more readable, scalable, deterministic and reliable at little 
cost to source bloat (may even reduce it), code size or execution time.

-Andy