ISO: WG21/N0357
                                  ANSI: 93-0150
                                  Author: John Max Skaller
                                  Date:  11/9/93
                                  Reply to: maxtal@suphys.physics.us.oz.au


      Subscripting operators for string classes
      ------------------------------------------

C++ needs a general purpose value oriented utility string
class which has convenient C like syntax, moderate efficiency,
and either a rich set of operations or a minimal set
with provision for user extension.

The existing string class fails to meet these criteria.
The proposals below are an attempt to close the gap
between the existing string class and what I believe
are the principal requirements.


PROPOSAL 1a (Alternative)
-------------------------

The classes string and wstring will provide the methods

  char string::operator[](size_t i);
  wchar_t wstring::operator[](size_t i);


with the following semantics:

  a) if the index is in range, the operator will return
     the ith character of the string

  b) if the index is equal to the number of characters
     in the string, the operator will return 0

  c) in other cases the operator semantics are
     implementation defined, and may include throwing
     an exception, returning a 0, or undefined results

  d) Non-normative comment: its expected implementors will
     provide compiler switches or the like to provide
     options for the user


PROPOSAL 1b (Alternative)
-------------------------

The classes string and wstring will provide the methods

  char string::operator[](size_t i)const;
  wchar_t wstring::operator[](size_t i)const;

  char& string::operator[](size_t i);
  wchar_t& wstring::operator[](size_t i);

The semantics for the const functions are as in proposal 1a.

The functions returning a reference will return a reference
to the ith character of the internal representation of the
string if i is in range. The results otherwise are
implementation defined.

Any operation that moves the string or changes its length,
or otherwise specified, will invalidate the reference.
Execution of c_str() also invalidates the reference.

If the string utilises a shared representation, the representation
must be adjusted when the reference is formed.

PROPOSAL 1c (Recommended Alternative)
-------------------------------------

The classes string and wstring will provide the methods

  char string::operator[](size_t i)const;
  wchar_t wstring::operator[](size_t i)const;

  char& string::operator()(size_t i);
  wchar_t& wstring::operator()(size_t i);

The semantics for the const functions are as in proposal 1a.
The semantics for the non-const functions are as in proposal 1b.

RATIONALE
---------

Dynarray<char> already provides both these operators.
The operators are expected for strings.

Users will not complain if they are not provided,
they simply wont use the string class if convenient,
C-like syntax is not available.

For both these reasons I dont think providing nothing
or 1a is viable.

It has been argued that providing a non-const reference
forces shared representations to be split needlessly,
thus reducing the efficiency of the string class,
and thus that proposal 1a is superior to proposal 1b.

That would make 1b non-viable.

Unfortunately, the syntax for storing a char in a string
is somewhat ungainly:

  s.put_at(n,ch)

whereas

  s[n]=ch;

is more readable (at least to me). Since I use short strings for
utility purpuses, I dont believe efficiency ought to
be a prinicpal design determinant for a string class:
usability is much more important.

If large strings are desired, or strings with
efficient computation of various attributes,
a more specialised class will have to be provided
by the user, no matter what implementation of string is used.

For example, for lexical analysis a special class
that optimises storage use and provides fast
comparison and assignment is important,
and the string class is not adequate (on its own) for that purpose.

Therefore I do not favour restricting the interface
of the string class on efficiency grounds.
Its principal purpose ought to be provision of general purpose
functionality with moderate efficiency and convenient syntax.

Nevertheless, proposal 1c appears to effect a pleasing
compromise. The principal problem with 1a is that it
does not provide an alternative to put_at().
1b does, but it threatens efficiency because the use
of the operators is not properly reflected by overloading
const.

Proposal 1c solves this problem by providing two distinct
names that do not overload, thus giving control back to
the programmer.

For example, the copy operation

  for (int i=0; i<src.length(); ++i) dst.put_at(i,src.get_at(i));

can be written

  for (int i=0; i<src.length(); ++i) dst(i) = src[i];

It can also be written correctly but potentially less
efficiently as

  for (int i=0; i<src.length(); ++i) dst(i) = src(i);

provided src is not const.


Thus, because 1c appears viable although not perfect,
I commend it to the committee.


PROPOSAL 2
----------

The classes string and wstring will provide the protected methods

  char* string::writable_c_str();
  wchar_t* wstring::writable_c_str();

(other names may be chosen)

These operations provide write access to the internal
representation of the string.

Any operation which changes the length of the string,
or adjusts the internal representation, invalidates
the pointer.

RATIONALE
---------

If a minimal set of operations is provided, there must be
a moderately efficient method of extending the set
to a users requirements. In addition, there also needs to
be a superior mechanism for interfacing to the existing
C technology supporting char* based strings.

This operation is required to allow extension of the string
class and integration with C subsystems
without the overhead of conversions.

It allows the programmer to grab control of the string
so as to define common methods such as conversion
to upper case or capitalisation effectively.

Consider the C function

  void Capitalise(char *);

which makes the first letter of each word upper case,
and all the other letters lower case. The function
is efficient and will work effectively
with very large strings because it is a mutator
written in C, which has excellent primitives for
managing raw memory efficiently.

Suppose we wanted to extend the string class to provide
this function. How would we do it?

One way is to re-write the function using the
get_at() and put_at() primitives, but that fails
to make good use of existing code.

A better method from the point of view of reusability
is this:

  void Capit(string &x)
  {
    char *s = strdup(x.c_str());
    Capitalise(s);
    x=s;
    free(s);
  }

However, this requires at least one and maybe two allocations and
deallocations and two copies.

Proposal 2 above allows this:

   class C_string : public string
   {
   public:
     char *MyCStr(){return writable_c_str(); }
   }

   void Capit(string &x)
   {
      Capitalise( ((C_string&)x).MyCStr() );
   }

The extra work involved with the downcast makes it
a bit harder to get at the internals.

If a facility like this is not provided, programmers
will write implementation dependent code to
perform exactly the same task.


PROPOSAL 3
----------

The classes string and wstring will provide the methods

  void string::set_malloced_string(char*);
  void wstring::set_malloced_string(wchar_t*);

which will force the internal representation of the
string to refer to the parameter. The user is required
to allocate the string using malloc or realloc.
Passing a string allocated on static or automatic
storage is not allowed, nor is passing a string
allocated with operator new.

The string classes will not copy the argument.

The purpose of these methods is to ensure copy of
huge strings computed by C like functions does not
require a spurious copy to be performed.



COMMENTS
--------

In effect, I believe that the string class must
expose its internal representation to the class designer
in order to allow efficient extension.

Giving the hooks protected access status is a compromise
between safety and extensibility.

Providing portable hooks to do this is better than
the alternatives:

  a) a rich string class that doesnt need extension
     (impossible to achieve)

  b) no hooks
     (programmers will either reject the string class
     or write code that depends on the internal
     representation anyhow.)

While I respect the need to provide a safe interface,
there also exists a need to provide facilities
for efficient user extension and to enable
utilisation of existing C code.

Using the C++ access control mechanism to administer
access to the string class seems appropriate.