Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  J. Kanze <kanze@gabi-soft.fr> writes:
|>
|>  > In the most
|>  > general case, changing an arbitrary character using operator[] will have
|>  > unspecified effects, due to multicharacter encodings.  The only *safe*
|>  > way to change a string is to use the replace function.
|>
|>  Well, if you have a multi-byte encoded text, you should convert
|>  it _then_ put it into a wstring. The locales gives you the
|>  convertion function for multi byte encoding.

I think I mentioned wstring later in my posting.  Even with Unicode, you
have problems, e.g. converting a string to caps (where Unicode 0xDF
requires two characters as a capital letter).  In general, I've never
had a case where just substituting one letter for another was useful.

|>  > Compatible with RandomAccessContainer: I've no idea here.  You'll have
|>  > to tell me what the requirements of a RandomAccessContainer are.  The
|>  > word doesn't occur in the standard.
|>
|>  It's in the SGI STL documentation. It's a containner supporting
|>  random access iteration and direct access with op[]. If there is
|>  no equivalent it means that the SGI STL doc is better than the
|>  std (which isn't surprising anyway).

It's not in the standard, so (at least in this forum) it doesn't exist.
Since I no longer have the initial context, I can't comment as to the
random access iterator requirements.  I do not see how operator[] can
affect them, however.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  Pete Becker wrote:
|>  >
|>  > J. Kanze wrote:
|>  > >
|>  > >
|>  > > In my own code, I don't think I've
|>  > > ever used an op[], either in my own string class or someone elses.  I'll
|>  > > admit that I cheat, however -- when parsing, I normally do the
|>  > > equivalent of c_str(), and use the resulting pointer:-).
|>
|>  Which still disallow sharing, except if c_str copies the data, which
|>  is as inneficient.

I don't understand this.  How does the use of c_str disallow sharing?

Of course, you do have to be careful, since the pointer returned by
c_str is invalidated by any non-const function.  But then, if you're
parsing, you're probably not modifying the string anyway.

|>  > That's not cheating. I was against having operator[] in the string class
|>  > at all, but the forces of inertia were impossible to overcome.
|>
|>  Can you explain that to me (or us), or give a document number ?
|>
|>  In particular, how does one reaad the char at position i ?
|>  Change it ? Would it be compatible with the RandomAccessContainner
|>  requirements ?

Read the character:  s.c_str()[ i ].  In practice, I find that I
generally read the characters sequentially, in which case, starting with
p = s.c_str() and incrementing p does the trick.  (An iterator is
probably a better solution today, but old habits die hard.)

Change it: read my post to which Pete was responding.  In the most
general case, changing an arbitrary character using operator[] will have
unspecified effects, due to multicharacter encodings.  The only *safe*
way to change a string is to use the replace function.  (I'm considering
re-evaluating this with regards to wstring.  In practice, however, I
doubt that it will make a difference.  Even something simple like
converting the string to upper case will occasionally require replacing
a single character with two.)

Compatible with RandomAccessContainer: I've no idea here.  You'll have
to tell me what the requirements of a RandomAccessContainer are.  The
word doesn't occur in the standard.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Brock" <peabody@npcinternational.com> writes:

|>  Valentin Bonnard wrote in message <34B6580F.6A50@pratique.fr>...
|>  <<<
|>
|>  >The problem is that sharing is often impossible as:
|>  >- operator[] has to return a charT&
|>
|>
|>  Does it have to return a charT& according to the standard?

Yes.  I argued against this in the French national body comments, but in
the end, I imagine that correcting it represented too big a risk given
the late date.

Consider the case where charT is a struct; the programmer might want to
write s[ i ].x (which is legal under the current wording).  Without
overloading operator., you can't do it using a helper class.  The French
comments suggested that perhaps support for a struct as charT wasn't
that important, and could be dropped.  I suppose that some of the
committee members felt that such code was important -- at any rate,
there was not time at that point to conduct any real surveys.

Note that an implementation that really wanted to could use a helper
class.  Basically, the compiler "knows" about basic_string.  So it could
automatically activate extensions within this class to support
operator., and to not count the conversion of the helper to char as a
user defined conversion.  There is still a problem with &s[i], but I
imagine that some more compiler magic could also solve this, and the
result would be that there is no way a conforming program could tell, so
it would be legal under the as if rule.

