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.

Re: New STL implementation from SGI

[Nathan Myers]

Peter Simons wrote:

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

Probably we should do that.  

Nathan Myers
ncm@cantrip.org

Re: New STL implementation from SGI

[Andi Kleen]

Nathan Myers <ncm@cygnus.com> writes:

> Peter Simons wrote:
> 
> > 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?
> 
> Probably we should do that.  

I have another related question. Does the all-singing, all-dancing, promised
rewriten GNU C++ Library only cover the non STL parts [and still relies on 
the SGI codebase], or does it include a rewriten STL too?

-Andi

Re: New STL implementation from SGI

[Martin von Loewis]

> I have another related question. Does the all-singing, all-dancing, promised
> rewriten GNU C++ Library only cover the non STL parts [and still relies on 
> the SGI codebase], or does it include a rewriten STL too?

My understanding is that it would still use the SGI code (which, of
course, comes from various sources). At least, I don't see any reason
not to use it.

Regards,
Martin

Re: New STL implementation from SGI

[Nathan Myers]

Andi Kleen wrote:
> 
> Nathan Myers <ncm@cygnus.com> writes:
> 
> > Peter Simons wrote:
> >
> > > 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?
> >
> > Probably we should do that.
> 
> I have another related question. Does the all-singing, all-dancing, promised
> rewriten GNU C++ Library only cover the non STL parts [and still relies on
> the SGI codebase], or does it include a rewriten STL too?

The ASAD rewrite includes a (slightly modified) copy of SGI STL, currently 
at release 3.1.  Our goal is to have it identical, but that will depend 
on (even more!) cooperation from Matt Austern at SGI.

Things left to do include putting "feature-select" macro guards around
the non-standard extensions and renaming some types and templates that
have "__" in their names.  (These can interfere with name-mangling on 
some targets.)  Most of the other differences are in how things are 
split up into files and how the files are found -- these make a difference
particularly when you want to keep track of (or avoid) the use of 
extensions, or when you are ready to support separate template compilation.

There will be very good reasons to want to support separate template
compilation.

Nathan Myers
ncm@cantrip.org

Re: New STL implementation from SGI

[Gerald Pfeifer]

On Sun, 5 Jul 1998, Nathan Myers wrote:
> Things left to do include putting "feature-select" macro guards around
> the non-standard extensions and renaming some types and templates [...]

I would also like to see those instances fixed, where EGCS prints
-- more or less warranted -- warnings for code in the STL headers. 

I definitely would be willing to contribute in that direction, just
let me know...

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: New STL implementation from SGI

[Branko Cibej]

Gerald Pfeifer wrote:

> I would also like to see those instances fixed, where EGCS prints
> -- more or less warranted -- warnings for code in the STL headers.

I guess STL headers would count as system headers as far as egcs is
concerned. In that case, this patch:

      http://www.cygnus.com/ml/egcs/1998-Jun/1137.html

could help. I don't know its status, though.

--
Branko Cibej   <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
phone: (++386 61) 186 53 49  fax: (++386 61) 186 52 70

Re: New STL implementation from SGI

[Josh Stern]

If the new STL is not obviously incompatible/broken when used
with egcs 1.1, how about making the choice of which STL is built
and installed a configure option?  The extra src would only
be a small percentage of the total package.  The configure could
also bump the minor version number on libstdc++.

- Josh

jstern@citilink.com

Re: New STL implementation from SGI

[Josh Stern]

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

The idea of user control is good.

>you could do different definitions in different compilation 
>units as long as you don't pass strings between units.  

If I was working on a multi-user project, I'd be scared of the
confusion resulting from such a restriction (I'd like to name
the classes different things that could turn out to be typedef'd
to the same implementation).  But the idea
of using different versions to address implementation tradeoffs comes
up over and over.  For instance, with the STL map/set/multimap etc.
classes there is a tradeoff between, on the one hand, best
small project speed and readability with a pure template solution,
and on the other hand, best space efficiency with a solution that
maps different template classes to common code based on
manipulation of void* pointers (I don't know whether
that runs into problems with exceptions, but the idea is clear).

One idea to consider is distributing a directory of c++contrib code
that #ifdef'd typedefs in user code could access based on the 
macro-defined compiler name and version number.  That should
make it easy to work around portability issues.


