Re: Recommended STL implementations for MSVC

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-18 16:27:02

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

Firstly, VC6 was released before the standard was ratified (it's that 
old).  The standard library was released before the standard even 
went into final draft, and at the time was the most standards 
compliant library available.  Your criticism, at this time, is 
unfounded, though I share your pain.  Now, when VC7 comes out and the 
compiler still doesn't have partial template specialization, I'll 
join you in criticizing MS.  However, at that time the compiler will 
ship with the newest Dinkumware library and should be standards 
compliant, or at least as compliant as possible with the compiler 
it's written for.

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

Again, it was VERY up to date at the time it was released.
 
> 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.

Again, Dinkumware supplied an STL implementation, not a full C++ 
standards implementation.  It was not the place of the Dinkumware 
library to define the legacy C functions/types within the std 
namespace.  This one is a failing of MS's, and I'll join you in 
criticizing them here, though at the time few other compilers had 
done this level of conformance either.
 
> My point is that the library is poorly supported, in that there 
aren't any
> fixes in the VC6 service packs.

A)  This isn't support, but maintenance.
B)  This was prevented by legal problems that were out of the control 
of both MS and Dinkumware.
C)  Since VC7 will make these changes I'm not sure you can even use 
maintenance as a round about way of arguing that it's not supported.

>  Why that is the case isn't relavent to
> the the bottom line of making code work.

Here I differ with you.  Dinkumware provided support, even if they 
couldn't provide MS with maintenance releases, so the known bugs 
could be fixed by the user.  Unfortunately this didn't include 
radical changes made by the standard after the implementation was 
created, such as std::auto_ptr semantics.  However, those changes are 
available in the updated library, which shows both maintenance and 
support on the behalf of Dinkumware.

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

They were under contractual obligations to Dinkumware that prevented 
this.  Unless they sued for breach of contract, thus severing 
themselves from the company that was poised to become the leader in 
this area, they couldn't use another implementation.  I'm not a 
lawyer, but I'm not sure they could even successfully sue for breach 
of contract here.  Besides, at the time there was no more compliant 
version available.  MS, rightfully, does not make major changes to 
SPs, so this wasn't an option later when other implementations became 
available.

>  Obviously, there's a cost/quality tradeoff here, and Microsoft
> went the route of saving the bucks.

Hardly.  They could have gone back to supplying the HP library or 
used the free STLPort and saved money in the long run.  They are 
paying a price for licensing the Dinkumware library and would not 
save money by continuing to use them.  So it's not a tradeoff, it's 
just a technical, legal and business reality.

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

They matched the standard at the time the library was released.

Again, there really aren't that many things that are non-standard 
here.  Nor are there that many bugs.  It's unfortunate that what does 
exist has been locked up in legal and business stagnation, but the 
complaints are unfounded regardless, IMHO.
 
> 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.

MS is woefully behind here, unfortunately.  One can only hope that 
most of this is fixed with VC7, though we know that the compiler 
still won't be standards conformant.

Bill Kempf

P.S.  You've not pointed out where Boost has needed work arounds 
because of the Dinkumware STL shipped with VC++.

P.P.S.  The "list insert" bug you posted is, frankly, a bug on your 
part.  The vector is empty, so nothing will occur.  The code you 
supplied thus compiles and runs correctly.  Fixing this error, so 
that something will truly be inserted, also compiles and runs with no 
error on VC++ (I'm using VC6 SP 4, though this is unlikely to make a 
difference as the STL is the same as that shipped with VC5).