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

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-18 17:44:26

From: "William Kempf" <sirwillard_at_[hidden]>
> Firstly, VC6 was released before the standard was ratified (it's that
> old).

Hmmm.  I remember buying Visual Studio 6 as soon as it was released for
sale (becuase I wanted to the new ATL OLEDB stuff), and as I recall that
was in September of 1998.  My copy of the standard shows ANSI ratification
on July 27, 1998.  Granted, I am going off of memory, here, so if you have
some explicit knowledge, I won't question it.

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

I realize that the library is old, and I'm not criticizing the old
library.  I am saying that it causes problems today and am lamenting that
Microsoft hasn't taken action to provide its users with a newer library.

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

All the standard C++ library files, including cstdlib that ships with VC,
are copywrited by P.J. Plauger.  That sure makes it look like std::size_t
et. al. were in Dinkumware's court.

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

It seems to all come to a matter of definitions and expectation of what
you get when you pay your money for a product.  I can understand where you
are coming from with your definitions and expectations, but I can
understand mine, too.

> [Several arguments about how Microsoft's hands were largely tied by
legality and avoiding large changes in service packs.]

Your points are very good.  I'm sure we all (MS library users) wish that
somehow MS could have found a way to make available a more standard
library when VC was released or soon thereafter.  Alas, 'twas not the
case, and so the VC library is what it is for purposes of comparison to
alternatives.

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

This is predicated on my understanding that files like cstdlib are part of
the Dinkumware library, as indicated above.  What part is Dinkumware
really doesn't matter though.  What matters is that boost has to work
around the out-of-the-box VC library, even with out-of-the-box meaning VC6
+ SP4 + vc_fixes.

> 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 SP4, though this is unlikely to make a
> difference as the STL is the same as that shipped with VC5).

The code intentionally does nothing useful.  It is just a minimal sample
to show the bug.  For me it doesn't compile under the VC6 library, but it
does under STLport.  Following is the entire snippet:

#include <vector>
#include <list>

int main() {
 std::vector<char> v;
 std::list<int> l;
 l.insert(l.end(), v.begin(), v.end());
 return 0;
}

The specific error I get is:
error C2664: 'void __thiscall std::list<int,class std::allocator<int>
>::insert(class std::list<int,class std::allocator<int>
>::iterator,unsigned int,const int &)' : cannot convert parameter 2 from
'char *' to 'unsigned
int'

The cause of the problem doesn't surprise me: member templates should have
been used but were not, probably because they were not available in an
earlier version of VC.  What surprises me is that this hasn't been fixed
in a SP.