apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann ...@bee-ware.net>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 13:18:42 GMT
Erik Huelsmann wrote:
> On 6/6/08, Ryan Bloom <rbloom@gmail.com> 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.

Mime
View raw message