[OpenAFS-devel] Refactoring the Solaris libafs code base

[chas williams - CONTRACTOR]

In message <200701041133.GAA15986@quince.ifs.umich.edu>,Marcus Watts writes:
>Yes, I know inline functions can do nifty things, but I also think of
>this as being in part a pernicious influence from c++.  The problem
>with inline functions is that it's easy to abuse them to get bad code
>bloat, and debugging anything real complicated with them can get very
>very weird.  What does a breakpoint mean in an inline function?

its less of a pernicious influence from c++ than a readability issue when
compared with #define and \'s.  you can also put #ifdef's in an inline
of course.

>Also, I would recommend being *sure* inline functions perform
>equivalently between all supported systems before relying on it.  ibm,
>sun, microsoft, & gnu do not implement quite the same language.  I'm

again since the intended use is to work about o/s specific problems and
should only be in src/afs/PLATFORM, if you compiler doesnt support static
inline, use the #define strategy.

>outside of that subset).  There are also things you can do with
>a #define that you can't do with a C inline.  (Or at least couldn't;
>in c++ you can and it could be spreading...)  For instance,
>treating parameters as lvalues.

yes there are a few things we cant do well but where we can make
the code easier to read (and therefore understand) it would be preferable.

>in one #define, because it won't behave right with "if".  
>Bracket with MACRO_BEGIN MACRO_END if you can to do this.

i like the explicit do while { } (0) notation better.  i think
more people understand what this means instead of MACRO_BEGIN/MACRO_END