Re: Recommended STL implementations for MSVC

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-18 18:06:51

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

Semantics.  It was "released" in the sense that it was finalized and 
sent to production before the standard was ratified.  This isn't the 
same as "released" in the sense that you could purchase it and have a 
copy in your hands before then.

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

Sort of.  The <c*> files are very thin wrappers around the MS 
supplied C headers.  I don't know why Dinkumware went to this level 
while not going all the way, though "going all the way" can lead to 
numerous issues for end users considering how the standard C headers 
are implemented.
 
> > [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.

Which I don't have a complaint about.  Now when VC7 hits the streets 
we'll talk again ;).
 
> > 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.

Then we choose to lay the blame on different shoulders.  These 
particular work arounds are caused by MS, not Dinkumware, IMHO.
 
> > 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'

Ahhh... I missed the different contained types.
 
> 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.

VC5 didn't support member templates.  This behavior is documented in 
the online help as a work around, not as a bug (look at list::insert 
in the online help).  So we're back to the legal/business reasons why 
this "bug" exists.  This is one that you can expect to be fixed with 
the release of VC7.

Bill Kempf