apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: APR_ARRAY_FOO convenience macros
Date Wed, 17 Aug 2005 03:53:25 GMT
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'm especially confused at how you think this is heading to the bad old 
days of a new function for each arg list, when my proposal requires 
exactly two macros, and you don't ever have to declare more functions 
when you want to work with more types of arrays because the type is 
passed in when you invoke the macro.  Now if you were arguing that 
requiring the user to pass in the type is too error prone, I could see 
that side of the argument, but even so I don't see how it's any more 
error prone than the existing state of affairs.

-garrett

Mime
View raw message