Re: some basic_string optimization

[Vadim Egorov <egorovv at mailandnews dot com>]

Nathan Myers <ncm@cantrip.org> writes:

> On Fri, Apr 28, 2000 at 07:14:32PM +0400, Vadim Egorov wrote:
> > I found that replacing a single character in a string was a bit more 
> > expensive than I thought. Making _M_mutate call conditional made
...
> 
> I think this doesn't work.  You must also check that the
> string representation isn't shared with any other string
> object; see the definition of _M_mutate, and the non-const

Oops! Sorry. May be this one would be acceptable - avoiding the 
redundant memmove seems to improve the speed significantly. 
:

2000-04-30  Vadim Egorov  <egorovv@mailandnews.com>

	* bits/string.tcc: avoid traits_type::move

Index: string.tcc
===================================================================
RCS file: /cvs/libstdc++/libstdc++/bits/string.tcc,v
retrieving revision 1.59
diff -c -r1.59 string.tcc
*** string.tcc	2000/03/28 04:21:42	1.59
--- string.tcc	2000/04/30 07:47:42
***************
*** 280,286 ****
  	  _M_rep()->_M_dispose(__a);
  	  _M_data(__r->_M_refdata());
        }
!       else if (__how_much)
  	{
  	  // Work in-place
  	  traits_type::move(_M_data() + __pos + __len2, __src, __how_much);
--- 280,286 ----
  	  _M_rep()->_M_dispose(__a);
  	  _M_data(__r->_M_refdata());
        }
!       else if (__how_much && __len1 != __len2)
  	{
  	  // Work in-place
  	  traits_type::move(_M_data() + __pos + __len2, __src, __how_much);


> operator[].  Is there some reason you're not using operator[]?
I wanted to find the most efficient way to return a basic_string
by value from some code that stuffs it with a number of characters
(say, builds a collation key for a given string). 
The code estimates the required length to store the result, allocates
a buffer and fills it. I wanted to avoid using extra buffers to eliminate
unnecessary copying and use the string to be returned itself.

Using non-const iterators as well as operator[] 
(they look so innocent at the first sight) 
would result in the resulting string to be in a 'leaked' state so 
the copying will occur anyway. So the choices are :
a)
  string result(len , ' ');
  for(...)
    result.replace(pos, 1, 1, ch); 

or 
a)
  result.reserve(len);
  for(...)
    result.push_back(ch); 

Unfortunately they both do a bit more than necessary. With this patch
the performance of a) become more or less reasonable.
I wish I could put basic_string back into non-leaked state somehow. Sigh.

Regards,
Vadim Egorov

> 
> Nathan Myers
> ncm at cantrip dot org