apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann ...@bee-ware.net>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 12:51:07 GMT
Branko ─îibej wrote:
> Yann wrote:
>> Sorry I didn't explain myself very well.
>>
>> I don't wan't to play with pointers, of course, a single sizeof won't 
>> allow me to do much more then a memcpy().
>>
>> For example ( innocently :p ) :
>>
>> struct mystuct {
>>     apr_pool_t p;
>>     ...
>> } myvar;
>> apr_pool_t p;
>>
>> apr_pool_create(&p, NULL);
>> memcpy(&myvar.p, p, apr_pool_sizeof());
> 
> How is that better than just putting an apr_pool_t* in your struct? So 
> it's inheritance by reference instead of by containment, semantically 
> it's equivalent (given that this is C).
> 
> -- Brane
> 

Think at this struct instead :

struct mypool_t {
	apr_pool_t p;
	apr_pool_t *owner;
	...
};

It is strictly compatible with apr_pool_t one, as I can use mypool_t* or apr_pool_t* with
the APR or derivative functions.

But I can add my own functions which, for example, attach/detach pools to/from each others
with the 
apr_pool_cleanup_register()ing mechanism (or make the my_prealloc() function).

So that I can create objects that can be affected to different pools, depending on whom they
belong to for a particular 
treatment (handled by a thread that can die with its pool anytime for example again).

The actual apr_pool implementation does not allow to join subpools to another pool after creation
(the apr_pool_join is 
a noop as far as I know).

Yann.

Mime
View raw message