On Fri, Sep 14, 2007 at 10:21:12PM -0700, Darren Reed wrote:
> David Young wrote:
> >On Wed, Sep 12, 2007 at 11:24:09PM -0700, Darren Reed wrote:
> >> David,
> >> 
> >> Please don't put inline functions in header files, especially using
> >> names that are all in capital letters and thus look like macros.
> >
> >I don't see any harm in putting inline functions into header files,
> >especially not when they will be shared by many C files.  I don't know
> >where else to put inline subroutines that C files will share; maybe you
> >can suggest some place.  Lowering the case of macros turned to inlines
> >is a lot of pain for very little gain.
> >  
> 
> ...why are they better served by being an inline function than a macro?

With an inline function, no backslash line continuations are necessary.
You get compile-time type checking, and useful line number information
for compile errors.  Function arguments are evaluated once and only
once---that is, no surprise side-effects.  Function arguments are "atoms"
(each use doesn't need to be parenthesized).  You get a new scope, so
that arguments and temporary variables don't need leading underscores
added to keep them from conflicting with variables in the caller's
scope.  Inline subroutines are contain less syntactic clutter (parens,
underscores, backslashes) so they are easier to read and to write.

I don't think that macros can be justified in new code, except where
a macro has a unique capability; for example, syntactic fiddling with
the # operator is needed.  In old code, I don't think there is any use
preserving a macro if an inline will do.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24