Re: Question about std::string and N2668

[Benjamin Kosnik <bkoz at redhat dot com>]

> 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?

No.

> 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?

Check out ext/vstring.h, which encapsulates the most current libstdc++
thinking about a string class. When possible, std::basic_string will be
implemented with this code.

In the meantime, people wanting/needing a more flexible string class
should be using __gnu_cxx::__versa_string.

-benjamin