> > > APR_DECLARE_POOL_ACCESSOR(file)
> > > APR_IMPLEMENT_POOL_ACCESSOR(file)
> > >
> > > or somesuch. Since I'm the one with the issue on type safety, I'd be quite
> > > happy to do this work.
> >
> > This isn't possible. The APR_IMPLEMENT_POOL_ACCESSOR function would need
> > to be in the header file that declares the underlying structure, which
> > means it won't be exported.
>
> No... it would follow the hook style. The DECLARE is used in a header, and
> the IMPLEMENT is used in a .c file.
>
> Let's get concrete here:
>
> #define APR_DECLARE_POOL_ACCESSOR(name) \
> APR_DECLARE(apr_pool_t *) apr_##name##_get_pool(apr_##name##_t *ob);
>
> #define APR_IMPLEMENT_POOL_ACCESSOR(name) \
> APR_DECLARE(apr_pool_t *) apr_##name##_get_pool(apr_##name##_t *ob) \
> { return ob->pool; }
>
> This creates type-safe accessors quite easily. It also meets the need for
> getting at a pool, and meets your point about the hooks: "without affecting
> the amount of duplicated code or maintainability."
It is also a real PITA as far as getting the names right. You know what,
go ahead and do what you want. I am not fighting anymore. You should
feel free to create the functions, or the macros. I would prefer that the
existing code stay in place until the new code is working.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------