From -2678064855296792290 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newshub.sdsu.edu!cyclone.bc.net!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "=?iso-8859-1?q?Ion_Gazta=F1aga?=" Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Date: 9 Aug 2005 20:50:19 GMT Organization: http://groups.google.com Lines: 37 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1123617023.609737.208380@o13g2000cwo.googlegroups.com> References: <7ibbe1hu4omoqsfibanas46idf9u6i5hjo@4ax.com> <9pchf11o63qib8h56fap5g5445gjac5ce2@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-Trace: posting.google.com 1123617029 18812 127.0.0.1 (9 Aug 2005 19:50:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 9 Aug 2005 19:50:29 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=80.58.48.235; posting-account=3igyCg0AAADt_bvshkpvenDPjgfCKhqd X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1729 Hi Pablo, I've been reading your proposal and I find some interesting things, but I agree with Howard that I prefer a non-throwing swapping with unequal allocators. > 3. That containers with different TYPES of allocators be able to > inter-operate, i.e., the type of the allocator does not always affect > the type of the container. > > The last point requires polymorphic allocators. One thing I don't like is a polimorphic allocator because: -> I can't place it in shared memory, because the virtual pointer would be valid only for one process, and I don't think the standard will ever standarize inter-process polimorphic objects (virtual tables, typeid-s, etc...) -> Some allocators, for example, segregated storage node allocators (Boost.Pool, for example), used without synchronization objects like mutexes, just need two pointer operations to allocate/deallocate a node. A call to a virtual function would be maybe too expensive. Although I have no data to prove it as a big reason. Or arena allocators can define deallocations like a empty function that can be easily eliminated if it's inline. Just a point to think about. Regards, Ion --- [ 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 ]