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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2000-12-18 21:20:26

I'll say this just once.  I NEVER suggested using the version that comes 
with VC6.  I said I used the UPDATE from Dinkumware.  Comparing a product 
which MicroSloth refused to update over several years with something 
released quite recently is absurd.  That you don't care for what MicroSloth 
(NOT Dinkumware) is shipping is obvious.  I'm not fond of it either, else I 
wouldn't have updated it.

If you haven't used it... then perhaps you should refrain from commenting.

At Monday 00/12/18 09:26, you wrote:
>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.
>
>
>
>
>

Victor A. Wagner, Jr.
Secretary, Wyoming Libertarian Party
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"