New STL implementation from SGI

New STL implementation from SGI

[Peter Simons]

-----BEGIN PGP SIGNED MESSAGE-----

I just checked the latest STL release from SGI and was pleased to see
that auto_ptr and a few other things have been fixed/added. I notice,
though, that the latest egcs snapshot (obtained via CVS today) does
still have the old STL implementation. Are there any plans to upgrade
to the new STL before the next release?

	-peter

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1

iQCVAwUBNZuT9g9HL1s0103BAQF25AP+PFM/C4QDrcTca5IxcXCEYWu0k1GP3yqM
a2gMdrWyrhs97AkA0aaAZjOWTIcAmZ5guaItlxyPYCwHdAF3FBzmKWIPwBWyngSp
KYGtk7uwluH5KaZCxCiO5ICM47W6oX732S8fwEoNuhrZYi9ARFZxVBeL1xvXyy82
WTTQuXv+/wM=
=jnE4
-----END PGP SIGNATURE-----

Re: New STL implementation from SGI

[Jeffrey A Law]

  In message < x7sokk1h55.fsf@peti.gmd.de >you write:
  > -----BEGIN PGP SIGNED MESSAGE-----
  > 
  > I just checked the latest STL release from SGI and was pleased to see
  > that auto_ptr and a few other things have been fixed/added. I notice,
  > though, that the latest egcs snapshot (obtained via CVS today) does
  > still have the old STL implementation. Are there any plans to upgrade
  > to the new STL before the next release?
I doubt we'd want to make that kind of change since egcs-1.1 is feature
frozen.

I think upgrading the STL code would be wise for egcs-1.2.  

jeff

Re: New STL implementation from SGI

[H.J. Lu]

> 
> 
>   In message < x7sokk1h55.fsf@peti.gmd.de >you write:
>   > -----BEGIN PGP SIGNED MESSAGE-----
>   > 
>   > I just checked the latest STL release from SGI and was pleased to see
>   > that auto_ptr and a few other things have been fixed/added. I notice,
>   > though, that the latest egcs snapshot (obtained via CVS today) does
>   > still have the old STL implementation. Are there any plans to upgrade
>   > to the new STL before the next release?
> I doubt we'd want to make that kind of change since egcs-1.1 is feature
> frozen.
> 
> I think upgrading the STL code would be wise for egcs-1.2.  
> 

What is the time table for 1.2? FYI, I know some C++ codes use
auto_ptr. I have to fix it in egcs 1.0.3. It may be a good idea
to include a better STL in egcs 1.1, since more and more C++ codes
are using STL, even if it means 1.1.1. Delaying it means people
may say "don't use STL in egcs and get a real one in stead". As far
as they know, STL in egcs is broken since 1.0 and it is broken.


-- 
H.J. Lu (hjl@gnu.org)

Re: New STL implementation from SGI

[Jeffrey A Law]

  In message < m0ytCni-000266C@ocean.lucon.org >you write:
  > What is the time table for 1.2?
It depends on how things go with egcs-1.1.  We don't know yet.

   > FYI, I know some C++ codes use
  > auto_ptr. I have to fix it in egcs 1.0.3. It may be a good idea
  > to include a better STL in egcs 1.1, since more and more C++ codes
  > are using STL, even if it means 1.1.1. Delaying it means people
  > may say "don't use STL in egcs and get a real one in stead". As far
  > as they know, STL in egcs is broken since 1.0 and it is broken.
Yes, I fully understand this issue.  I just don't think now is the
time to bring in a bunch of code we have never built or tested.

Ultimiately it's Jason's call, but I would personally recommend against
importing this code for egcs-1.1.
jeff

Re: New STL implementation from SGI

[Ben Scherrey]

I'm not sure if I fully understand what we're talking about. Do you
mean integrating the latest STL for distribution or for use in actually
implementing the compiler? I haven't looked to see if egcs is using any
STL code internally so this may be an ignorant question.
	I agree that bringing it in might not be warranted for internal use.
