🚀 go-pugleaf

>>>>> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

> In article <4cteo4$32o@netlab.cs.rpi.edu>
> Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:

> |> I believe that the string class would best implememnted as a
> |> copy-on-change class, which means that the copy-constructor will not
> |> actually duplicate the string but will increase the reference counter it
> |> uses.

> I don't believe that copy on write is allowed in the current draft.
> Each string can have its own unique allocator; how do you implement
> copy on write in such cases?

I don't see why specifying the allocator would have any effect on COW.
Whether a representation can be shared is independent of what method was
used to allocate the storage for that representation.

> Even if copy on write were allowed, I can think of many reasonable
> implementations in which string::data() (or string::c_str()) may throw
> bad_alloc.  Maintaining the physical data internally as a contiguous
> buffer makes most of the string manipulation functions relatively
> expensive on long strings.  (Since I only use very short strings, this
> doesn't bother me.  But it is a point that an implementor may want to
> consider.)

I was going to tell you that the types of the iterators precluded any other
representation, but happily it looks like that was changed in the September
WP: from

      typedef typename Allocator::types<charT>::pointer        iterator;
      typedef typename Allocator::types<charT>::const_pointer  const_iterator;

to

      typedef implementation_defined                      iterator;
      typedef implementation_defined                      const_iterator;

This also gives COW implementations more flexibility.

Jason
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]