On Fri, Jul 14, 2000 at 04:22:29PM -0500, Johan Warlander wrote:
> Browsing the code a few months ago, I saw that it's not using the STL, but
> rather has its own container class, the linked list one. Merely out of
> curiosity, is this because no one's gotten to it yet, or is it a conscious
> choice? I *can* see many reasons not to use it, in certain circumstances -
> like wanting to maintain compatibility with older compilers, perhaps even
> specific bugs in the STL that are not acceptable. I was just kind of
> curious, since I've done some work using the STL myself and found it for
> the most part a blessing.
>
Well, from my point of view there are a number of reasons for this :
1. Not every C++ compiler out there includes an STL implementation,
nor will they even work with some of the freely available ones.
Furthermore their interfaces have only recently been standardized.
2. Most compilers require all template code to be available in
the included header file. For STL templates this can mean quite a
lot of code must be included, which greatly increases compile time,
especially in light of the sheer number of Blackbox files which use
LinkedList's.
3. Blackbox uses a decent number of LinkedList's of different
(pointer) types; a naive STL implementation would result in
substantially more memory consumption, since it will generate
code for each template type used. This can be avoided by providing
code in the template library to handle the special case of containers
of pointers, but not all compilers support type specialization.
4. The iterator-infested interfaces of the standard library may make
the pattern folks happy, but it makes performing some very basic tasks
more complicated than they need to be.
Basically, the C++ standard (STL included) provides a number of nice
features, but unfortunately most every one of them runs contrary to
resource efficiency. Since Blackbox tends to emphasize efficiency,
it tends to use very little of what the standard has to offer.
Mind you, this is just my own opinion; nyz is responsible for having
written most of that code, and he may have had other reasons.
Jeff Raven
