Has anything been done about the problems with the string template? (See
http://www.sgi.com/Technology/STL/string_discussion.html)

--
Ross Smith ............................. <mailto:ross.smith@nz.eds.com>
Internet and New Media, EDS (New Zealand) Ltd., Wellington, New Zealand
   "The first thing we do, let's kill all the language lawyers."
                             -- Henry VI Part II, by W. Shakespeare;
                                additional dialogue by B. Stroustrup
---
[ 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                             ]

Ross Smith wrote:
>
> Has anything been done about the problems with the string template? (See
> http://www.sgi.com/Technology/STL/string_discussion.html)

To summarize that article:

1. There used to be a problem with s[1] = s[0], but that was fixed in
July.
2. Threads aren't easy to support.
3. Many implementors have written code with the same bug, but it's easy
to fix.

That is, 1 isn't a problem, 2 isn't a problem that the standard
addresses anywhere (deliberately), and 3 isn't a problem.
 -- 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                             ]

Ross Smith wrote:
>
> Has anything been done about the problems with the string template? (See
> http://www.sgi.com/Technology/STL/string_discussion.html)

We corrected it in London, as explainned in the mentionned
document. Well, it's still not perfect, but at least it's
safe for mono thread use, and safe if _all_ operations are
protected with a lock on multi threaded programs.

The problem is that it's conservative:

  // untested code

  string lower_string (string s)
  {
      transform (s.begin (), s.end (),
                 s.begin (), tolower);
      return s;
  }

  string x = "Hello World";
  copy (x.begin (), x.end (),
        ostream_iterator<char> (cout));
  string x_lower = foo (x);
  cout << x_lower;

Here after the first of begin () and end (), the
string x is not only unshared but unshareable, so
the construction of s must copy the elements (expensive).

Then foo will call begin/end again, so s is made
unshareable. Then it is returned: second copy to a
temporary variable of type string (the compiler can
elide this copy, but let's say that it won't).

Then the temporary is copied to x_lower, but as it
is shareable, no actual copy is performed. Both
x_lower and the temporary are shared now. When the
temporary is destroyed, x_lower reverts to unshared
but still shareable.

So what is the conclusion ? Did we gained something
wrt a simple non-sharing implementation ?

Well, yes, we avoided one copy. The copy from x to s
wasn't avoidable as s is changed anyway. The copy to
the return value, however, wasn't neccessary, so it
could be better.

In particular, people may get the feeling that it's
no longer neccessary to pass strings by const ref:

  void print (string x)
  {
      copy (x.begin (), x.end (),
            ostream_iterator<char> (cout));
  }

  print ("Hello, string");

as they assume that an indirection will be introduced,
so it's better to pass by value as no copy will occur.

This is wrong: the call to begin () force a copy of
the content of the string; using const string, which
appears as equivalent with string, isn't really:

  void print (const string x)
  {
      copy (x.begin (), x.end (),
            ostream_iterator<char> (cout));
  }

Here the const begin/end are called, and sharing is still
possible. Anyway, as the original string might be
unshareable, it's better to use const string& arguments
when possible.

And it's possible to rewrite lower_string to make it
more efficient:

  string lower_string (string s)
  {
      transform (s.begin (), s.end (),
                 s.begin (), tolower);
      s.append ("", 0);
      return s;
  }

Here append is a no-op (a fast one I hope), and will
unshare the string (but it already it unshared), and
make it shareable, so the next copy can be avoided.

Summary: in London we choosed the safe way (at least
for single threaded code), but not the faster one.

--

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                             ]

Ross Smith <ross.smith@nz.eds.com> writes:

|>  Has anything been done about the problems with the string template? (See
|>  http://www.sgi.com/Technology/STL/string_discussion.html)

There were some changes, but I'm not sure how far they go.  They do go
far enough that neither the French national body nor the people at SGI
felt it worth the effort of insisting more (although they don't go as
far as I would have liked).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ 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                             ]