🚀 go-pugleaf

Here are some comments and a query about the standard string class. I am
working from the January 96 working papers, but the comments also apply to
the April 95 version of the standard.


Reallocation
------------

Under the section on reserve the draft standard says that no reallocation
of the storage takes place during insertions until the string reaches
the length given by the last call of reserve. The standard does not say
what insertion means. I assume it means append, +=, and possibly insert
statements. Is this correct? If so the value returned by data() should
remain valid following a call of append, += or insert if the string doesn't
exceed the length set by reserve.

But this is conflict with the description of data() which says the value
returned becomes invalid after any non-constant call to the string concerned.

Am I missing something or does this still need to be worked out?

...recommendation: this be clarified


reserve
-------

The reserve function allows you to increase the capacity but there doesn't
seem to be anyway of decreasing it. So before working of a string we might
increase the capacity to something large to avoid repeated reallocating
storage. When we have finished we might want to set the capacity down to size()
to save space. There doesn't seem to be anyway of doing this.

...recommendation: a command be included to reduce the capacity to the
length of the string, eg reserve().


at and operator[]
-----------------

The same comments apply here as applied to data() in my comments on
reallocation.

Are we to assume that
x[3] = 'a';
as an example, may cause a reallocation, and so invalidate data()?

at and operator[] seem almost identical except that operator[] isn't required
to check bounds. However, the const version of x[x.size()] is supposed to
return traits::eos(), so if we store our strings without a trailing
traits::eos() we will have to check bounds. Is this is what is intended?

The constant version of operator[] returns a charT whereas the constant
version of at returns a const_reference. What is the point of this 
difference and what effect does it have?

...recommendation: remove the requirement that x[x.size()] return
traits::eos() and clarify the difference between operator[] and
at.

Question: are we safe to assume that something = x[3] will use the constant
version of the operator?


c_str
-----

Same comments apply as applied to data() in the section on reallocation.


data
----

Also note that the value might be destroyed by a call to c_str(), since we
might have to reallocate the string to accommodate a trailing traits::eos().

... recommendation: under the section of data() note that the returned value
may be invalidated by a call to c_str.


reallocation again
------------------

Suppose I am right in thinking we can update a string with operator[], at,
insert or append without causing reallocation. Suppose also we are writing
a string package with copy-on-write. Then copy-on-write must be disabled on
string for which data() etc has been called. We need some way of telling a
program that copy-on-write can be reactivated - eg we are no longer interested
in the value returned by data(). Calling reserve() as I have defined above
may be one possibility.

... recommendation: some way be found for allowing a user to re-instate
copy-on-write.


find etc.
--------

Most of the functions that deal with two strings (such as replace and
compare in the January papers) use the order of parameters:
   pos and n for the string on the left of the '.'
   the name of the second string
   pos and n for the second string.

But find does not follow this convention. Here pos follows the second string
but refers to the string on the left of '.' . The situation is
doubly confusing for str.find(s, pos ,n) where s is a charT*. Here
pos refers to str and n refers to s.

...recommendation: fix this.


That's all for now.

Robert
 


[ To submit articles: Try just posting with your newsreader.  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
]