|>  I read somewhere
|>  (More Effective C++?) about an efficient way to determine whether operator[]
|>  was used for read or write access by returning an object with an overloaded
|>  operator=(charT), and an operator charT().  I even wrote a (hopeless) email
|>  to my vendor (MS) complaining that their std::string implementation didn't
|>  use this technique, as I had assumed it to be the standard way to do it.

It is the normal way of doing it.  It's the way I did it in my own
string class (for substring, not for operator[], which is a const
functon returning a char).  It is not legal according to the standard.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze <kanze@gabi-soft.fr> writes:

> In the most
> general case, changing an arbitrary character using operator[] will have
> unspecified effects, due to multicharacter encodings.  The only *safe*
> way to change a string is to use the replace function.

Well, if you have a multi-byte encoded text, you should convert
it _then_ put it into a wstring. The locales gives you the
convertion function for multi byte encoding.

> Compatible with RandomAccessContainer: I've no idea here.  You'll have
> to tell me what the requirements of a RandomAccessContainer are.  The
> word doesn't occur in the standard.

It's in the SGI STL documentation. It's a containner supporting
random access iteration and direct access with op[]. If there is
no equivalent it means that the SGI STL doc is better than the
std (which isn't surprising anyway).

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@gabi-soft.fr (J. Kanze) writes:
> Read the character:  s.c_str()[ i ].  In practice, I find that I
> generally read the characters sequentially, in which case, starting with
> p = s.c_str() and incrementing p does the trick.  (An iterator is
> probably a better solution today, but old habits die hard.)

Actually, the iterators do get close, but in my experience not quite
close enough to be as convenient as pointers.  What makes all the
difference is the trailing null: the pointer guarantees it while the
iterators don't.  Thus, when parsing a string with iterators and there
is a need to peek ahead, one constantly needs to compare against the
end iterator.  With pointers, it is sufficient to rely on the null
character to compare unequal to other characters.

Here is a more concrete example.  Suppose you are parsing a C-like
string syntax, and quoted characters are preceded by a backslash.
With the pointer style you can write something like this:

   if (rest[0] == '\\' && rest[1] == 'x') { /* ... */ }

With the iterator style you must add a check:

   if (rest[0] == '\\' && rest != source.end ()-1 && rest[1] == 'x')
   { /* ... */ }

At some point I tried to write my string parsers using the iterators,
but in the end I reverted back to using pointers.  This was really
only due to the benefits from the null character guarantees.  In the
end it simplifies the code quite nicely.

In any case this has been true in the implementations I have used and
according to Dec'96 draft.  If string requirements have changed since
to better support parsing, I would be interested to hear about them.

Cheers,
//lat
--
Lassi.Tuura@cern.ch          There's no sunrise without a night
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Matt Austern <austern@isolde.mti.sgi.com> schrieb:
> For most purposes, however, we do continue to recommend using the
> class rope<> instead.  It is a non-standard extension, but it has
> better performance characteristics for many purposes.

Are there plans to make rope<> a separate distibution for compilers that =
=20
already have "built-in" STL support?

--=20
Claus Andr=E9 F=E4rber <http://www.muc.de/~cfaerber/> Fax: +49_8061_3361
PGP: ID=3D1024/527CADCD FP=3D12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C=
9 DC
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard <bonnardv@pratique.fr> writes:

    [concerning string...]
|>  so, as op[] is typically used often, often the sharing
|>  won't take place.

I'm curious about this statement.  In my own code, I don't think I've
ever used an op[], either in my own string class or someone elses.  I'll
admit that I cheat, however -- when parsing, I normally do the
equivalent of c_str(), and use the resulting pointer:-).

Note that I don't think I've ever used op[], or any of its moral
equivalents, to modify a string.  It just doesn't work.  (Think of
multibyte encodings.  My comment here is probably NOT valid for wstring,
although I've not enough experience to tell.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard wrote in message <34B6580F.6A50@pratique.fr>...
<<<

>The problem is that sharing is often impossible as:
>- operator[] has to return a charT&


Does it have to return a charT& according to the standard?  I read somewhere
(More Effective C++?) about an efficient way to determine whether operator[]
was used for read or write access by returning an object with an overloaded
operator=(charT), and an operator charT().  I even wrote a (hopeless) email
to my vendor (MS) complaining that their std::string implementation didn't
use this technique, as I had assumed it to be the standard way to do it.

