apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Lavictoire <ylavicto...@bee-ware.net>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 12:32:49 GMT
Christopher Key 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());
>> That's all I can do, I can't access any apr_pool field ...
> That sounds like a bad idea to me.  At a conceptual level, just 
> duplicating a number of bytes is not the same as creating a copy.  
> Indeed, the concept of creating a copy is something that can only be 
> defined specifically for each object.

Unless you only want to copy the pointers, which are still valid pointers.

Indeed with the memcpy() you don't create a real copy of the object, but the you can use this
pseudo-copy as if it were 
the original object (until this latter is destroyed of course).

Fields other then pointers in this pseudo-copy are nothing else than unused/wasted memory

> Specific examples why this is so:
> The apr_pool_t struct may contain pointers to other data that cannot be 
> shared between pools.  Again, this data would also need to be copied, 
> but wouldn't in the above example.

As I said above, the goal can't be to create a real copy, and a pseudo-copy use as the original
object is still working 

> The apr_pool_t struct may contain pointers to items within itself.  
> These would no longer point to the correct location after the copy.
> There may be alignement issues with where an apr_pool_t can be stored on 
> specific platforms.  There's no way to guarantee that the copy your 
> create will end up with the correct alignment.
> Plenty of others.

Same applies here, the pointers of the pseudo-copy still point to the original pool (the one
in the allocator), and its 
internal items.

I don't see any platform/alignement issue since apr_pool_sizeof() *is* platform specific too.

> Regards,
> Chris


View raw message