[Freeciv-Dev] Re: (PR#7279) Macro optimizations

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >


Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >
> 
>>[rwetmore@xxxxxxxxxxxx - Tue Jan 27 02:43:58 2004]:
> 
>>If the maintainers have done their homework, understood ths issues,
>>presented all the arguments and with the concensus of the community
>>reached a decision to change core Freeciv standards or start a new
>>version written in C++, then that is fine.
> 
> Do you think we'll get any consensus?

Lack of concensus defaults to the longtime status quo - standard fix
and thus not really an issue in reaching a conclusion.

But if one argues on non-subjective grounds then concensus is almost
always obtainable. Only when you introduce religion do you introduce
irresolvable components.

> Here are the code requirements I'd impose:
> 
> 1. Each macro must evaluate each of its arguments exactly once.
> 2. No function-like macro should impose additional restrictions that a
>    function would not.  Specifically this refers to the sequence point
>    problem.
> 3. Any macro that pretends to be a loop must respect "break".
> 4. Inlining should only be used when it gives a substantial improvement
> (in speed or code size) over macro or traditional function forms.

   5. The fix should not introduce new/unnecessary restrictions or constraints
      on either runtime hardware or build environment.

> These are all technical specifications.  The point is that any macro
> that looks like a function or loop must _behave_ like a function or
> loop, so that the normal rules of C apply.
> 
> #1 and #3 would require some fixes to existing macros. 

   Existing situations should be fixed when they cause problems or the code
is touched. This is a grandfather clause to eliminate the introduction of
code purges in any form. Time will resolve the issue once the standard is
set.

 > #1 may also
> preclude some current macros from being written in function form. 

Should never be an issue for a competent programmer :-).

 > #2
> and #4 are not currently a problem anywhere AFAIK.

#2 (specific case) is a problem only if one is concerned about lint warnings
for code paths that are never taken :-).

One should detail whether one is concerned about warnings or errors to be safe,
and impose a documentation constraint if there are ignorable warnings.

#4 effectively rules out inlining over macro since it is always going to be
on the wrong side of performance.

One needs to set a list of environments where this is tested that should include
at a minimum the standard ports, and contain the top compilation environments
- GCC linux, Visual Studio, Sun, IBM, Intel etc. What constitutes a test needs
to be defined.

> Discuss.
> 
> jason

Cheers,
RossW
=====