[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: question about range_intersect() and range_contains() functions

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-07-06 15:18:16 CEST

On Thu, Jul 06, 2006 at 06:44:33PM +0530, Madan U Sreenivasan wrote:
> >Ok, so what's the benefit of using a macro here? (which is what I should
> >have asked first).
> >
> >The compiler can easily inline a static function if it thinks that's
> >the right thing to do (given the current optimisation settings), and
> >functions have argument type-checking and obvious side effects, which
> >macros don't.
> I think its better to have single line functions as macros, than rely on
> the compiler to detect it.

The compiler is smarter than us, and this isn't performance-critical code
(the callers aren't in tight loops, for example). And what if the user
wants to optimise for space rather than speed? (though admittedly in
this case it's likely that the inlined version of the function might
be smaller).

> >Really, the rule should be that we only use macros where we absolutely
> >have to.
> and when do you think it is? (am asking as a matter of trying to
> understand :)

Apart from constants, which we need to use macros for in C, I say that
we should use macros only when we have no alternative, when we actually
need to use the macro functionality, not for simple function.

Good examples in our codebase would be: the error code functionality
(include/svn_error_codes.h), where we change the macro definition to
generate different output; SVN_ERR(), which generates inline code
that we can't replicate with a function; the token-pasting macros
in e.g. mod_dav_svn/liveprops.c (SVN_RO_DAV_PROP et al); and the RA
compatibility wrappers in libsvn_ra\wrapper_template.h.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 6 15:18:43 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.