SGI-STL or STL of VC++ 
Author Message
 SGI-STL or STL of VC++

I used 2 jears ago SGI-STL and the advantage was that during debugging
the source of STL became also visual.
As far as I know is that not possible with the STL of Visual C.
This advantage was also very interesting becouse it made it very easy
to understand the STL.

At this moment I am thinking to use the SGI-STL in VC 6.0 but I am not
sure that it is a very good idea.
What do you all think abouth it??
Is there someone with experience of this??
And is it possible to use it in vc 6.0(withouth creating other
compiling problems?) ??

thanks
kris

Sent via Deja.com
http://www.*-*-*.com/



Mon, 14 Jul 2003 16:48:26 GMT  
 SGI-STL or STL of VC++

Quote:

> I used 2 jears ago SGI-STL and the advantage was that during debugging
> the source of STL became also visual.
> As far as I know is that not possible with the STL of Visual C.

Code is code. I've never had a problem stepping through the VC++ STL
code.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)



Mon, 14 Jul 2003 22:05:19 GMT  
 SGI-STL or STL of VC++
Whereas I had. MS STL sometimes causes an INTERNAL COMPILER ERROR when you
try to instantiate the the standard objects such as lists, etc. with some
unusal classes. At the same time, the same code compiled OK with a clone of
SGI STL.

    I prefer to use STLPort v4 (www.stlport.org) - it's built from the
original SGI code and is compatible with a dozen of compilers.

    Gleb


Quote:

> > I used 2 jears ago SGI-STL and the advantage was that during debugging
> > the source of STL became also visual.
> > As far as I know is that not possible with the STL of Visual C.

> Code is code. I've never had a problem stepping through the VC++ STL
> code.

> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
> Contributing Editor, C/C++ Users Journal (http://www.cuj.com)



Thu, 17 Jul 2003 02:53:59 GMT  
 SGI-STL or STL of VC++

Quote:




> > > I used 2 jears ago SGI-STL and the advantage was that during debugging
> > > the source of STL became also visual.
> > > As far as I know is that not possible with the STL of Visual C.

> > Code is code. I've never had a problem stepping through the VC++ STL
> > code.

> Whereas I had. MS STL sometimes causes an INTERNAL COMPILER ERROR when you
> try to instantiate the the standard objects such as lists, etc. with some
> unusal classes. At the same time, the same code compiled OK with a clone of
> SGI STL.

This is, of course, a different issue than the one that I replied to.
But I'm sure you're right that the SGI implementation doesn't stress the
compiler as much as the VC++ implementation does, since the SGI version
implements less of what the C++ standard requires.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Thu, 17 Jul 2003 03:21:07 GMT  
 SGI-STL or STL of VC++
Less? Pure SGI implementation - maybe. But I was talking about STLport.
Here's what it's derived from:

 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Copyright (c) 1996-1999
 * Silicon Graphics Computer Systems, Inc.
 *
 * Copyright (c) 1997
 * Moscow Center for SPARC Technology
 *
 * Copyright (c) 1999, 2000
 * Boris Fomitchev

It has all that required locale, hash table, etc stuff pluse the new SGI
streams.
It doesn't take a lot of movements to adopt it - just unzip and add a new
include path above the VC98/Include. That's it! Surely, it supports all that
debugging features someone was talking about plus a lot of other
#define-configurable options.
    Actually, I didn't have any other troubls besides that INTERNAL COMPILER
ERRORs, but I needed parts of my code to be portable to a very old version
of GCC on FreeBSD - another reason why I migrated to STLport.

    Gleb


Quote:




> > > > I used 2 jears ago SGI-STL and the advantage was that during
debugging
> > > > the source of STL became also visual.
> > > > As far as I know is that not possible with the STL of Visual C.

> > > Code is code. I've never had a problem stepping through the VC++ STL
> > > code.

> > Whereas I had. MS STL sometimes causes an INTERNAL COMPILER ERROR when
you
> > try to instantiate the the standard objects such as lists, etc. with
some
> > unusal classes. At the same time, the same code compiled OK with a clone
of
> > SGI STL.

> This is, of course, a different issue than the one that I replied to.
> But I'm sure you're right that the SGI implementation doesn't stress the
> compiler as much as the VC++ implementation does, since the SGI version
> implements less of what the C++ standard requires.

> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)



