From -1063430262363091863 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news1.google.com!news.maxwell.syr.edu!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: phalpern@halpernwightsoftware.com (Pablo Halpern) Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Date: Thu, 1 Sep 2005 05:51:29 GMT Organization: EarthLink Inc. -- http://www.EarthLink.net Lines: 122 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <48sch1lclsrtqr6tcgfns9jinmo1ecmdsb@4ax.com> References: <9pchf11o63qib8h56fap5g5445gjac5ce2@4ax.com> <1124790086.351633.74880@g14g2000cwa.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1125553895 9597 158.152.254.254 (1 Sep 2005 05:51:35 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 1 Sep 2005 05:51:35 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j815pTL0016749; Thu, 1 Sep 2005 15:51:29 +1000 (EST) X-NNTP-Posting-Date: Wed, 31 Aug 2005 21:08:45 PDT X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Forte Agent 1.93/32.576 English (American) X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1993 lancediduck@nyc.rr.com wrote: >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. I take issue with your definition of "works" here. All of the libraries you site allow allocators to carry state, thus allowing an allocator to contain a pointer to a polymorphic type. However, the issues I state in the paper still exist. You sent me a memo in which you yourself listed many of these issues. Most notably: 1. The asymetry between copy construction and assignment cause one to lose control over the allocator. 2. It is difficult resize a vector if the allocator does not have a default constructor. 3. It is difficult to get a container and its contained elements to share the same allcator. 4. It is unclear what certain constructs SHOULD do. >Mr. Halpern's proposal largely just makes polymorphic allocators the >default instead of stateless. Actually, my proposal says a heck of a lot more. It addresses the issues listed above. You may be zeroing in on the default allocator because it is probably the most controversial part of the proposal, now that I've backed away from changing the semantics of swap(). >Making it the default solves nothing - It solves the interoperability of "vocabulary" types like std::string and std::vector. It allows existing software libraries that don't explicitly use allocators to work with client code that does use allocators. >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. I'm not sure what you mean "render millions of current applications suddenly nonstandard." Lots of third-party code was rebuilt using our enhanced STL and they work fine. They were standard-conforming before the change and they remain conforming after the change. Could you describe what you mean by 'adding in "default singleton allocator instances" to the initialization routines'? If you're concerned about recompilation, I will just say that most development organizations I've worked for are not afraid to recompile every 10 years or so, when a new standard is ratified and implemented by compiler vendors. When evaluating proposed changes to the standard based on compatibility with the old standard, I draw the line at recompilation -- if the vast majority of old code compiles and has the same semantics under the new standard, that's good enough for me. As far as the extra pointer is concerned, I've already addressed that issue in a previous post. >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. The issue of reference counting in the presence of unequal allocators is independent of my proposal, but I'll give my opinion: If the original and copy use different allocators, then make a deep-copy. For example, If the copy is supposed to go into shared memory but the original is not in shared memory, you'd better make a deep copy. >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 Could we see some examples? (Interface would be enough.) >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. Again, you assert that everybody would have to rework existing applications. I say it ain't so. We have real-world experience to show that no changes need to be made in client code UNLESS it wants to take advantage of the new features. The default allocator still uses new/delete unless constructed with a different implementation object. Compile-time allocators are still supported with both the old and new semantics (selectable via traits). Cheers, Pablo Halpern phalpern@halpernwightsoftware.com Author: The C++ Standard Library from Scratch http://www.halpernwightsoftware.com/stdlib-scratch --- [ 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 ]