From 7833323159194687091 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c66ceaccc8f25e6b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-04-23 17:46:01 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: Wed, 24 Apr 2002 00:45:10 GMT Organization: Verio Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <42aba677.0203291151.ff4f74c@posting.google.com> <3CAE478F.ECDBDB2C@wizard.net> <3CAFB23E.A7A68E71@wizard.net> <3CB63333.A97E7E27@wizard.net> <3CBBA3CC.B434A21C@wizard.net> <3CBEB889.4CB46076@wizard.net> <3CC23645.AB823219@wizard.net> X-Trace: mail2news.demon.co.uk 1019609117 mail2news:9567 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: Mon, 22 Apr 2002 23:43:53 GMT Lines: 45 Xref: archiver1.google.com comp.std.c++:10776 James Kuyper Jr. wrote: >> Maybe. What, again, is a compelling argument in favor of >> allowing inequivalent allocator instances? > I hadn't realized you were arguing against that feature. The > prototypical example of an allocator type with inequivalent instances, > is one where each independently constructed instance of the allocator > manages a seperate pool of memory. Generically, it would seem there Currently I do it with a type templated by (magic) integers (when all compilers that we use support global variables as templates, I'll use global variables instead). > would have to be some situation where that feature would be useful, but > I don't claim to know of any. I'm fascinated by the concept of > allocators with inequivalent instances, mainly because dealing with them > properly imposes so many interesting complications for the > implementations of containers, not because I have any actual use for > them. They are either an appalling wart on the concept of allocators, or > a powerful extension to the concept, but I'm not sure which - possibly > they're both. :-) I'll agree. > The standard specifies what a==b means for Allocators, and of course > support for inequivalent instances is encouraged in 20.1.5p5, so a fair 2.1.5p4 says "it's OK to cut corners"; 2.1.5p5 says "you're encouraged not to cut corners". Guess what will the commercial implementors do? > number of people on the committee must have thought it was worthwhile to > allow for a==b to be false. Would anyone care to explain why? I'm more interested in seeing an explanation of 2.1.5p4/2. I am really annoyed by it, having to port software to a 64-bit platform. 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 ]