Hello, Ryan Bloom wrote: > I really don't think we should take a function like apr_pcalloc and > convert it to a macro. The only reason to go to a macro is for > performance reasons. First, the performance boost should be > relatively minimal, and for anybody who needs it, they can use > apr_palloc and memset themselves. I agree, I only suggested a macro as it is one now.
> As for documentation mentioning if it is a function or macro, I don't
> think we should do that. macros should be written so that arguments
> aren't evaluated multiple times.
In general there is also the problem of taking the address of a
function/macro. i.e.
alloc_func = &apr_pcalloc;
doesn't work when apr_pcalloc is a macro.
> If the documentation says what is macro, then that is almost
> guaranteed to be out of date at some point in the future.
That's an alltime present problem with documentation. I think doxygen
can distinguish these two cases.
> And, what happens when sometimes it is a function and
> sometimes it is a macro, depending on the compiler used or what
> #defines are set?
One more reason to say something like: "This is sometimes a macro and
sometimes a function". If a developer uses something like taking the
address of a function/macro, it works on his platform and there is no
hint, that it doesn't on an other.
Regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=1+electron+mass%3D
signature.asc
Description: Digital signature
