Re: History of and support for std::basic_string::back()
On Monday, 5 August 2013 07:37:42 UTC+1, Paavo Helde wrote:
James Kanze <james.kanze@gmail.com> wrote in
news:0afdbb8d-b8df-495b-9af0-f3abc58670b5@googlegroups.com:
On Sunday, August 4, 2013 7:19:53 PM UTC+1, Bart van Ingen Schenau
wrote:
On Sat, 03 Aug 2013 16:27:52 -0700, James Kanze wrote:
[...]
If you want to allow CoW implementations (such as the one used by
g++), then non-const operator[] (and non-const begin() and end()) must
be able to invalidate iterators, at least the first time they are
called. (And IMHO, if the standard bans CoW implementations, it is
broken.) This was recognized in previous versions of the standard.
CoW requires multi-threaded synchronization deep in the inners of
std::string, where it would be totally on the wrong level.
It's possible, at least in theory, to use atomic types for the
counters. And the synchronization is there so that the client
code is unaware of the sharing.
In this
regard, CoW seems like a typical premature optimization attempt which may
easily become a pessimization on new hardware (thinking NUMA), so why are
you so keen about supporting it?
It's existing practice. It was introduced because it was needed
in some applications. I used it in my pre-standard String
class, because I'd had a performance problem that it solved.
And this is a library; you can't tell the user to implement it
if his profiler shows that he needs it.
If banning CoW conincidentally eliminates obscure UB in things like var
[0]==var[1], then I'm all for it.
In C++98, there was no problem with var[0] == var[1]. There was
in the CD2 preceding the standard, but the French national body
spotted it, and raised the issue in its comments. The resulting
wording was far from perfect, but it did make the intent fairly
clear.
--
James