Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (hermes.apache.org: local policy)
Subject: Re: Pools, C++, and Exceptions Best Practices
From: Sander Striker <striker@apache.org>
To: David Barrett <dbarrett@quinthar.com>
Cc: dev@apr.apache.org
In-Reply-To: <20041008035639.E729E62494C@striker.xs4all.nl>
References: <20041008035639.E729E62494C@striker.xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1097215621.3309.48.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Fri, 08 Oct 2004 08:07:01 +0200

On Fri, 2004-10-08 at 05:56, David Barrett wrote:
> Is anyone in the audience using apr pools in a C++ application?  Can you
> point to any sample code showing how to override 'new' and 'delete' (or
> manually invoke constructors and destructors) to manage objects within a
> pool?
> 
> Right now I have an ugly mix of pools for apr objects and heap for C++
> objects, and I'd prefer to use apr pools exclusively.  I'm thinking pools
> might complement structured exception handling very well: create a sub-pool
> before each 'try' block, and destroy it in the 'catch' block if an exception
> is thrown.  In theory, this would ensure that whatever data allocated up to
> the point the exception was thrown would be safely cleaned up.
> 
> Alternatively, do you have any suggestions on how best to use pools with
> C++?  Currently I'm just creating a pool for each object in its constructor,
> and destroying it in the destructor.  Am I on the right track?

You'll be eating through your available memory at a pretty quick rate
this way.  Each pool preallocates 8k.  In your case this means that
every object you instantiate, you allocate 8k.

TBH I don't know how well pools map to your usage pattern.  At least not
without an efficient implementation of apr_pfree (which is currently not
part of the API).

Sander