<<<
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze wrote:
>
>
> In my own code, I don't think I've
> ever used an op[], either in my own string class or someone elses.  I'll
> admit that I cheat, however -- when parsing, I normally do the
> equivalent of c_str(), and use the resulting pointer:-).

That's not cheating. I was against having operator[] in the string class
at all, but the forces of inertia were impossible to overcome.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Brock wrote:
>
> Valentin Bonnard wrote in message <34B6580F.6A50@pratique.fr>...
> <<<
>
> >The problem is that sharing is often impossible as:
> >- operator[] has to return a charT&
>
> Does it have to return a charT& according to the standard?  I read somewhere
> (More Effective C++?) about an efficient way to determine whether operator[]
> was used for read or write access by returning an object with an overloaded
> operator=(charT), and an operator charT().  I even wrote a (hopeless) email
> to my vendor (MS) complaining that their std::string implementation didn't
> use this technique, as I had assumed it to be the standard way to do it.
>
> <<<

>From 23.1.1  Sequences, Table 6:

a[n]            T&; const T&     *(a.begin() + n)
                for constant a

string is a sequence; also from 21.2  String classes/4:

          const_reference operator[](size_type pos) const;
          reference       operator[](size_type pos);
          const_reference at(size_type n) const;
          reference       at(size_type n);

The standard can't be clearer. Don't complain when your
implementor (especially MS) is right, it's so rare.

You can implement your classes the way you want, BTW.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pete Becker wrote:
>
> J. Kanze wrote:
> >
> >
> > In my own code, I don't think I've
> > ever used an op[], either in my own string class or someone elses.  I'll
> > admit that I cheat, however -- when parsing, I normally do the
> > equivalent of c_str(), and use the resulting pointer:-).

Which still disallow sharing, except if c_str copies the data, which
is as inneficient.

> That's not cheating. I was against having operator[] in the string class
> at all, but the forces of inertia were impossible to overcome.

Can you explain that to me (or us), or give a document number ?

In particular, how does one reaad the char at position i ?
Change it ? Would it be compatible with the RandomAccessContainner
requirements ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Brock" <peabody@npcinternational.com> writes:

> >The problem is that sharing is often impossible as:
> >- operator[] has to return a charT&
>
>
> Does it have to return a charT& according to the standard?  I read somewhere
> (More Effective C++?) about an efficient way to determine whether operator[]
> was used for read or write access by returning an object with an overloaded
> operator=(charT), and an operator charT().  I even wrote a (hopeless) email
> to my vendor (MS) complaining that their std::string implementation didn't
> use this technique, as I had assumed it to be the standard way to do it.

Yes, the standard does require that that basic_string<>::operator[]
return a charT&.  Proxy references are not allowed.

Changing from charT& to a proxy reference class is not an
implementation detail, but a visible change in the interface.  To take
one trivial example: at present, if s is a string, the expression
std::swap(s[0], s[1]) is legal.  If operator[] returned a proxy
reference, though, it would not be.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard wrote in message <34BB973F.167EB0E7@pratique.fr>...
>> J. Kanze wrote:
>> >
>> > In my own code, I don't think I've
>> > ever used an op[], either in my own string class or someone elses.
I'll
>> > admit that I cheat, however -- when parsing, I normally do the
>> > equivalent of c_str(), and use the resulting pointer:-).
>
>Which still disallow sharing, except if c_str copies the data, which
>is as inneficient.

Why does c_str() disallow sharing?  It returns a pointer to const which
remains valid only until a non-const member of the string is called.

Given
  string a,b("Hello");
  a=b;
  const char* pa = a.c_str();
  const char* pb = b.c_str();
I don't see any requirement that pa!=pb.

>In particular, how does one reaad the char at position i ?


a.c_str()[i]
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Bill Wade" <bill.wade@stoner.com> writes:

> >Which still disallow sharing, except if c_str copies the data, which
> >is as inneficient.
>
> Why does c_str() disallow sharing?  It returns a pointer to const which
> remains valid only until a non-const member of the string is called.

Ah, but that's exactly the point.  s1.c_str() returns a pointer that
remains valid until a non-const member on s1 gets called.  Non-const
members on copies of s1, though, are quite a different story.

     const char* p1 = s1.c_str();
     string s2 = s1;
     s2[0] = '*';        // No non-const member of s1 has been called,
                         //  so p1 is still valid.  This means that
                         //  p1 may not point to a region of storage
                         //  that is controlled by s2.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Matt Austern wrote in message ...
