apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <rbl...@gmail.com>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 13:28:46 GMT
On Fri, Jun 6, 2008 at 9:18 AM, Yann <yl@bee-ware.net> wrote:
> 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 ?

If this is what you really want/need, then I would suggest focusing on
a patch that implements this functionality.


Ryan Bloom

View raw message