This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Question about std::string and N2668

Hi, all.

I'm aware of the issues raised in 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 - -

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]