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
