[Freeciv-Dev] Re: Map coordinate cleanups.

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 10:13 PM 01/08/16 -0400, Jason Dorje Short wrote:
>Gaute B Strokkenes wrote:
>> 
>> On Thu, 16 Aug 2001, jshort@xxxxxxxxxxxxx wrote:
>> >
>> > Are you saying there is a reason other than speed to make them
>> > macros?
>> 
>> Yes.  For one thing, this makes it feasible to put them in other
>> places where it would be silly to use a function.  A slightly cheesy
>> example would be the definition of IS_PROP_TILE(), which basically
>> IS_NORM_TILE && IS_REAL_TILE.  That would be a silly thing to write in
>> terms of functions.  A somewhat more relevant example might be the
>> adjc_dir_iterate() macro you wrote.  I added an assert() which
>> amounted to IS_PROP_TILE() to it before committing it.  This actually
>> had a measurable impact on performance, and having a function call
>> would probably make it even slower.  Doing it this way means that we
>> can use the macro there with no worries.
>
>Um, all of those reasons are just "it is faster".  

Actually they are not. Gaute did a minor oneliner fix and replaced inline
functionally across the codebase in perhaps a majority of files. 

In most cases where these things were written as or included in functions,
people hand coded the tests rather than calling functions because the
function "hid" the definition, functions are known to be slow and it was
only a compare anyway, or similar rationales. The result was a
proliferation of variants on the basic concepts, bastard fixes for obscure
bugs and a host of other evils. 

By putting things in a macro, and defining it with documentation in a
header, you provide people with the "right" way to do it where they will
see it and use it. You also bypass their tendency not to make teh extra
step to lookup the definition of one of the 53 extern declarations in the
same header and just go ahead and hand code the simple test they think they
need.

And when it comes time to rewrite the function or macro, you have far fewer
special cases to root out of mouldering code in one mode over the other.

>I'm not disputing
>that it's faster - I just don't really care.  Despite the
>adjc_dir_iterate macro patch I made, I really don't care about speed
>(especially when it's something a compiler *should* be able to optimize
>anyway).  

>I believe the macro form is uglier, 

Religious wars are ever caused by differing perceptions of beauty ... 
(-: besides anyone who programs in "C" obviously has no taste :-)

>and I don't look forward
>to having to replace it later to allow for orthogonal maps.  

The macro or the function are just equivalent symbolic names for the API
with slighly different implementation properties. But there is NOTHING you
need to change in one case that you will not be changing in the other :-).

That is one of the reasons why people like to use the same name for macros
and functions so that you can make them interchangeable for various
purposes, or replace one with the other when the need arises for the
different implementation properties. That is also why least common
denominator practices "like never use function args with side-effects" have
any validity.

The advantage of functions is that they are not limited in capability the
way macros are, and implementation can be far more complex. And any macro
of more than a page in size is also evil.

>All of
>these are small issues, though, and I don't think we should argue over
>the macro/function thing any more.

Sensible ... I should have read this first.

>jason

Cheers,
RossW