However, If we're talking about using it for distribution of the STL
library than I'd hope that it made it into 1.1 as everyone out there is
going to be trying to build it on their own anyway.

	thanx,

		Ben Scherrey
		Proteus Technologies, Inc.

Jeffrey A Law wrote:
> Yes, I fully understand this issue.  I just don't think now is the
> time to bring in a bunch of code we have never built or tested.
> 
> Ultimiately it's Jason's call, but I would personally recommend against
> importing this code for egcs-1.1.
> jeff

Re: New STL implementation from SGI

[Jeffrey A Law]

  In message < 35A19F9D.F5D3B9CC@gte.net >you write:
  > I'm not sure if I fully understand what we're talking about. Do you
  > mean integrating the latest STL for distribution or for use in actually
  > implementing the compiler?
No, integrating it for use by folks that use egcs.


  > 	I agree that bringing it in might not be warranted for internal use.
  > However, If we're talking about using it for distribution of the STL
  > library than I'd hope that it made it into 1.1 as everyone out there is
  > going to be trying to build it on their own anyway.
That's fine, they're welcome to try, but IMHO, it's unwise to try and
suck in a new STL release at this point.  Unless we want to push back
the release schedule again (which then runs the risk of hitting the
next Cygnus EOQ).

Getting the egcs-1.1 release out in August is still the target, if we
miss it, it's likely to fall into October due to Cygnus EOQ concerns.

Re: New STL implementation from SGI

[Nathan Myers]

Jeffrey A Law wrote:
> IMHO, it's unwise to try and
> suck in a new STL release at this point.  Unless we want to push back
> the release schedule again (which then runs the risk of hitting the
> next Cygnus EOQ).
> 
> Getting the egcs-1.1 release out in August is still the target, if we
> miss it, it's likely to fall into October due to Cygnus EOQ concerns.

The new release fixes bugs and is substantially closer to conformance.  
I'd like to see somebody try integrating it before any decision is made. 
It probably will fold in easily, as SGI has been responsive to the needs 
of Egcs users.  The version in the rewrite (which is identical in all but
packaging details) passes the test suites fine.

People using STL have learned not to expect binary compatibility from one 
release to the next.  Eventually it will stabilize, but it does no harm
to remind people that we're not near there yet.

Nathan Myers
ncm@cygnus.com

Re: New STL implementation from SGI

[Alex Buell]

On Mon, 6 Jul 1998, H.J. Lu wrote:

> What is the time table for 1.2? FYI, I know some C++ codes use
> auto_ptr. I have to fix it in egcs 1.0.3. It may be a good idea
> to include a better STL in egcs 1.1, since more and more C++ codes
> are using STL, even if it means 1.1.1. Delaying it means people
> may say "don't use STL in egcs and get a real one in stead". As far
> as they know, STL in egcs is broken since 1.0 and it is broken.

Seconded, the sooner this is included in egcs, the better, as people
won't have to go commercial for their STL needs.  

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Smoke some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk

Re: New STL implementation from SGI

[Carlo Wood]

I'd like to see the latest STL be added to egcs-1.1 too.
Or at least we should try it, and see if anything obvious
breaks.  Chances are that it will work immedeately, and
then a bug of a more difficult type (that temporally will
stay hidden) isn't as bad as releasing the compiler with
an old STL.

Just my $0.02,

 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: New STL implementation from SGI

[B. James Phillippe]

On Tue, 7 Jul 1998, Carlo Wood wrote:

> I'd like to see the latest STL be added to egcs-1.1 too.
> Or at least we should try it, and see if anything obvious
> breaks.  Chances are that it will work immedeately, and
> then a bug of a more difficult type (that temporally will
> stay hidden) isn't as bad as releasing the compiler with
> an old STL.
> 
> Just my $0.02,

If "me too"'s count here, I'll throw my two cents in with yours.  I think
it's a bigger deal to get the STL in; too many people are starting to ask
for it.

-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGT Inc.
http://earth.terran.org/~bryan

Re: New STL implementation from SGI

[Martin von Loewis]

> I'd like to see the latest STL be added to egcs-1.1 too.
> Or at least we should try it, and see if anything obvious
> breaks.

