(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 :-)
Cheers,
Ben.
--
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
void *x;
#define define_type(name,type) typedef type name
#define access_as(name,variable) ((name)variable)
define_type(string,char *);
int main()
{
int *a=access_as(string,x);
char *b=access_as(string,x);
a=a;
b=b;
return 0;
}
