From -6252457396621150384 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c66ceaccc8f25e6b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-04-12 03:41:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!colt.net!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: "James Kuyper Jr." Newsgroups: comp.std.c++ Subject: Re: Allocators, standard containers, and assignment Date: Fri, 12 Apr 2002 10:40:38 GMT Organization: Giganews.Com - Premium News Outsourcing Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3CB63333.A97E7E27@wizard.net> References: <42aba677.0203291151.ff4f74c@posting.google.com> <3ca4e319$0$20850$724ebb72@reader2.ash.ops.us.uu.net> <42aba677.0204051121.59ee7aca@posting.google.com> <3cae209e$0$19654$4c41069e@reader1.ash.ops.us.uu.net> <3CAE478F.ECDBDB2C@wizard.net> <3CAFB23E.A7A68E71@wizard.net> X-Trace: mail2news.demon.co.uk 1018608043 mail2news:6860 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) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Thu, 11 Apr 2002 19:56:14 CDT X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly Lines: 121 Xref: archiver1.google.com comp.std.c++:10531 xleobx@qmailcomq.com wrote: > > James Kuyper Jr. wrote: > > >> int a = 5; // allocation strategy: data segment > >> void foo() { > >> int b; // allocation strategy: stack > >> b = a; > >> ... > >> } > >> > >> Are you surprized that `b' dies at the end of foo()? I don't think so. > >> Why should other objects be any different? Allocation strategy is > >> presumed to be a part of an object's type, not part of an object's state. > > > a and b have the same type, yet different allocation strategies. I think > > One can say (loosely) that `a' is actually `extern int', > whereas `b' is `auto int'. Which means that they have the same type, but different storage classes. .... > > Note: it doesn't matter whether containers swaps allocators, if all such > > instances are equivalent. Therefore, I'm assuming that this discussion > > Yes, as far they are of the same type. Containers can only legally swap() if they have the same type. All of the standard-defined container types, (which are the only container types for which the standard says anything about allocators) are templated by Allocator type, so they can only swap() if they have the same Allocator type. > > is specifically about Allocators with inequivalent instances. It must > > Or, rather, where an allocator may be made a part of the state. I'm unclear what it is you mean there. If all instances of an allocator type are equivalent, even if they are part of the state (whatever you mean by that), then any one of those instances may freely be used to deallocate memory allocated by one of the other instances (see table 31, the entry of == ). I don't see that there's any reason, in that case, to worry about which instance you're using. > > What does change when swap() exchanges inequivalent allocators along > > with the rest of the container's contents, is the set of objects that > > can be deallocated. I think we can safely presume that a container > > should always be able to deallocate it's own contents. > > Also it should always be able to ensure the lifetime of its contents, right? > But if objects are allowed to exchange allocators freely, a long-lived > object can get an allocator for short-lived memory. I don't understand what you're saying. You've got two instances of the same allocator type, one of which has a different lifetime than the other. I'd say that code which terminates the lifetime of an the memory allocated using a given allocator instance, while that allocator instance is still in use by a container, is defective. It's not clear to me that there's any special problem with avoiding such code. Your example below doesn't qualify, for the reasons I give below. > > If swap() does swap allocators, then it can be a constant-time > > operation, and satisfy 23.1p10, without using heavy pointers. I consider > > this a very strong argument in favor of swapping the allocators. > > However, because of 20.1.5p5, I can't actually claim that this is > > required. > > Yes, it can, but it will wreak havoc, akin to returning pointers to > stack or temporaries, that is much harder to debug. I don't follow that. Can you provide an example? .... > > I'm afraid I don't follow that. I've never seen code that uses > > allocators with inequivalent instances; support for them is > > experimental, and I've never seen one of the experiments. When you > > swap() the contents of two containers, all iterators, pointers, and > > references to elements of the first container become iterators, > > pointers, and references to elements of the second container. That's > > only possible interpretation of the validity requirement - they can't > > become iterators pointing at the corresponding element of the original > > container, because the two containers might have different numbers of > > elements - there might not be a corresponding element, and such > > iterators/pointers/references could not possibly remain valid. > > This is not what I meant. Assume the allocator is a part of an object's state, > the syntax is for demonstration only. > > template class ShortAlloc .... > > vector a; // with the default allocator > > void foo() { > ShortAlloc::init(); > { > vector b(ShortAlloc()); > ... > a.swap(b); > } > ShortAlloc::fini(); > } > > ....and the fact that `a' points to the dead storage goes unnoticed. a and b have different types. 'a' has the type std::vector >, while b has the type std::vector >. Table 65 only requires a.swap(b) to work when 'a' and 'b' have the same type. The only signature required by the standard for std::vector.swap() is one that takes a std::vector& argument (23.2.4.2). An implementation is free to add an overload that accepts other arguments (17.4.4.4), but the behavior of that overload is not governed by the C++ standard, except insofar as it must not interfere with legal calls to swap(). --- [ 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 ]