I have a concern about binary compatibility. Most likely,
instantiations of templates will introduce slight
incompatibilities. So people might have to recompile even more stuff,
or run into non-obvious traps.

So I'd rather keep the incompatible changes together, so that people
will surely know at link time that things changed, instead of breaking
everything at every release.

Of course, there are claims that egcs g++ 1.1 will be incompatible on
some platforms, anyway, so this might not be an issue.

Martin

Re: New STL implementation from SGI

[H.J. Lu]

> 
> > I'd like to see the latest STL be added to egcs-1.1 too.
> > Or at least we should try it, and see if anything obvious
> > breaks.
> 
> I have a concern about binary compatibility. Most likely,
> instantiations of templates will introduce slight
> incompatibilities. So people might have to recompile even more stuff,
> or run into non-obvious traps.
> 
> So I'd rather keep the incompatible changes together, so that people
> will surely know at link time that things changed, instead of breaking
> everything at every release.
> 

That is what is my interface patch for.

-- 
H.J. Lu (hjl@gnu.org)

Re: New STL implementation from SGI

[Joe Buck]

> > I'd like to see the latest STL be added to egcs-1.1 too.
> > Or at least we should try it, and see if anything obvious
> > breaks.
> 
> I have a concern about binary compatibility. Most likely,
> instantiations of templates will introduce slight
> incompatibilities. So people might have to recompile even more stuff,
> or run into non-obvious traps.

I'm afraid that egcs-1.1 will already break binary compatibility on at
least some platforms (linux-glibc2), because of thread-safe exceptions.

> So I'd rather keep the incompatible changes together, so that people
> will surely know at link time that things changed, instead of breaking
> everything at every release.

The real issue (whenever we decide to pick up the new STL) is the string
class: do we use the SGI one, the existing one, or the one Ulrich Drepper
is working on?

Re: New STL implementation from SGI

[Ulrich Drepper]

jbuck@synopsys.com (Joe Buck) writes:

> The real issue (whenever we decide to pick up the new STL) is the string
> class: do we use the SGI one, the existing one, or the one Ulrich Drepper
> is working on?

Actually Nathan is doing the work.  Anyhow, we will not completely
abandom the version we have in the moment since on some platforms
space consumption is more important than speed and here the current
implementation we have is superior.

To decide which version we use somebody will have to make measurements
with a thread-safe version of either implementation.  My guess is that
the SGI version is faster since we don't have to care for locking.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: New STL implementation from SGI

[Joe Buck]

I wrote:

> > The real issue (whenever we decide to pick up the new STL) is the string
> > class: do we use the SGI one, the existing one, or the one Ulrich Drepper
> > is working on?

Ulrich replies:

> Actually Nathan is doing the work.  Anyhow, we will not completely
> abandom the version we have in the moment since on some platforms
> space consumption is more important than speed and here the current
> implementation we have is superior.

Yes, the SGI implementation is basically a slightly different
vector<charT> that is always null-terminated, meaning that there is no
reference counting and string copy is a deep copy operation, but
conversion to/from const char* is cheaper.  I would prefer something that
works more like what we have (reference counting).

However, I am discouraged by the fact that we still don't have anything
available for testing.  I'd like to encourage the developers (e.g. you and
Nathan) to make available even partially working code so that others can
assist with testing, suggestions for improvement, etc.

> To decide which version we use somebody will have to make measurements
> with a thread-safe version of either implementation.  My guess is that
> the SGI version is faster since we don't have to care for locking.

Actually I suspect that the SGI version will be slower as well as require
more memory in some applications: if copying strings from place to place
is common, but concatenation is less common, a deep copy may cost more
than a reference count adjustment.  But other operations are faster
(e.g. get the string length without any indirection, c_str() is free etc).
Because of the different implementation tradeoffs, just tell me which
implementation you want to win and I will write you an appropriate
benchmark. :-)

Re: New STL implementation from SGI

[Ulrich Drepper]

Joe Buck <jbuck@Synopsys.COM> writes:

