From -2940154923089748470 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: lancediduck@nyc.rr.com Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Date: 23 Aug 2005 14:30:08 GMT Organization: http://groups.google.com Lines: 58 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1124790086.351633.74880@g14g2000cwa.googlegroups.com> References: <7ibbe1hu4omoqsfibanas46idf9u6i5hjo@4ax.com> <9pchf11o63qib8h56fap5g5445gjac5ce2@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Delivered-To: std-c++@ucar.edu X-Trace: posting.google.com 1124790091 32564 127.0.0.1 (23 Aug 2005 09:41:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 23 Aug 2005 09:41:31 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=66.65.46.98; posting-account=3mYY3wwAAADRamnjcYfRKWdoFpb0mshK X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox4.ucsd.edu; Tue, 23 August 2005 02:41:33 -0700 (PDT) X-Spamscanner: mailbox4.ucsd.edu (v1.6 Aug 4 2005 15:27:38, -2.6/5.0 3.0.4) X-MailScanner: PASSED (v1.2.8 55433 j7N9fWjQ056991 mailbox4.ucsd.edu) X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1908 The fact is that every major STL supplier already supports polymorphic allocators. I've tested this with Roguewave, Dinkumwave, STLPort, and gnu on Sun, gcc, MSVC, aCC, etc, and others I know of have tested it on Comeau and gcc. I haven't tested using Mr Hinnant's offering, but I'm sure polymorphic allocators work there as well. Mr. Halpern's proposal largely just makes polymorphic allocators the default instead of stateless. Making it the default solves nothing - worse, it renders millions of current applications suddenly nonstandard, and to restandardize them implies rebuilding all of them, adding in "default singleton allocator instances" to the initialization routines, and an extra pointer to everybody's containers whether they need it or not. Even if the committee DID adopt every word of Mr Halpern proposal, there is no way every organization is going to pour effort into reworking already built and tested code. It would largely just make the standard ineffective. Support for polymorphic behavior in allocator::operator==, max_size, allocate, and deallocate is already the de facto standard. Making it the de jure standard would be largely a no brainer, except for std::string, where the standard explicitly allows for reference counted implementations. I'm not really sure of just what stateful allocator semantics are for reference counting. But given that every STL vendor already supports polymorphic allocators, at least for the functions of interest, it would be far easier to standardize a container adapter that wraps the problematic container functions. For example, a "stateful vector adapter" would wrap 1. resize (because T may also hold something that wants an allocator) 2. default constructor (this is the worst problem, not swap) 3. swap 4. size_t constructor (because it call resize) 5. non const iterator 6. any mutating operator Then using the adapter approach, we don't have to try to figure out the correct behavior for everybody up front - choose a suitable default for the standard, and a way to adapt it for the special cases. Then all you need is a library - and since unequal allocators are a very niche problem, a 3rd party adapter library is a far better solution than having everybody rework existing applications so that we could use "Lakos Allocators" as the default. The C++ community could equally ruminate on making the "grow factor" in vectors have polymorphic behavior, or the page size in a deque, or the type of error thrown for range_error, but the 1995 committee mercifully burnt these value in, and no one second guesses it. Indeed the whole idea of the STL is that specialized containers could be easily designed to use a wide range of existing algorithms. Second guessing the 1995 containers interafaces completely misses the point. "To use the STL is to extend it" --- [ 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://www.jamesd.demon.co.uk/csc/faq.html ]