Question about std::string and N2668

[Brad Spencer <spencer at starscale dot com>]

Hi, all.

I'm aware of the issues raised in
http://gcc.gnu.org/ml/libstdc++/2001-12/msg00267.html and I have read
N2668 and I understand the implications for single-threaded programs
about how copy-on-write can lead to the invalidation of iterators at
unfortunate times, and it does seem like there is a small hole in
std::string that needs fixed.

I notice at the end of N2668, there is the following recommendation:

  "The largest potential loss in performance due to a switch away from
  copy-on-write implementations is the increased consumption of memory
  for applications with very large read-mostly strings. However, we
  believe that for those applications ropes are a better technical
  solution, and recommend a rope proposal be considered for inclusion
  in Library TR2."

I couldn't find any modern proposals for rope with my Google
searching.  Does anyone here know of one?

It seems that the trunk version of libstdc++ is still using
copy-on-write, and I was wondering if any investigation has been done
into alternative implementation approaches yet?  I'm (selfishly)
wondering what the actual time and memory performance differences
would be in single-threaded programs.  Is the only alternative to just
have a pointer and a length and do the obvious things?

I'm sure it's been said many times before, but it seems such a shame
to have to give up the benefits of copy-on-write even though
std::string is imperfect without it. :( However, it may be that move
semantics cover most of the cases that matter, and the rest of the
cases might just be "neat tricks" that are easily (but perhaps more
cumbersomely) done with shared_ptr.

-- 
----------------------------------------------------------
Brad Spencer - spencer@starscale.com - www.starscale.com