Re: [E-devel] Re: E CVS: apps/efsd raster

[<ra...@ra...>]

On Tue, 2 Oct 2001 17:57:21 -0700 Michael Jennings <e-...@ka...> babbled
profusely:

> On Tuesday, 02 October 2001, at 19:32:26 (-0500),
> Lyle Kempler wrote:
> 
> > I stick by my original assertion. Anything longer than a line (in
> > regular code, not in macroland, where 10 lines of code sometimes get
> > packed into a single 1-line macro) should be an inline whenever
> > inlining code is available -- if you're doing it primarily for speed
> 
> I assume you're referring to inline functions?  As far as the
> resultant code is concerned, inline functions and macros are
> identical.  The only real difference is that one is portable (macros)
> and one is not (inline functions).
> 
> Furthermore, macros are a very good way to replace repetitive bits of
> code.  You can also use them to alias functions.  (They provide a more
> sensible method, IMHO, than function pointers in cases where the
> aliasing is known at compile-time.)  I certainly disagree you cannot
> replace more than one line of code with a macro and be justified in
> doing so.
> 
> For example, you can find any number of multi-line macros in the Eterm
> header files.  Many of them are specifically used to portably
> implement inline functions.  Others are designed to replace repetitive
> code snippets which I do not feel warrant functions in their own
> right.  Still others are imployed to provide direct access to function
> local or block local parameters without having to pass pointers to
> functions.  The trick to using macros well is establishing and
> following a standard (e.g., using names in all-caps) and defining
> macros in a standard, predictable place (like in one big bunch in the
> .h file of the same name).
> 
> Macros can even be used to encapsulate implementation details inside
> what seems to be a function-based interface.  For example, using a
> BEGIN/END macro pair could employ nothing at all, or simple braces, or
> even variable initializations and declarations.  These could even be
> interchangeable with #ifdef's to support various
> initializations/cleanups in a given function.
> 
> Macros can be used for all sorts of things.  As long as they are
> self-contained and clearly defined, there is no reason to avoid them.

agreed. its not a matter of setting rules like "1 line is the limit"

it's a matter of looking at the situation and taking an appropriate action. in
my case macros here access local block parameters, and make the task of
repetitive declarations simpler.

some of the config stuff is functions - where warranted. some is macros -
wrapping accesses to some of the config functions, avoiding repetition and
saving time writing that repetitious code.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    ra...@ra...
Unemployed Bum                      ra...@de...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362