 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
benlucas99@hotmail.com
Guest
|
 Posted: Thu Dec 01, 2005 4:30 pm Post subject: VC++ STL library status |
 |
|
Hi All,
What is the standards compliancy status with the latest MS STL library?
What problems still exist? Also, could somebody explain which class of
win32 apps previously had to use 3rd party libraries (eg STLPort)? I
know there were thread safety issues in older releases but there were
also plenty of multithreaded apps using said library without problem.
Did the issue only arise when porting an app reliant on a 'broken' part
of MS STL implementation?
tia,
Ben
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
P.J. Plauger
Guest
|
| Posted: Fri Dec 02, 2005 12:36 am Post subject: Re: VC++ STL library status |
|
|
<benlucas99 (AT) hotmail (DOT) com> wrote
| Quote: | What is the standards compliancy status with the latest MS STL library?
What problems still exist?
|
It has been essentially completely conforming since V7.1
(.NET 2003). The latest MS version is V8 (.NET 2005).
| Quote: | Also, could somebody explain which class of
win32 apps previously had to use 3rd party libraries (eg STLPort)?
|
None *needed* to. Some people *chose* to use STLPort. For V6,
you got some missing member template functions and hash tables.
(Those have also been available from Dinkumware for V6 for
many years now.) V7, like V6, does not support template partial
specialization, so some features were offered in alternate
forms in the library shipped with V7.
| Quote: | I
know there were thread safety issues in older releases but there were
also plenty of multithreaded apps using said library without problem.
Did the issue only arise when porting an app reliant on a 'broken' part
of MS STL implementation?
|
V6 used a COW string which was unprotected for multithreading. A patch
for this problem has long been available at:
http://www.dinkumware.com/vc_fixes.html
V7 onward has had a string class with no such multithreading issues.
HTH,
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ulrich Eckhardt
Guest
|
| Posted: Fri Dec 02, 2005 12:53 am Post subject: Re: VC++ STL library status |
|
|
[email]benlucas99 (AT) hotmail (DOT) com[/email] wrote:
| Quote: | What is the standards compliancy status with the latest MS STL library?
|
The libraries are supplied by Dinkumware. From what I can tell, the one
supplied with VC7 was much better than the one supplied with VC6 and newer
ones are even better.
| Quote: | What problems still exist? Also, could somebody explain which class of
win32 apps previously had to use 3rd party libraries (eg STLPort)?
|
Simple: the class of applications that relied on features that were buggy
in earlier versions, simple as that. Also, I might notice, IOstreams of
STLport are faster than the ones that come with VC6 and, AFAICT, even
faster than the newer ones.
| Quote: | I know there were thread safety issues in older releases but there were
also plenty of multithreaded apps using said library without problem.
Did the issue only arise when porting an app reliant on a 'broken' part
of MS STL implementation?
|
The Dinkumware website has several pages devoted to bugfixes for the VC6
libraries (which are mainly the ones that created the 'bad' reputation of
'MS STL', probably in combination with lots of FUD concerning C++ and/or
template libraries in general). I suggest you read those. I'd also suggest
you take a look at the microsoft.* news hierarchy (if your newsserver has
them), there is a group devoted to VC's standardlibrary in general (I
forgot its name, but it contains 'stl').
Uli
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Maxim Yegorushkin
Guest
|
| Posted: Fri Dec 02, 2005 5:07 pm Post subject: Re: VC++ STL library status |
|
|
P.J. Plauger wrote:
[]
Apart from this the library that was shipped with VC6 had a bunch of
problems which prevented it from being usable for any decent (event at
that time) C++ programming. Nonconforming std::auto_ptr<> (without
auto_ptr::reset) and std::basic_string<> first spring into mind, there
were also problems with static members in std::map<> implementation
which caused problems when passing an instance between modules and
numerous other problems. One simply had no choice but to use STLPort
with VC6.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
P.J. Plauger
Guest
|
| Posted: Sat Dec 03, 2005 11:30 am Post subject: Re: VC++ STL library status |
|
|
"Maxim Yegorushkin" <maxim.yegorushkin (AT) gmail (DOT) com> wrote
| Quote: | P.J. Plauger wrote:
[]
V6 used a COW string which was unprotected for multithreading. A patch
for this problem has long been available at:
http://www.dinkumware.com/vc_fixes.html
Apart from this the library that was shipped with VC6 had a bunch of
problems which prevented it from being usable for any decent (event at
that time) C++ programming.
|
And yet it was used...
| Quote: | Nonconforming std::auto_ptr<> (without
auto_ptr::reset) and std::basic_string<> first spring into mind,
|
There was no *standard* when the V6 library froze, so it's hard
for the library to be nonconforming. In fact, the library *did*
conform exactly to the then current draft at freeze time, FWIW.
V6 has proved to have a very long life, and drafts of the C++
Standard proved to have a very short life -- thus the apparent
lack of "conformance".
| Quote: | there
were also problems with static members in std::map<> implementation
which caused problems when passing an instance between modules and
numerous other problems.
|
Same issue as COW strings -- the first couple of libraries we
delivered to Microsoft were not required to be thread safe,
in the sense that is now widely accepted (thanks to SGI).
The free fix for this has been at our web site for years
(see link above).
| Quote: | One simply had no choice but to use STLPort
with VC6.
|
One could also use the upgrade library available at our web site
and do even better. And that's even more true today than in the
past. Again FWIW, STLport has been minimally supported for the
past several years now, to put it politely.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Dec 04, 2005 5:28 pm Post subject: Re: VC++ STL library status |
|
|
Maxim Yegorushkin wrote:
| Quote: | P.J. Plauger wrote:
[]
V6 used a COW string which was unprotected for
multithreading. A patch for this problem has long been
available at:
http://www.dinkumware.com/vc_fixes.html
Apart from this the library that was shipped with VC6 had a
bunch of problems which prevented it from being usable for any
decent (event at that time) C++ programming.
|
If I recall right, VC++ 6.0 itself had a number of problems
which prevented it from being used for the more advanced
programming techniques being invented at the time. For
established techniques being used in robust production code,
it's still being used by a lot of people today, with the library
that came with it.
| Quote: | Nonconforming std::auto_ptr<> (without auto_ptr::reset) and
std::basic_string<> first spring into mind, there were also
problems with static members in std::map<> implementation
which caused problems when passing an instance between modules
and numerous other problems. One simply had no choice but to
use STLPort with VC6.
|
For advanced programming, one simply had no other choice but to
use some other compiler. (To be fair to VC++ 6.0, most of the
advanced techniques were based on features defined in the
standard after the compiler was first released.) Most of the
problems I encountered with VC++ 6.0 were in the compiler, not
in the library. (The library was decidedly better than that
which came which g++ 2.95.2, which was more or less contemporary
with it. I never actually succeeded in getting STLport to work
with any compiler, so I can't compare it.)
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Stephen Howe
Guest
|
| Posted: Tue Dec 06, 2005 10:42 am Post subject: Re: VC++ STL library status |
|
|
| Quote: | Apart from this the library that was shipped with VC6 had a bunch of
problems which prevented it from being usable for any decent (event at
that time) C++ programming. Nonconforming std::auto_ptr<> (without
auto_ptr::reset) and std::basic_string<> first spring into mind...
|
That is somewhat unfair chronologically. VC6 came out before the standard
was finalised.
auto_ptr changed 3 times before the standard was released.
| Quote: | ..., there were also problems with static members in std::map
implementation
which caused problems when passing an instance between modules and
numerous other problems.
|
True. You could download a patch from Dinkumware's site.
| Quote: | One simply had no choice but to use STLPort with VC6.
|
STLPort was fully conformant at the time was it?
Stephen Howe
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