Thu, 17 Jul 2003 04:45:47 GMT  
 SGI-STL or STL of VC++

Quote:

> It has all that required locale, hash table, etc stuff pluse the new SGI
> streams.

Be careful here: hash tables aren't part of the standard. The way to
determine standards conformance is to measure it with a validation
suite. You can't just look at the headers and make a list of classes.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Thu, 17 Jul 2003 04:55:08 GMT  
 SGI-STL or STL of VC++

Quote:
>     I prefer to use STLPort v4 (www.stlport.org) - it's built from the
> original SGI code and is compatible with a dozen of compilers.

I'm upset about the compile times of STLport. Dinkumware STL compiles 30%
faster.

Klaus



Thu, 17 Jul 2003 21:21:20 GMT  
 SGI-STL or STL of VC++
Do you mean the time of compilation if its DLLs, or of the programs using
STLport? If first, you only need to do it once. If the latter - what build
(Debug/Release/STL Debug) and what kind of linkage do you use
(static/dynamic)?
    For me think, pure dynamic release compiles quite fast...
    Of course, the folks who wrote it should have made some kinda trade-off
between portability and compilation effectiveness.

    Gleb


Quote:
> >     I prefer to use STLPort v4 (www.stlport.org) - it's built from the
> > original SGI code and is compatible with a dozen of compilers.

> I'm upset about the compile times of STLport. Dinkumware STL compiles 30%
> faster.

> Klaus



Thu, 17 Jul 2003 21:42:07 GMT  
 SGI-STL or STL of VC++

Quote:

> This is, of course, a different issue than the one that I replied to.
> But I'm sure you're right that the SGI implementation doesn't stress the
> compiler as much as the VC++ implementation does, since the SGI version
> implements less of what the C++ standard requires.

> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)

I'm sorry, but to claim that the STL that ships with VC++ is more
conformant, uses more C++ features, or is better in just about any other way
compared to STLport is just laughable.

Jeff



Tue, 22 Jul 2003 08:17:57 GMT  
 SGI-STL or STL of VC++

Quote:

> I'm sorry, but to claim that the STL that ships with VC++ is more
> conformant, uses more C++ features, or is better in just about any
other way
> compared to STLport is just laughable.

Rather than merely rollicking in mirth, wouldn't it be more productive
to actually support your statement with some facts?

I'm not saying you're right or wrong, mind you--just that we're not
taking a vote here, and more than bare assertion is desirable.



Tue, 22 Jul 2003 09:04:41 GMT  
 SGI-STL or STL of VC++

Quote:



> > This is, of course, a different issue than the one that I replied to.
> > But I'm sure you're right that the SGI implementation doesn't stress the
> > compiler as much as the VC++ implementation does, since the SGI version
> > implements less of what the C++ standard requires.

