kanze@gabi-soft.fr wrote:
[...]
>                            In fact, there is no requirement that the
> backing store be contiguous.  However, the pointer returned by data or
> c_str must point to a contiguous buffer.  There are several ways to
> achieve this using a non contiguous backing store; one is to simply
> switch to contiguous backing store when either of these functions are
> called.  If the iterators also point into the backing store, this will
> invalidate them.

This will also make it impossible to call c_str()/data() CONCURRENTLY
with respect to {almost} any other CONST operation on the same object.

Confusing, to say the least.

regards,
alexander.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Minor correction: I'm informed by my colleague that it was in fact the
Principle of Least Astonishment I was thinking of, although hopefully the
idea was transmitted well enough.

The issue at hand really isn't whether or not it should or should not const;
it's that its sideeffects as stated run contrary to what its intended use
is.  c_str() exists to provide an alternate _view_ of the data inside the
string; that view can be immutable if need be, as long as it's accurate.
Technically, I could write my own getCStr() which just returned a
boost::shared_array<T *> and iterated through the entire string copying a
char at a time, but I think it's reasonable to suggest that doing so really
shouldn't be necessary.

Unfortunately, after absorbing the views of everyone here, I can't see a way
to correct c_str() without either breaking old code or placing obviously
unwelcome restrictions upon implementors, so I suggest that this DR should
be withdrawn.   However, I still see the need for what may end up being an
alternate string class that strikes a more appropriate balance between
implementor freedom and usability.  (It would also be a chance to go back
and reverse some of the other annoyances of basic_string, such as npos.)

~ Ryan Myers <root@poweredbyg.nu>


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]