From 3426668902177747517 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c66ceaccc8f25e6b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-04-25 05:10: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: Thu, 25 Apr 2002 12:09:38 GMT Organization: Verio Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <42aba677.0203291151.ff4f74c@posting.google.com> <3CAFB23E.A7A68E71@wizard.net> <3CB63333.A97E7E27@wizard.net> <3CBBA3CC.B434A21C@wizard.net> <3CBEB889.4CB46076@wizard.net> <3CC23645.AB823219@wizard.net> <3CC60C6E.61FB874A@wizard.net> X-Trace: mail2news.demon.co.uk 1019736584 mail2news:27706 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: Wed, 24 Apr 2002 21:04:27 GMT Lines: 48 Xref: archiver1.google.com comp.std.c++:10811 James Kuyper Jr. wrote: >> 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? > Both. Most will cut corners, a few will probably experiment. Which is > precisely what the committee wanted. The next version of the standard > should contian a more detailed specification of the semantics. The > committee wanted a few implementations to experiment with the concept, > to build up the experience need to help decide what those specifications > should say. Maybe; but more likely, esp. re: 20.1.5p4/2, because rebinding did not work in many compilers yet. > .... >> 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. > Could you explain that in more detail? std::set and std::map, as specified in the standard, pretty much require a pointer-heavy implementation. Porting an application that uses them actively, from a 32-bit platform to a 64-bit platform on the same hardware will reduce the effective memory cache size in half (what used to take 4 bytes, now takes 8), therefore reducing performance by an unpredictable amount. Without 20.1.5p4/2 there would have been some recourse: specifying std::set > where, roughly speaking, sizeof(based_ptr_allocator::pointer) == 4, so that the size of the set nodes will be the same as before, allowing for more graceful performance degradation. But now the compiler is allowed to cut corners, so, no matter what the allocator is, std::set still uses native pointers for its internal purposes. > By the way, it's 20.1.5, not 2.1.5. Sorry, a persistent typo. 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 ]