> > --
> > Pete Becker
> > Dinkumware, Ltd. (http://www.dinkumware.com)

> I'm sorry, but to claim that the STL that ships with VC++ is more
> conformant, uses more C++ features, or is better in just about any other way
> compared to STLport is just laughable.

And what data do you base this on? I suggest you wait a few weeks and
read the April, 2001 CUJ conformance review.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Tue, 22 Jul 2003 09:17:53 GMT  
 SGI-STL or STL of VC++

Quote:

> And what data do you base this on? I suggest you wait a few weeks and
> read the April, 2001 CUJ conformance review.

While you're waiting for it, I suggest you read the email archives behind the
article.  They used to be located at www.egroups.com in the group
hs_conformance, but it seems that Yahoo bought egroups, and now I can't find
the archives.  If somebody else can, perhaps they'll be so kind as to post the
URL here.  Last I heard, they were open to be viewed by anybody, but that may
have changed since Yahoo took over.

If you can get to the archive, it will give you some important background on
the data on which the article is based.  Without dwelling on the issue, I
consider the data so suspect, I withdrew from the project and urged that the
article not be published.  You would be astonished at the mistakes that were
identified, from missing include files in test suites to awarding a 50%
conformance rating to a feature that was completely missing in the tested
configuration.  And those are just the problems that were found and fixed.
Nobody knows how many other serious problems remain, and that's why I opposed
publication.

I have a lot of respect for Pete, and I know that he believes what he writes.
At the same time, it's important to recognize that he works for Dinkumware,
and Dinkumware has a lot riding on that article, because they participated as
both a library vendor and a conformance tester.  This does NOT mean I think
that Pete is trying to mislead anybody.  I don't.  But that doesn't change the
fact that both he and his company have a conflict of interest.  (They
acknowledged this conflict up front, and it is explicitly pointed out in the
article.  At least it was in the last draft I saw).

I represent an extreme and minority viewpoint, but I feel strongly enough
about this to urge everybody who reads that article to read it VERY
carefully.  Look especially for disclaimers and caveats on the meaning of the
results and the rankings.  Personally, I think the results are meaningless.
Others involved in the project disagree.  I suggest you examine the data and
come to your own conclusions.

Scott

PS - I don't want to get into a fight about this, so this will be my only
posting on this topic.  I didn't plan to say anything, but since Pete has
referred to the upcoming article twice in a way that suggests it will shed
light on conformance issues, I think it's important to point out that, in my
opinion, the light is quite strongly tainted.



Tue, 22 Jul 2003 10:11:08 GMT  
 SGI-STL or STL of VC++

Quote:



> > I'm sorry, but to claim that the STL that ships with VC++ is more
> > conformant, uses more C++ features, or is better in just about any
> other way
> > compared to STLport is just laughable.

> Rather than merely rollicking in mirth, wouldn't it be more productive
> to actually support your statement with some facts?

VC 6.0 STL is about 5 years old and was released before C++ standard
became a standard. STLPort is quite recent, on the other hand.
This alone should suffice to justify what Jeff wrote.

Dmitrii.



Tue, 22 Jul 2003 21:53:44 GMT  
 SGI-STL or STL of VC++

Quote:

> PS - I don't want to get into a fight about this, so this will be my only
> posting on this topic.  I didn't plan to say anything, but since Pete has
> referred to the upcoming article twice in a way that suggests it will shed
> light on conformance issues, I think it's important to point out that, in my
> opinion, the light is quite strongly tainted.

Unlike the typical post here, which says something like "since STLport
is much newer than the VC++ 6.0 library, it must be better."

The article discusses the results of running three conformance test
suites against most of the compilers and libraries that are out there.
There were some problems with the way one of the suites was used, and I
was one of the loudest voices complaining about this. Nevertheless, the
results of all three tests were quite consistent in their rankings of
compilers and libraries. There are also comments from the suppliers of
most of those compilers and libraries in the article. I think people can
judge for themselves.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Tue, 22 Jul 2003 23:35:00 GMT  
 SGI-STL or STL of VC++

Quote:

> I have a lot of respect for Pete, and I know that he believes what he writes.
> At the same time, it's important to recognize that he works for Dinkumware,
> and Dinkumware has a lot riding on that article, because they participated as
> both a library vendor and a conformance tester.  This does NOT mean I think
> that Pete is trying to mislead anybody.  I don't.  But that doesn't change the
> fact that both he and his company have a conflict of interest.  (They
> acknowledged this conflict up front, and it is explicitly pointed out in the
> article.  At least it was in the last draft I saw).

You can't have it both ways. Since you cite no facts to indicate any
actual bias in any of the results, your suggestion that our results (our
test suite is one of the three that provided data for the article) are
somehow biased because of a conflict of interest is exactly the sort of
ungrounded innuendo that I have been objecting to throughout this
thread. Shame on you.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Tue, 22 Jul 2003 23:44:51 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Conflict between VC 7 STL and SGI STL - how to resolve

2. ATL conflict between VC 7 STL and SGI STL - how to resolve

3. VC++ STL v/s SGI STL Performance ???

4. Porting code from SGI STL to MSVC STL

5. sgi STL & vc++ 6.0

6. VC++ and STL (SGI Implementation)

7. SGI STL and VC++ 5.0

8. VC 5.0 and SGI STL

9. SGI STL w/vc 5.0?

10. SGI-STL and VC++ 5.0

11. VC++ and STL (SGI Implementation)

12. how to use stl of sgi in VC++?

 

 
Powered by phpBB® Forum Software