From 8473244753566370406 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!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Sat, 03 Sep 2005 14:10:49 -0500 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 From: lancediduck@nyc.rr.com Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Organization: http://groups.google.com Message-ID: <1125769160.339942.74620@g43g2000cwa.googlegroups.com> References: <9pchf11o63qib8h56fap5g5445gjac5ce2@4ax.com> <1124790086.351633.74880@g14g2000cwa.googlegroups.com> <48sch1lclsrtqr6tcgfns9jinmo1ecmdsb@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50215),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: g43g2000cwa.googlegroups.com; posting-host=66.108.12.24; posting-account=3mYY3wwAAADRamnjcYfRKWdoFpb0mshK X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Sat, 3 Sep 2005 14:04:04 CST Lines: 133 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-VAX30dDLFdine5aJHuD9Jv2HCVRwvD5EghbqmTGidff+tDauLN80aTV+2gV9NQHrdTPcLK1ciMlREAN!419bGjnpqqzBbePSg45U/cQHXKEn6ofcBxgXR4nPLn3/ouoOtL3+dV94bblJjZJrpcseyViS4CrP!Cmv9mAOZMCuf8uy5XacuffnO/8UiEfhlqBNmrV209A== X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:2009 -->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. They aren't issues, but observations. This weekend I'll correct some spelling errors and references and post it for all to reference. Specifically -- 1. The "asymmetry" does not cause one to lose control over allocators. Indeed the paper presents code examples on precisely how to maintain control. Perhaps I need to speak to the examples more. 2. It is not difficult at all to resize a vector where the allocator does not have a default constructor. Indeed, the very same code example demonstrates how to do it. 3. It is not difficult to get a container and its contained elements to "share" the same allocator. Again, the code sample shows you how. 4. It is unclear what certain constructs should do because there are no postconditions specified for operations on containers that test allocator comparisions Mr. Hinnant sounds like he has done a lot of work in this area - personally I don't care WHAT the standard behavior is for "unequal allocators," as long as it is standard - that tells me when I need to make a specialty container, and when I don't. >You may be zeroing in on the default allocator because it is probably >the most controversial part of the proposal No-I am zeroing in on changing std::allocator< > from being stateless to having state (i.e a this pointer) as the library default. Right now the state of the world is that it is the other way around. >>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. They are already "interoperable." I'm sure we all know how to make them interoperate using the std algorithms, so that point is moot. If you are looking for "interoperability" between libraries deployed in binary form, which I think you are trying to achieve, then using ANY template library to achieve that, no matter what namespace it resides in, is likely a misapplication. Trying to make std::vector or std::string (what about std::wstring??) binary compatible is a misuse of a STL library implementation, not a problem with the library design itself. It is easy to make STL compatible binary compatible containers -they just don't reside in ::std. If all you are trying to do is just make a way to pass allocators around and want your solution to live in namespace std ... "vocabulary type" is an application domain concept. We don't have to change the standard to solve application problems. --> 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. It works fine against my code too. Why? Because I have learned, from most other successful libraries out there, not to rely on ANY STL implementation for anything critical. I have often had to incorporate TWO STL implementations in the code to get things to work (I've used your offering and the native simultaneously too) This is not a new practice. Many libraries avoid using the C standard libraries for the same reason - they don't have to eat someone else's bugs. But that is library coders. Most C++ programmers are just guys wanting to get their job done, and not manage the needs of libraries. The default polymorphic allocator, required for backward compatibility, just adds to the list a things that the library needs, and a library users has to manage. As for the "million of applications" --The upgrade process would be this if the proposal were adopted: first, compiler writers would contract with the library vendors to get upgrades. The vendors will have to modify their expensive tests to account for the proposed changes. The compiler vendors would test the new libraries with the systems guys. These compilers would now be delivered. The embedded systems community quits using any of it because their platforms can barely handle the stateless allocator containers they have been trying to adapt for 10 years. OK the corporate and academic IT guys are still on board - and remain noncompliant until they recompile and retest their libraries just for the sake of now making "polymorphic allocators" the default. Changing this portion of a well established standard is not academic. -->We have real-world experience to show that no changes need to be made in client code I have real world experience with this too. TONS of it. You are correct that no application code syntax changes are needed, only systems requirements change (i.e. that pesky default polymorphic allocator), to get exactly what you had before. What did that buy me? Other than needing to support more system requirements?? As for the "adapter" OK I'll try to write up a sample and try to test it with an implementation using an EDG front end with Plum Hall suite of tests. It isn't high on my to do list, but easy enough. The problem is detecting when a type can take an extra allocator argument. "traits" probably isn't good enough for a general solution, but good enough for a demo of vector of fairly simple user types. There are ambiguities in the standard about type deduction in partial specialization, so THAT part of the standard would have to be "enhanced" as well. Like I said -- TONS of real world experience with this. I would invite you to study the COM Automation containers, which there are STL wrappers for. These are the "vocabulary types" and "interoperability" concepts you are looking for. Also look at the work of the CORBA community. I invited J Lakos to make this same study as well -- maybe it needs to be said on a public forum instead???? But thanks for making the proposal -it gets the community talking about this again. Good conversation and good reason to pour a few extra beers!!! :) Cheers Lance --- [ 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 ]