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

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

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


Jason Short wrote:
[...]
> I can't believe this is being used as an argument *against* using
> functions in favor of macros.  Although the order of evaluation of
> arguments may be undefined in an inline function call, at least you know
> that each argument will be evaluated *exactly once*.  In a macro you get
> no such guarantee.
> 
> jason

Since you can write macros to explicitly evaluate arguments once and this is
in fact what Freeciv iterators do and what various commentaries state fairly
strongly is the correct way to write macros, I find it rather amusing that you
are trying to use the "we can write bad macro code so macros must be bad" line
again. We know you can write bad code, but generalizing this as arguments for
or against some coding practice is not really germane.

It is not the fact that the order is not defined, it is the fact that with
inline vs function calls, even in the same compiler you can get different
results with the same code and arguments.

It just further shows the randomness of trusting to inline hints and problems
it is liable to cause in debugging when identical code acts differently. Given
the issues of portabilty in forcing compiler restrictions for a feature that
is not required, and has worse performance characteristics than other options,
there is nothing but problems and no instances of gains for choosing inline in
"C". This is recognized by those that really do understand.


Is there some reason why you just can't accept such clear facts and need to be
further convinced? If not, perhaps you should go with established opinion both
in Freeciv and in the wider world until you can come up with a set of valid
arguments for disagreeing with established wisdom. Post your reasons for, at
least, and let us see why you are making this fundamental change and starting
on yet another code purge when there are any number of real patches to work on.

And in the future, you should do as you are doing now and debate such changes
in the public forum from the start, so there is some degree of validation and
justification before serious mistakes are made.

Cheers,
RossW
=====