apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 17:51:06 GMT
Yann wrote:
> 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.

Maybe you should just live with the fact that this is C, not C++, so any 
kind of fake polymorphism will be just that -- fake. Even if apr_pool_t 
wasn't opaqe, you'd still have to add a cast in order to make the 
regular apr_pool functions digest your new struct, and frankly, an 
explicit indirection is better than a cast any day -- because it 
preserves type information.

-- Brane


Mime
View raw message