Re: Recommended STL implementations for MSVC

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-18 13:14:19

--- In boost_at_[hidden], "Ed Brey" <brey_at_a...> wrote:
> From: "William Kempf" <sirwillard_at_m...>

As Beman pointed out, this is off topic, so I'm going to cut huge 
parts out and keep my remarks to a minimum, but I think the info I 
have is helpful to Boost members.

>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?"

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.

>  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?)

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.

>  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.

MSDN and the Dinkumware web site.

>  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

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.

> given that there are test suites out there designed to pound on a 
compiler
> and its standard library.

One of the industries leading providers of such test suites happens 
to be Dinkumware.

>  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.

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.

>  It's encouraging to hear that
> you have had good success with support.

As would anyone who's attempted to receive it.  Seriously, Dinkumware 
takes good care of their customers and Mr. Plauger is very helpful 
personally.
 
> 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).

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.

Bill Kempf