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

["Arnstein Lindgard" <a-l@xxxxxxx>]

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

On Fri, 23 Jan 2004 09:05:09 -0800 rwetmore@xxxxxxxxxxxx wrote:

> I tried to figure out what the actual problem was that you ran into and
> Jason is trying hard to bill as some critical issue with map_to_index().

I believe this is another defaultism debate, and should not focus on
a special case.

I didn't save my useless macro, but this is what map.h looked like
before Jason inlined:

#define map_pos_to_native_x(map_x, map_y)                                   \
  (topo_has_flag(TF_ISO)                                                    \
   ? (((map_x) - (map_y) + map.xsize                                        \
       - (((map_x) + (map_y) - map.xsize) & 1)) / 2)                        \
   : (map_x))

#define map_pos_to_native_y(map_x, map_y)                                   \
  (topo_has_flag(TF_ISO)                                                    \
   ? ((map_x) + (map_y) - map.xsize)                                        \
   : (map_y))

#define map_pos_to_index(map_x, map_y)        \
  (CHECK_MAP_POS((map_x), (map_y)),           \
   (map_pos_to_native_x(map_x, map_y)         \
    + map_pos_to_native_y(map_x, map_y) * map.xsize))

Now it is:

static inline int map_pos_to_index(int map_x, int map_y)
{
  /* Note: writing this as a macro is hard; it needs temp variables. */
  int nat_x, nat_y;

  CHECK_MAP_POS(map_x, map_y);
  map_to_native_pos(&nat_x, &nat_y, map_x, map_y);
  return nat_x + nat_y * map.xsize;
}

If you believe this inline has merely hidden a symptom, you should
compare against the previous code rather than asking for the code of
my failed experiment, which was based on inferior understanding. I'm
not sure you would resist applying more smoke and mirrors.

Unless the inline is inherently dangerous, the advantages seem clear:

1. It's pretty. Nice colors. Less brackets. No backslashes.
2. No need to maintain two forms of a function for type checking.
3. We can add local variables wantonly, without breaking POSIX or
   bloating the interface.

This is sufficient grounds for rethinking conformity to tradition.
The fact that gcc takes a progressive stance on inlining, is a hint
to the programmers that we may or may not choose to take.

There should be clear reasons for banning inlining. So far, the
misleading warning about undefined order of evaluation of function
arguments is clearly irrelevant. We foolhardly assume that the ISO
standards commitee has not yet been taken over by kamikaze coders. If
the undefined order was a problem, they simply would have defined it.

If there are true arguments against inlining, they should be
presented clearly for scrutiny. If arguing in circles around the
opposition camp's position was a silver bullet around here, we'd all
be writing Python already.

The superior power of macros can certainly be useful in some
situations. If you want to run a campaign for a particular coding
style as a crusade against inlining, you may find yourself implicitly
defending the position that all functions should be rewritten as
macros because it presents more power we don't need.

If there are risks associated with inlining, the risks should be
clearly defined and assessed. Risk assessment is entirely a
mathematical science.

I prefere not type checking my arguments in either political or
technical debates. While I would not use the word "incorrect" I would
say it is "politically incorrect" not to clash political arguments up
against technical ones.

Coding is a technical process involving coders. Maintainability, ease
of use, and just plain likeability are perfectly valid arguments that
may trump pure technical ones. It could just as well lead to more
productivity and less bugs, depending on the majority's orientation.

My opinion is that if Freeciv decides to inline, after making a
tradeoff between risk, speed and the fact that oranges taste better,
it will be a sound decision in it's own right. Same goes for the
opposite decision. I agree it's best to do it on open forums.

Of course, I prefere to allow both forms. Total anarchy, wohoo!


Arnstein