Re: [boost] Re: Recommended STL implementations for MSVC

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-18 11:26:24

From: "William Kempf" <sirwillard_at_[hidden]>

> > I haven't tried the latest Dinkumware code, largely because I was so
> > dissapointed with the version that ships with VC6.  It is
> nonstandard, slow,
> > bloated, unreadable, buggy, and not well supported.
>
> At the time of it's release it was the most standard implementation
> that I'm aware of.  I've not found it to be slow or bloated either,
> though I'm sure it could be improved in these areas.  There's also
> very few bugs, all well documented with fixes and work arounds.
> Readability is in the eye of the beholder, though even the author
> complains about this one.  As for not well supported... have you
> tried to get support?  I've found the support to be exemplary.

I don't want to get too deep into details here, since library
implementation quality is only topical in a few respects.  To address your
points, my comments are with regard to the quality of implementations that
ship today with VC6 and ship today with STLport.  Although the freeze
dates should be considered for evaluating the authors' competency, they
are not relavent to the question of "What should I use today, if I don't
want to shell out any more money?"  As for speed, I've done tests, and
node-based containers are several times faster with STLport, primarily
because of the allocator.  I haven't done size tests, but by looking at
the code and seeing properly segemented template-versus-non-template
classes in STLport versus the Dinkumware monolithic _Tree, don't you
expect the Dinkumware code to be bloated compared to STLport code?  I've
never tried to count the number of bugs, which would be difficult because
of the Floridian level of subjectivity (e.g. are the missing std::min()
and std::size_t bugs?)  In any case, if you know where they are well
documented, please post the source.  I searched MSDN for the std::list bug
I mentioned in the previous post and came up empty.  The fact that it's
been two years and 4 service packs since VC shipped, and bugs like this
haven't been fixed is inditive of a component that is not well supported,
given that there are test suites out there designed to pound on a compiler
and its standard library.  Perhaps I could call up Microsoft and tell them
the problem, and they'd get around to fixing it in SP5, which would make
the library fairly supported in my book, or maybe they'd tell me how to
fix my own system, but not issue a general fix, so my code wouldn't be
portable, which would make the library poorly supported, IMHO.  I haven't
contacted Microsoft regarding STL, discouraged by all the news I heard
about their refusal to put a fix for std::string in the the runtime DLL,
and the fact that I switched to STLport.  It's encouraging to hear that
you have had good success with support.

> > Items 1 and 6 are important to Boost.  With STLport, there is no
problem,
> > whereas we have to specifically put in workarounds in order to achieve
> > compatibility with out-of-the-box VC6SP4.
>
> What work arounds have been done in Boost?  The only ones I'm aware
> of come from compiler non-compliance, not problems with the "STL" (I
> really hate using that acronym).

I'm not fond of the STL acronym, either; however in this case it is
convenient in that is concisely separates out the iostream library (which
I hear is better in STLport, too, although I haven't benchmarked it).  The
Dinkumware workarounds in boost are std::size_t, std::ptrdiff_t, std::min,
and std::max, which STLport gets right and Dinkumware in VC6 gets wrong.

And just because I forgot to put the plug in my previous email, the debug
version of the STLport implementation (__STL_DEBUG), is very handy.