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

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-18 15:33:09

From: "William Kempf" <sirwillard_at_[hidden]>
> Dinkumware has updated libraries.  Today the cost money, but with VC7
> they'll be shipped with the compiler.  It's not fair, in general, to
> criticize Dinkumware's implementation in comparision to STLPort
> considering these factors.

My intent was to compare libraries and not to criticize either.  I
acknowledge that STLport has an advantage of being updated, versus the
stagnant VC6 library.  But that advantage doesn't change the comparison,
though; the bottom line is that the product that Microsoft ships has quite
a few problems that STLport doesn't have.

> >From the stand point of the Dinkumware library, which is an STL
> implementation not a full standards library implementation, no they
> are not bugs.  The std::min() debate gets even uglier, because
> technically they *are* included with the Dinkumware library, they
> just don't work with the Windows.h header which defines a macro for
> this purpose.

For Micrsoft to release and sell a product using the name C++ after the
standard was ratified but not include the standard library, without
stating such absense on the box would be unethical, IMHO.  Fortunately,
one can easily make the case that a standard library was included, just
not a very up-to-date - and therefore good - one.  To its credit, it has
iostreams and localles, not just containers and algorithms.

I agree that std::min() is a sticky issue, but there's no excuse for some
easy ones like std::size_t.  And even the min macro problem could be fixed
with a little creativity.  Instead the creativity is in boost's
config.hpp, which is not where it belongs.

> This is a misconception.  The Dinkumware library shipped with VC++
> has remained static since VC5 first shipped.  This was due to a legal
> battle that Dinkumware had with a third party that prevented them
> from supplying MS with fixes or updates.  This legal battle was only
> recently resolved, allowing MS to ship the latest version with VC7.
> Despite this, claiming the library was unsupported does a huge
> disservice to both Dinkumware and MS, and it's unfounded.

My point is that the library is poorly supported, in that there aren't any
fixes in the VC6 service packs.  Why that is the case isn't relavent to
the the bottom line of making code work.  Here again, if Microsoft really
wanted to support their product well, they could have resolved the problem
with some creativity, e.g. dump/depricate the legally ensnarled Dinkumware
and provide an implementation they could update, even commercialize
STLport.  Obviously, there's a cost/quality tradeoff here, and Microsoft
went the route of saving the bucks.  I'm not saying their decision was
right or wrong; it just is what it is, and the result is a library that
still has problems, e.g. an auto_ptr with semantics that don't match the
standard.

> MS licenses the Dinkumware library.  They can do nothing but report
> bugs to Dinkumware.  They are not to blame for anything here.
> Dinkumware, in the mean time, has done their best to fix and maintain
> the library, and the updates are available to you.  It's only very
> complex and convoluted legal problems that have resulted in there
> being no fix available directly from MS.  This will be fixed with VC7.

My intent is not to assign blame, just to compare the quality of the
libraries.  For whatever reason, Dinkumware doesn't go very far on its
vc_fixes page, as even with those fixes in place, there are still many
problems (such as list.insert not working).  The result is that the
quality of the library in VC6 (VC6 + SP4 + vc_fixes) suffers compared to
STLport.  A different comparison would be how does the new Dinkumware
library compare to STLport, but I don't know how many people will be
buying the new Dinkumware library so close to the release of VC7.

> Technically, iostreams are not part of the STL.  Even std::string is
> not part of the STL.  The "bugs" you wanted to count, std:min,
> std::size_t, et. al. are not part of the STL.  Usage of this acronym
> is misleading at best.

I agree.  For boost, the meaning of STL isn't important, since boost leans
heavily on the standard library as a whole.  So it is the quality of the
standard library as a whole that is important.