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.
