From 934630493144699946 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,b83a4267f4ac775 X-Google-Attributes: gidf78e5,public From: ncm@nospam.cantrip.org (Nathan Myers) Subject: Re: string/cow/algorithm Date: 1998/08/11 Message-ID: <6qoumk$402$1@shell7.ba.best.com>#1/1 X-Deja-AN: 380094253 Approved: stephen.clamage@sun.com (comp.std.c++) Sender: ncm@best.com References: <6qfr41$oue$1@pigpen.csrlink.net> <6qgs0r$92e$1@pigpen.csrlink.net> <35ccc2b4.832003@news3.ibm.net> <6qn19u$sb0$1@pigpen.csrlink.net> Organization: http://www.cantrip.org/ X-UID: 0000000001 X-Status: $$$T Newsgroups: comp.std.c++ Originator: clamage@taumet John Potter wrote: >I received some email responses to the original. Not seeing any >posts, I will pass on the information to you and others. Here is >another nasty problem: > > string s("abc"); > string::iterator i(s.begin()); > string c(s); > *i = 'z'; > // What is the value of c[0]? > >A solution is for strings to have one of three states (shared, unique, >unsharable). You have the first two now. Any function which returns >a non-const reference to internals must take care of making the copy >and marking it unsharable. Any copy function which gets an unsharable >to copy must do a deep copy. In the above, s.begin() would do that >for s and the copy constructor would be forced to do a deep copy in >creating c. This is not a nasty problem in a conforming implementation, for the reason stated above. In fact, these three states (shared, unique, unsharable) neatly correspond to values n>0, 0, and -1 for a reference count n, so no extra storage is needed to represent the extra state. -- Nathan Myers ncm@nospam.cantrip.org http://www.cantrip.org/ [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]