[Freeciv-Dev] Re: Map coordinate cleanups.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Aug 16, 2001 at 11:17:03PM -0400, Ross W. Wetmore wrote:
> 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.

So you argue we should use macros because they have the documentation
in the header? Don't you think we should document the functions and
put the documentation in the header?

> 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.

Why?

> >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, 

Ack.

> 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.

You loose the ability to profile with macros. If a small method like
get_tile_type() gets a top position in the profile you can either:
 1) make get_tile_type() faster (only a macro can do this)
 2) search why get_tile_type() get called this often (it has to be
 called a lot to get such a top position in the profile)

I would first do 2) and only if there no chance to reduce the amount
of calls to the method would apply 1). If you change a method to a
macro you loose the ability of doing 1).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Programming today is a race between software engineers striving to
  build bigger and better idiot-proof programs, and the Universe trying
  to produce bigger and better idiots. So far, the Universe is winning."
    -- Rich Cook