From dev-return-14202-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun May 15 19:31:59 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 65693 invoked from network); 15 May 2005 19:31:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 May 2005 19:31:58 -0000 Received: (qmail 21990 invoked by uid 500); 15 May 2005 19:36:27 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 21690 invoked by uid 500); 15 May 2005 19:36:25 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 21149 invoked by uid 99); 15 May 2005 19:36:21 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from out-2.mail.amis.net (HELO out-2.mail.amis.net) (212.18.32.14) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 15 May 2005 12:36:20 -0700 Received: from localhost (in-3.mail.amis.net [212.18.32.22]) by out-2.mail.amis.net (Postfix) with ESMTP id 3C712108FCA for ; Sun, 15 May 2005 21:31:26 +0200 (CEST) Received: from in-3.mail.amis.net ([127.0.0.1]) by localhost (in-3.mail.amis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94949-01 for ; Sun, 15 May 2005 21:31:24 +0200 (CEST) Received: from smtp.amis.net (smtp.amis.net [212.18.32.41]) by in-3.mail.amis.net (Postfix) with ESMTP id 35D02FB905 for ; Sun, 15 May 2005 21:31:24 +0200 (CEST) Received: from palantir.xbc.nu (cpe-212-18-56-180.cable.amis.net [212.18.56.180]) by smtp.amis.net (Postfix) with SMTP id F0528396805 for ; Sun, 15 May 2005 21:31:23 +0200 (CEST) Received: (qmail 29162 invoked from network); 15 May 2005 19:31:23 -0000 Received: from unknown (HELO ?172.17.19.19?) (172.17.19.19) by mx.xbc.nu with SMTP; 15 May 2005 19:31:23 -0000 Message-ID: <4287A39B.8020307@xbc.nu> Date: Sun, 15 May 2005 21:31:39 +0200 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wes@page.ca CC: dev@apr.apache.org Subject: Re: RogueWave Standard C++ Library proposal in Incubator References: <20050515035103.GY28303@scotch.ics.uci.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at amis.net X-Spam-Status: No, hits=-2.589 required=5 tests=[AWL=0.010, BAYES_00=-2.599] X-Spam-Level: X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Wesley W. Garland wrote: >You know, all they'd need to do is overload the STL constructors to >use APR pools > Actually, it's the allocators that would have to be overridden, not the constructors. And you, as the user of the stahdard library, are free to override the allocators (both ::operator new and std::allocator used by containers). >instead of malloc and they'd be have a product I'd use >in a heartbeat. > > Not that I can see how pools would be better for C++ object allocation... it sort of defeats the "resource allocation is construction" idea if your "freed" objects hang around in memory until you happen to clear a pool. >But then it wouldn't meet the ISO standard. Hmm... > > In fact, the standard doesn't specify that ::operator new and friends should call malloc(). The library is free to use a different allocator. -- Brane