Re: std::string bad design????
Peter Dimov wrote:
James Kanze wrote:
This discussion hasn't yet seriously taken place in the committee, as
far as I'm aware. My opinion is that (2) should be required for every
standard type, and that a mutating access is defined on the logical
level, not on the physical level (to maintain a degree of
implementation hiding and abstraction). This means that unless a
function f is explicitly designated to read from, or write to, an
object x, the logical constness of x within f is used to derive whether
f reads or writes x. In your example, s[0] and s.begin() are writes by
default because s is non-const in operator[] and begin(), unless the
general principles are overridden by changes to the specification of
std::string.
There is one interesting exception to the above rule,
tr1::function<>::operator(); it's logically const, but a write access.
There may be more in the parts of the library that aren't my strong
points. :-) The global variables std::cout et al are another
interesting case that needs explicit attention.
There is also the case of a const member function operating on a member
variable that is declared mutable.
I think some people would like to see that, if a global aggregate has
storage class const, then it should be thread-safe, and if not, there
should be things done to the language to assert that the semantics of
modifying a const global aggregate is thread-safe.
It would be interesting to compare the performance trade-off of taking
this approach, versus assuming that perturbation of state is always a
possibility when invoking a member function on an aggregate.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]