From -3834122486198152745 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,2dadf1d1c3a45d35 X-Google-Attributes: gidf78e5,public From: "Bradd W. Szonye" Subject: Re: Why basic_string != vector ? Date: 1997/03/12 Message-ID: <01bc2eb9$373cf320$d571adce@azguard>#1/1 X-Deja-AN: 224890522 References: <3325F838.6AEF@pratique.fr> <5g5crc$o0v@mulga.cs.mu.OZ.AU> X-Original-Date: 12 Mar 1997 07:46:53 GMT Organization: Concentric Internet Services X-Auth: PGPMoose V1.1 PGP comp.std.c++ Newsgroups: comp.std.c++ Fergus Henderson wrote in article <5g5crc$o0v@mulga.cs.mu.OZ.AU>... > Valentin Bonnard writes: > > >The question is in the subject line: why basic_string != vector ? > > (a) historical reasons -- string was around before STL and vector; > (b) there are some operations that string provides which don't make > sense for vector; > (c) the implementation can optimize string in various ways that wouldn't > be appropriate for vector, e.g. by using reference counting > with copy-on-write. This last part is a fairly recent change. (So recent, in fact, that some of the text appears to contain cut-copy-paste errors and awkward verbiage.) In pre-CD2 drafts, basic_string<> and vector<> had the same semantics for reserve() and capacity(). In the CD2, basic_string<> gives you no guarantees for reserve (although the actually verbiage could stand some editing). It's turned from an allocation-pattern guarantee into a mere hint. I expect vendors to do the Right Thing and make reserve() as tight as possible; I believe the change occurred because the strict semantics of vector::reserve() make implementation of lazy-copy strings non-conforming. There simply isn't a way to do lazy-copy AND guarantee exactly when allocation occurs, at least not without excessive legalese. The other change I noticed: basic_string<> now behaves according to Sequence requirements and RandomAccessible container requirements. This means, for instance, that the constant-amortized allocation time guaranteed by Sequences also now applies to strings. (The requirement basically mandates geometrically rather than arithmetically expanded strings.) Overall, I'm very pleased with the new specifications. While I don't think that strict-copy strings are necessarily a Bad Thing, I'd hate for (a) vendors to provide lazy strings that would have been nonconforming by the old rules, or (b) users to avoid the string class for real or imagined performance concerns. Ahhh, my faith in The Committee is restored! -- Bradd W. Szonye bradds@concentric.net http://www.concentric.net/~bradds --- [ 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 ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]