apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: APR_ARRAY_FOO convenience macros
Date Sun, 09 Oct 2005 20:38:36 GMT
(Reviving a very old thread)

Garrett Rooney wrote:
> William A. Rowe, Jr. wrote:
>> Yes, but (especially registered functions) allow you to set
>> up an argument type/argument list by casting a function ptr,
>> rather than the actual data object.  This means that every
>> invocation of APR_FN_type_FOO will accept only a certain type,
>> enforcing typesafety.
>> Ben went to the trouble of figuring it out (brilliant!) so
>> I'd happily veto wrappers which don't enforce type safety.
>> I don't want to return to the 1.3 mod_ssl days (of a new
>> fn for each arg list) after we have such an elegant solution
>> at hand :)  Take some time to grok
>> http://svn.apache.org/repos/asf/apr/apr-util/trunk/include/apr_optional_hooks.h 
> I've read apr_optional_hooks.h and looked at the underlying 
> implementation, and I don't see how this gains us a whole lot.  What it 
> does seem to do is add complexity by requiring the user to declare and 
> then retrieve their accessor functions, and on top of that it sure 
> doesn't seem to be thread safe, what with its use of global variables in 
> apr_hooks.c with no apparent locking.
> On the other hand, we've already seen these accessor macros used to 
> great effect in a large codebase, and I know for a fact that they make 
> it much much much easier to work with APR arrays.  No, they do not solve 
> all problems, but they do improve the situation without adding a great 
> deal of complexity.
> If I'm getting the wrong impression, and it really is far simpler to 
> make use of these APIs for the purpose of providing helper functions for 
> the APR array interface than it seems at first glance, then could you 
> please explain how, perhaps by sketching out how you'd see the interface 
> being used.

I doubt its simpler to implement them, but the strength of the hook and 
optional function implementation is that it ties the types of the 
various pieces to the name of the function or hook. So, it doesn't rely 
on you putting the correct type in every time you access. Or, more to 
the point, code that relies on you noticing that you changed the type.

I suspect the same trick could be employed to make APR array access 
typesafe by creating named accessor functions that enforce the types. 
There may be other ways (precompilers work well here :-) that avoid 
having to use functions, but given that many modern compilers can inline 
functions, perhaps that's not an issue.

In fact, thinking about it, creating non-functional access methods 
linked to names is trivial. See the attached program, which produces a 
warning at the appropriate spot.

Or, in short, the difference between what I did and what you did is a 
typedef :-)



http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

View raw message