From 5288168952612369461 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c66ceaccc8f25e6b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-04-20 19:08:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: xleobx@qmailcomq.com Newsgroups: comp.std.c++ Subject: Re: Allocators, standard containers, and assignment Date: Sun, 21 Apr 2002 02:07:21 GMT Organization: Verio Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <42aba677.0203291151.ff4f74c@posting.google.com> <42aba677.0204051121.59ee7aca@posting.google.com> <3cae209e$0$19654$4c41069e@reader1.ash.ops.us.uu.net> <3CAE478F.ECDBDB2C@wizard.net> <3CAFB23E.A7A68E71@wizard.net> <3CB63333.A97E7E27@wizard.net> <3CBBA3CC.B434A21C@wizard.net> <3CBEB889.4CB46076@wizard.net> X-Trace: mail2news.demon.co.uk 1019354846 mail2news:2202 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au 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) User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (FreeBSD/4.4-RELEASE (i386)) NNTP-Posting-Date: Fri, 19 Apr 2002 22:39:13 GMT Lines: 48 Xref: archiver1.google.com comp.std.c++:10741 James Kuyper Jr. wrote: >> ... In brief, my point is (please ignore what I previously >> said - it takes me time to distill what I mean) that containers, >> as an abstract concept, do not (and should not) care about allocators, > OK. The next question is, why? I think that your claim that they "do not > .... care" is true to some extent, but only because most containers are > currently not written to handle allocators that have inequivalent > instances. However, it seems to me that containers should care about > allocators, particularly when written to handle ones that allow > inequivalent instances. Well, the allocators in and of themselves are a reflection of limitations of the operating environment: limited amount of memory (that's why we want short lifetime memory pools), limited memory performance (that's why we want locality-optimized allocators), or limited memory persistence (that's why we need special handling for the objects that need to persist across processes). (Did I miss anything?) But all that is beyond the scope of the concept of a container, and I believe that bringing any additional allocator-related semantics (i.e. abolishing 20.1.5.4req1) into the objects that represent containers is not needed. What I would want instead is to abstract the concept of a pointer (i.e. to abolish 20.1.5.4req2) and require all standard containers to use Allocator::pointer wherever T* is needed, etc. Think shorter (based) pointers, allowing for memory-efficient implementations of std::set and std::map. > In your reply to Kevin S. Van Horn you claimed that treating the > allocator as part of the container's state is error prone. It's > certainly error prone, if you aren't expecting it to be treated as part > of the state. However, I don't think you've established the case that it > would be more error-prone than the alternative would be, when used by > developers who expect the container to treat the allocator whichever way > it actually does treat it. Maybe. What, again, is a compelling argument in favor of allowing inequivalent allocator instances? Leo --- [ 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 ]