Boost logo

Boost :

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
> 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,
> 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
> with some creativity, e.g. dump/depricate the legally ensnarled
> 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

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

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