From 6345601513364871143 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 15 Aug 2005 12:00:01 -0500 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 From: "Greg" Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Organization: http://groups.google.com Message-ID: <1124124407.332662.198550@o13g2000cwo.googlegroups.com> References: <7ibbe1hu4omoqsfibanas46idf9u6i5hjo@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=192.31.106.42; posting-account=0QL4PAwAAADpmPfSbEDCW30Gyk6SNwDY X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Mon, 15 Aug 2005 11:51:34 CST Lines: 18 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-h6lRUvoiMqdhsu71VpLYNa/50hC7D/v+xyq34ija5ycCnC7ksxQwutHZGyO7q1UpL/pGnSZU3sx4o0M!4fQmQFJbP5eZHZukJIq/5tyDdBTdQNBfOLJpfc9ckxwdmQ4i9ewTzm1FdaqdwASafjPXd47ONIDC!LgHE2J1qjjm3r1MNhOM/WPgRJQH0dpuIkkJwLR04mB0= X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:1813 I can certainly sympathize with the desire to avoid mentioning an allocator's type in the type of a container. For hard real-time applications that make heavy use of custom allocation strategies (e.g., memory pools, stacks, etc.), interoperability with separately developed libraries predicated upon the use of std::allocator can be too costly if not impossible. The other issues Pablo raises notwithstanding, I wonder whether a standard-supplied concrete allocator handle/polymorphic body pair would help mitigate this problem somewhat by encouraging library authors to support this interface? --- [ 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 ]