> I'd like to encourage the developers (e.g. you and Nathan) to make
> available even partially working code so that others can assist with
> testing, suggestions for improvement, etc.

You can believe me that I would prefer tis as well.  If nothing bad
happens this wish will be reality soon.  The problem is that Nathan is
currently working almost alone on this since I'm working on a
different project in the moment.

> Because of the different implementation tradeoffs, just tell me which
> implementation you want to win and I will write you an appropriate
> benchmark. :-)

This is why I want to see both implementations in the final package.
But I fear that we'll get compatibility problems then since different
machines running the same system can have different string code from
the instanciations in the libstdc++.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: New STL implementation from SGI

[Pieter Nagel]

On Thu, 9 Jul 1998, Joe Buck wrote:

> Actually I suspect that the SGI version will be slower as well as require
> more memory in some applications: if copying strings from place to place
> is common, but concatenation is less common,

Ouch! I've been happily using strings to pass around megabyte-sized
blobs of data, but reading about the SGI string class makes me want
to run and reread the spec to check on how portable my use is - I
thought C++ strings were *supposed* to have reference countng
semantics.

I'm all for including different implementations of the string class.
How about renaming basic_string to shallow_copy_basic_string and
deep_copy_basic_string respectively, and then have a mechanism to
choose which one is typedefed to basic_string - thereby allowing one
to write code that uses *both*?

-- 
     ,_
     /_)              /| /
    /   i e t e r    / |/ a g e l

Re: New STL implementation from SGI

[Joe Buck]

> Ouch! I've been happily using strings to pass around megabyte-sized
> blobs of data, but reading about the SGI string class makes me want
> to run and reread the spec to check on how portable my use is - I
> thought C++ strings were *supposed* to have reference countng
> semantics.

This shows why Stepanov's (inventor of STL) notion of specifying
performance guarantees for library algorithms in standards is so
important.  Unfortunately this was only done for the STL part; there are
no performance guarantees on string operations, I'm afraid.
(Had the committee required that string assignment is constant time
and not dependent on length, this would have forced a reference-counting
or similar implementation).

> I'm all for including different implementations of the string class.
> How about renaming basic_string to shallow_copy_basic_string and
> deep_copy_basic_string respectively, and then have a mechanism to
> choose which one is typedefed to basic_string - thereby allowing one
> to write code that uses *both*?

Ah, but there is a *third* implementation possibility: you could base
your string class on the SGI "rope" class, which gives you yet another
performance tradeoff.  I supposed you could call the rope implementation
"lots_of_pieces_string".

Since the standard says there is just basic_string, any chosen mechanism
would have to compile standard programs and not pollute the namespace.
If you just do a #define, it is easy -- but the user has to use the same
#define for everything in the program.  If there is a controllable
typedef, you could do different definitions in different compilation units
as long as you don't pass strings between units.

Of course, constructors could be added to convert one form of string into
another -- however, we would have to be careful not to introduce
ambiguities by doing this.

But: some of us have to write code that runs through multiple compilers,
so we can only assume that there is one string class, with unknown
implementation.

Re: New STL implementation from SGI

[Nathan Myers]

Pieter Nagel wrote:
> 
> On Thu, 9 Jul 1998, Joe Buck wrote:
> 
> > Actually I suspect that the SGI version will be slower as well as require
> > more memory in some applications: if copying strings from place to place
> > is common, but concatenation is less common,
> 
> Ouch! I've been happily using strings to pass around megabyte-sized
> blobs of data, but reading about the SGI string class makes me want
> to run and reread the spec to check on how portable my use is - I
> thought C++ strings were *supposed* to have reference countng
> semantics.

Unfortunately the (sub-)committee waffled on this issue, and tried to write
the spec to tolerate either implementation, to the detriment of both.
(basic_string<> is easily the least inspiring component in the library.)

If you want a reliably reference-counting string, the "rope" from SGI-STL
might be your best bet.  It will be in the rewritten library.

> I'm all for including different implementations of the string class.
> How about renaming basic_string to shallow_copy_basic_string and
> deep_copy_basic_string respectively, and then have a mechanism to
> choose which one is typedefed to basic_string - thereby allowing one
> to write code that uses *both*?

