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
space.
> 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
here.
> 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
>
Regards,
Yann.