[Freeciv-Dev] Re: (PR#7195) inlining map_pos_to_index

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

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


Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >
> 
> Ross Wetmore wrote:
> 
>>1)  Use local variables. Assiging globals to local variables at the start
>>    of a code block and then using only the local variables within the
>>    block lets the compiler know they are not subject to change except if
>>    done explicitly in the code block.
> 
> Using local variables _is_ the greatest thing in the world.  (Except for 
> a nice MLT - mutton, lettuce, and tomato sandwich.  When the mutton is 
> nice and lean and the tomato is ripe, they're so perky.  I love that.)
> 
> But we can't use local variables in a function-like macro that returns a 
> value. 

Why not?
(I'll let you think this statement through again and correct yourself, the
answer is rather trivial :-).

In any event, the problem goes away if you drop the function-like constraint
which is also not usually a problem, just a stylistic preference.

> So our only alternatives are

Please explain why these are the only alternatives (sigh)?

> (1) Do extra calculation rather than store the temporary values.  This 
> is what the macro form in CVS did, and it's definitely slower.
> 
> (2) Use global variables.  This is what your corecleanups patch does. 
> But then the caller has to worry about sequence points and lots of them 
> have to be rewritten.  No good.

Tradeoff in worrying about sequence points vs all the inline problems
definitely falls to the sequence point case. Note, this is no different
than documented and undocumented rules for a lot of the inherent single
threaded code already built into Freeciv. It's endemic use of globals
makes this a long standing current issue, so not worth getting hot and
bothered about in this one particular case.

When there are easy alternatives to avoid it, those should be used. But using
things like [macro-specific] [static] globals in implementation of macros is
not a heavy price to pay for a performance fix.

> jason

Again and again, it is the case that all your absolutely insurmountable
issues with macros are not really technical problems at all, usually just
lack of experience or willingness ot look for solutions.

Are you ready to accept the fact that macros are just "C" code and thus
anything you can do with "C" code can be done with macros?

There is nothing to be gained by using inline functions except real
performance loss and technical problems including limitations on the
portability of the Freeciv codebase. The fact that C++ was initially
implemented as a preprocessor producing "C" code should tell you that
inline functions are unnecessary. Their functionality can be handled in
properly written and structured "C" code.


Cheers,
RossW
=====