Unfortunately C++ has no aliasing feature for templates.  However, it's
possible that basic_string<> could be *derived* from one of the above.
I will look into this; it would require some cooperation from Matt at SGI.

The ideal would be if both could be present at once (though in different
files), but I doubt that is possible in this case.

Nathan Myers
ncm@cantrip.org

Re: New STL implementation from SGI

[Nathan Myers]

Joe Buck wrote:

> > To decide which version we use somebody will have to make measurements
> > with a thread-safe version of either implementation.  My guess is that
> > the SGI version is faster since we don't have to care for locking.
> 
> Actually I suspect that the SGI version will be slower as well as require
> more memory in some applications: if copying strings from place to place
> is common, but concatenation is less common, a deep copy may cost more
> than a reference count adjustment. 

In particular, returning a string from a function will be substantially
more expensive.

> But other operations are faster
> (e.g. get the string length without any indirection, c_str() is free etc).
> Because of the different implementation tradeoffs, just tell me which
> implementation you want to win and I will write you an appropriate
> benchmark. :-)

Compared with the rewritten version, length() or c_str() should be about 
equally fast in either case. 

Nathan Myers
ncm@cantrip.org

Re: New STL implementation from SGI

[Joe Buck]

> > I think upgrading the STL code would be wise for egcs-1.2.  
> > 
> 
> What is the time table for 1.2?

Possibly we should attempt a smaller cycle for 1.2.  But I'd like for
1.2 to be the release which finally has the new libstdc++.

> FYI, I know some C++ codes use auto_ptr.
> I have to fix it in egcs 1.0.3.

And I know some codes that use namespaces.  I would like to get the
new STL out too, but you have to decide if 1.1 is to be a stable
release or not.

Now, for classes that previously did not exist (like auto_ptr) it would
be risk-free to add them from the new STL -- it cannot break any old
code.  If you only want auto_ptr, then we could do that.

> It may be a good idea
> to include a better STL in egcs 1.1, since more and more C++ codes
> are using STL, even if it means 1.1.1.

We can't introduce new features into 1.1.1.  If we do something major
like a new STL, it is 1.2.  Note that this doesn't say anything about
timing; 1.2 could come one month after 1.1 if it is ready.

> Delaying it means people
> may say "don't use STL in egcs and get a real one in stead".

I think that the new STL should go into the snapshots ASAP.  But it
can't go directly into the release -- that would be irresponsible
(inadequate testing).

> As far
> as they know, STL in egcs is broken since 1.0 and it is broken.

What do you mean?  The existing STL works quite well.  True, there
have been improvements.

We will have to mention that the egcs 1.1 release is an old SGI release,
which is kind of embarrassing.  If you want the new SGI release into
egcs 1.1, this is possible -- *if* we move all the dates back (feature
freeze will have been extended).

Unfortunately there are some issues: the new SGI STL has a standard
string class.  But we already have a string class.  And Uli has a new
(yet a third) standard string class.  Which one should we use?

Maybe it's best to release what we have, and *then* settle issues like
this.

Re: New STL implementation from SGI

[H.J. Lu]

> 
> 
> > > I think upgrading the STL code would be wise for egcs-1.2.  
> > > 
> > 
> > What is the time table for 1.2?
> 
> Possibly we should attempt a smaller cycle for 1.2.  But I'd like for
> 1.2 to be the release which finally has the new libstdc++.
> 
> > FYI, I know some C++ codes use auto_ptr.
> > I have to fix it in egcs 1.0.3.
> 
> And I know some codes that use namespaces.  I would like to get the
> new STL out too, but you have to decide if 1.1 is to be a stable
> release or not.
> 
> Now, for classes that previously did not exist (like auto_ptr) it would
> be risk-free to add them from the new STL -- it cannot break any old
> code.  If you only want auto_ptr, then we could do that.
> 

Yes.

H.J.

auto_ptr, new warning? (was: New STL implementation from SGI)

[Carlo Wood]