- Josh

Re: New STL implementation from SGI

[Ross Smith]

From: Joe Buck <jbuck@synopsys.com>
>
>> 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).

Unfortunately, as the design notes for the SGI implementation explain,
reference counted containers are incompatible with thread safety. You
can do tricks to make a compromised implementation of std::basic_string
that is thread safe (in the SGI STL sense), which sometimes reference
counts and sometimes deep copies. (I gather the description of
std::basic_string in the FDIS was carefully tweaked to make this
implementation possible.) But if you require amortised-constant copying,
I think this force reference counting too often; I don't think such an
implementation could be thread safe.

I realise not everyone thinks thread safety is vital, but for me and
many others, thread safety is a killer issue. I had to switch from EGCS
to MSVC because of this; I plan to switch back as soon as a thread safe
libstdc++ is available. I'd just like to put in a plea to the library
implementors to make sure they understand this issue, and not to
compromise thread safety in favour of efficiency. (Or at least to give
us the option.)

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
  "Remember when we told you there was no future? Well, this is it."
                                                        -- Blank Reg

Re: New STL implementation from SGI

[Thomas Kunert]

I hope this doesn't sound too stupid:

What is the purpose of reference-counted strings? For portable code, one
cannot depend on fast copy-operations and if one writes code especially
for egcs, rope is better anyway. In neither case reference counting
would be very useful.

--
Thomas Kunert

Re: New STL implementation from SGI

[Joe Buck]

> What is the purpose of reference-counted strings?

In many applications, they are reasonably fast.

> For portable code, one cannot depend on fast copy-operations ...

meaning that if egcs uses a reference-counted string class, people moving
from a class that works like Microsoft CString (always deep copy) will
see a speedup.  In practice, since the committee said nothing about speed,
people who need speed can't use the standard string class at all; they
would need to design a custom class or else specifically choose which
class to use on a per-platform basis.

> and if one writes code especially for egcs, rope is better anyway.

Not always.  For many operations where the current egcs string, or the SGI
string, are O(1), rope is O(log(N)).  See the SGI documentation on rope
for a discussion.  Some rope operations are slow.  But rope will run on
many compilers, not just egcs, so using rope isn't that unportable.

Re: New STL implementation from SGI

[Mike Stump]

> From: "Ross Smith" <ross.s@ihug.co.nz>
> To: <egcs@cygnus.com>
> Date: Mon, 13 Jul 1998 17:44:24 +1200

> I realise not everyone thinks thread safety is vital, but for me and
> many others, thread safety is a killer issue. I had to switch from
> EGCS to MSVC because of this; I plan to switch back as soon as a
> thread safe libstdc++ is available. I'd just like to put in a plea
> to the library implementors to make sure they understand this issue,
> and not to compromise thread safety in favour of efficiency. (Or at
> least to give us the option.)

If would be useful for us for you to add to the g++int.texi file a
chapter on thread safety, or more importantly, what isn't that you
think should be.  There are some of us that can do the work, if you
sensitize us to the issues.

Re: New STL implementation from SGI

[Mike Stump]

> Date: Mon, 13 Jul 1998 16:32:55 +0200
> From: Thomas Kunert <kunert@physik.tu-dresden.de>
> To: egcs@cygnus.com

> I hope this doesn't sound too stupid:

> What is the purpose of reference-counted strings? For portable code,
> one cannot depend on fast copy-operations

This is called a ``quality of implementation'' issue.  Sure, people
cannot rely safely of such things, but some people just don't care a
whole lot about performance and they are happy to give money to the
compiler company that gives them the best performace for their
application.

Or look at it a different way, sure you can portably rely upon
reference counted strings, because if a C++ compiler doesn't offer it,
you can just use g++, as _it_ is portable (for some definition of
portable).

> and if one writes code especially for egcs, rope is better
> anyway.

Ah, but that class is nonstandard (so far).  We might add it next time.

Re: New STL implementation from SGI

[Joe Buck]

> > and if one writes code especially for egcs, rope is better
> > anyway.
> 
> Ah, but that class is nonstandard (so far).  We might add it next time.

We already ship the rope class, so there is nothing to add.