Re: Alpha release!

[Hary Walsh <hwalsh@tellabs.ie>]

>>>>> "Kasper" == Kasper Peeters <t16@nikhef.nl> writes:

    Kasper> I would turn that around. Let's start with STL, and if we
    Kasper> _really_ need a better performance or less memory waste,
    Kasper> rewrite some parts.  STL is finished now; our containers
    Kasper> would still have to be written and debugged. Having a
    Kasper> working browser is more important than full optimisation
    Kasper> at the moment.

Yes, I see your point, and to some degree I agree with you, but I
*really* think that caution needs to be observed.  Some of the memory
management functionality is dissapearing from STL, which may prove to
be a serious problem.  On the product I'm working on at the moment,
data size was reduced from about 3.5 Mb to 350K.  Here we are in big
trouble at the moment.  What happens when this functionality
dissapears?  Do we stick with an old version of C++ and STL or do we
ignore the memory issues.  Both are unacceptable in the long run.
There is some talk on comp.std.c++ about this issue, but I don't
follow it closely enough to know how it's going to turn out.

I think before STL is used, an analysis should be done to define
exactly which containers are needed.  It probably won't be anything
other than vector, string and map.  A smart pointer class is probably
a good idea too.