| > Now, for classes that previously did not exist (like auto_ptr) it would
| > be risk-free to add them from the new STL -- it cannot break any old
| > code.  If you only want auto_ptr, then we could do that.

A note on auto_ptr... It's an unsafe class imho.
The problem I have with it is that when it accidently is
used for a temporary, then the ownership is lost (with
memory leak as result, or worse).

Would it be possible to build into the compile a warning,
that warns when an auto_ptr might be used as a temporary?

-Wauto_ptr

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

==========
PS I wrote my own auto_ptr and use that :/.  It contains
   a new boolean `frozen' and two new methods
   `freeze()' and `unfreeze()'.  While frozen, the auto_ptr
   does not pass on ownership when passed on as argument in
   the copy constructor.  I then call `freeze()' before the
   temporary is created.  The explicit use of operator=()
   always copies ownership, also when `frozen'.


// $Header: /usr/src/CVS/libr/include/libr/auto_ptr.h,v 1.1.1.1 1998/06/17 16:02:19 carlo Exp $
//
// Author:
//
// 1024/624ACAD5 1997/01/26 Carlo Wood, Run on IRC <carlo@runaway.xs4all.nl>
// Key fingerprint = 32 EC A7 B6 AC DB 65 A6  F6 F6 55 DD 1C DC FF 61
// Get key from pgp-public-keys server or
// finger carlo@runaway.xs4all.nl for public key (dialin, try at 21-22h GMT).
//
// This implementation of `auto_ptr' was originally posted to comp.std.c++
// on March 30, 1996 by Greg Colvin.
//
// The template member functions have been removed because they are not
// supported by most compilers, yet.
//
// I added the boolean `frozen' and the methods `freeze', `unfreeze'
// and `is_frozen' to allow to freeze ownership.
//

#ifndef SUPPORT_AUTO_PTR_H
#ifdef __GNUG__
#pragma interface
#endif
#define SUPPORT_AUTO_PTR_H

RCSTAG_H(support_auto_ptr, "$Id: auto_ptr.h,v 1.1.1.1 1998/06/17 16:02:19 carlo Exp $")

template<class X>
class auto_ptr {
  mutable bool owner;
  bool frozen;
  X* px;
// template<class Y> friend class auto_ptr;
public:
  explicit auto_ptr(X* p=0) : owner(p), frozen(false), px(p) {}
// template<class Y>
    auto_ptr(const auto_ptr<X /*Y*/ >& r) 
    : owner(r.owner && !r.frozen), frozen(false), px(r.frozen ? r.get() : r.release()) {}
// template<class Y>
    auto_ptr& operator=(const auto_ptr<X /*Y*/ >& r) {
     if ((void*)&r != (void*)this)
     {
       if (owner) 
	 delete px;
       owner = r.owner; 
       px = r.release();
     }
     return *this;
   }
   ~auto_ptr() { if (owner) delete px; }
   void reset()	{ bool own = owner; owner = 0; if (own) delete px; px = NULL; }
   bool freeze() { frozen = true; return owner; }
   void unfreeze() { frozen = false; }
   X& operator*()   const { return *px; }
   X* operator->()  const { return px; }
   X* get()         const { return px; }
   X* release()     const { owner = 0; return px; }
   bool strict_owner() const { return frozen; }
#ifdef DEBUG
   bool is_owner(void) const { return owner; }
#endif
};

#endif // SUPPORT_AUTO_PTR_H

Re: auto_ptr, new warning? (was: New STL implementation from SGI)

[Joe Buck]

> A note on auto_ptr... It's an unsafe class imho.
> The problem I have with it is that when it accidently is
> used for a temporary, then the ownership is lost (with
> memory leak as result, or worse).

Are you basing your notion of what auto_ptr does on the Dec. 1996
draft (the one that is on the web) or the final draft (which you can't get
unless you are on the committee)?  The two are quite different.

> PS I wrote my own auto_ptr and use that :/.

You should call it something different then.  auto_ptr is a standard
class.  If you write a class that doesn't work the same way, it will
only confuse people.

I'm not happy with everything the committee did, but we shouldn't get into
redesigning the standard library.