>> Why does c_str() disallow sharing?  It returns a pointer to const which
>> remains valid only until a non-const member of the string is called.
>
>Ah, but that's exactly the point.  s1.c_str() returns a pointer that
>remains valid until a non-const member on s1 gets called.  Non-const
>members on copies of s1, though, are quite a different story.
>
>     const char* p1 = s1.c_str();
>     string s2 = s1;

At this point s2 and s1 may have a shared representation.

>     s2[0] = '*';        // No non-const member of s1 has been called,
>                         //  so p1 is still valid.  This means that
>                         //  p1 may not point to a [shared] region of
storage


At this point s1 and s2 may not have a completely shared representation.
Any system using shared representations will most likely 'unshare' any
string as soon as a non-const member (in this case op[]) is called.  The
unsharing must occur in a way which leaves p1 valid.

Perhaps it is just a question of semantics.  I would say that c_str did not
prevent sharing, it was op[] which prevented sharing.  If s1[0] != s2[0] it
is hard to imagine the benefit of sharing element zero.

I will admit that c_str makes "partial" sharing inefficient.  In the absence
of c_str it might make more sense to implement strings which share common
substrings (along the lines of rope).  More precisely, implementations with
non-contiguous characters make c_str inefficient.

I would guess that c_str was included in the standard because existing
libraries take a lot of char* arguments, and people will want to pass string
arguments to those libraries.  I believe it would be a big step back to
require programmers to write

  char* cname = new char[name.length()+1];
  copy(name.begin(), name.end(), cname);
  cname[name.length()] = 0;
  remove(cname);
  delete[] cname;

instead of

  remove(name.c_str());

I can't use vector for memory management, since an implementation is not
required to make vector elements contiguous.  There is no auto_array_ptr
because vector is better ;-).  The standard could have mandated that
remove() be overloaded to take a string argument, but that doesn't help
existing third party libraries.  At worst c_str is implemented as shown
above.  In many implementations it is significantly better.  I note that
even rope provides c_str, even though it is not efficient.

If I'm using strings in an environment where the need for c_str and op[] is
rare, and concatenation of megabyte strings is common I'm sure you can
suggest a better class.
For an environment where most string operations
  1) involve long strings
  2) no multithreading
  3) lots of assignment/copy construction
  4) lots of c_str calls
a typical shared string implementation seems appropriate.

In an environment where the most common operation was
  string += char;
a not-shared deque might be the best implementation.  In this case I would
argue that a deque implementation makes c_str inefficient, not that c_str
makes concatenation inefficient, but I guess it just depends on how you look
at it.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Does anyone (hopefully someone from SGI) know about the company's
reaction to the November ISO FDIS on the subject of the STL string
class?

Specifically, are they happy enough to implement it in the next
release, and if so when might that happen.  Thanks.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tom Hahn <hahn@pixar.com> writes:

> Does anyone (hopefully someone from SGI) know about the company's
> reaction to the November ISO FDIS on the subject of the STL string
> class?
>
> Specifically, are they happy enough to implement it in the next
> release, and if so when might that happen.  Thanks.

Yes.  We have a standard-conforming version of basic_string
internally, and we will include it in a future compiler release.
Additionally, as usual, we will include it in our freely available STL
distribution.

For most purposes, however, we do continue to recommend using the
class rope<> instead.  It is a non-standard extension, but it has
better performance characteristics for many purposes.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tom Hahn <hahn@pixar.com> writes:

> Does anyone (hopefully someone from SGI) know about the company's
> reaction to the November ISO FDIS on the subject of the STL string
> class?
>
> Specifically, are they happy enough to implement it in the next
> release, and if so when might that happen.  Thanks.

They already have a nearly conformant string class which
works. It doesn't have sharing and copy on write. The intent
of the commitee is to allow but not mandate sharing.

The string class as defined in the London draft is usable
(the CD2 one was strictly unusable).

The problem is that sharing is often impossible as:
- operator[] has to return a charT&
- the reference is valid until you mutate the containner
  for ex. with append (not just its elements)

so, as op[] is typically used often, often the sharing
won't take place.

So SGI will continue to provide a non sharing string class
and 'rope'.

Note: I am a student; I am not from SGI.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]