Erik Huelsmann wrote:
On 6/6/08, Ryan Bloom <[EMAIL PROTECTED]> wrote:
I don't think that there is any reason to not have a sizeof()
function, other than any code that does "play" with the pointers will
be non-portable code. The reason that I originally went with opaque
data structures (I did it before giving the code to the ASF), was that
most of the structures are defined totally differently on each
platform. By making the structures opaque, it became much harder for
a developer to write code with APR that worked on some APR platforms,
but not others. If you play with the pointers, your code is very
likely to work only on the platforms that you code on.
But, I would like to hear from some of the active developers about this as well.
Well, as soon as you provide its size, it's not completely opaque
anymore, now is it :-)
Yes of course, but as soon you provide an accessor it isn't neither ...
I think the entire issue is centered around the fact that Yann doesn't
really want to play by the pool-rules...
I would love to play with the APR pools if they could become subpools of others
after their creation.
That is, a pool being the whole object (destroyed with its pool), and objects
living or dying with their changing owners.
Why couldn't that be compatible with the pool rules ?
I've been subscribed to this list a few years now. I've heard people
regretting that APR uses pools for all of its portability
functionality. I've seen the Subversion devs juggle with pool life
time problems, but I've never heard anybody wanting to copy pools.
Having done quite my share of pool life time juggling myself, I really
don't understand the desire to copy pools around: you have the
pointer, you don't know what else has a pointer...
Bye,
Erik.
I explained myself for what I intended by a copy, this is not really a copy, just the possibility to use the apr_pool_t
as a first field of a structure to make this one compatible with the apr_pool_t struct.
I can do that without the sizeof(apr_pool_t), or a function that returns it ...
Regards,
Yann.
