Boost logo

Boost :

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
> dates should be considered for evaluating the authors' competency,
> are not relavent to the question of "What should I use today, if I
> 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
> of the Floridian level of subjectivity (e.g. are the missing
> 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
> haven't been fixed is inditive of a component that is not well

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
> 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
> 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
> portable, which would make the library poorly supported, IMHO. I
> contacted Microsoft regarding STL, discouraged by all the news I
> about their refusal to put a fix for std::string in the the runtime
> 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
> 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
> I hear is better in STLport, too, although I haven't benchmarked

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at