Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Trent Piepho <xyzzy@xxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: Gaute B Strokkenes <gs234@xxxxxxxxx>
Date: Sat, 18 Aug 2001 05:05:08 +0200

On Thu, 16 Aug 2001, xyzzy@xxxxxxxxxxxxx wrote:
> On Thu, 16 Aug 2001, Gaute B Strokkenes wrote:
>> 
>> If we ever have to change this back (which I don't think we have
>> to, until and unless we implement `isometric view' shapes), it's
>> only going to take two minutes to change it back, anyway.
> 
> Why change it in the first place?

Why not?

As far as I can see, the function fulfils the usual criterion for
inlining/macroising functions:  it is small and simple enough not to
invoke any of the situations that sometimes make macros a problem.  It
is also sufficiently small to be both smaller and faster when inlined
than as a normal function call, and is present (or at least ought to
be present) in several critical loops.

>> > Also, most of the places these functions are used is inside
>> > debugging assert calls.  There is no point in making those faster
>> > since they are just for debugging.  So there is no good reason to
>> > make it a macro in the first place.
>> 
>> That's not true.  Compiling with assertions disabled is the
>> exception rather than the norm, so most people would benefit from a
>> speedup.
> 
> That's just stupid reasoning.  Stick macros in the debugging checks
> so they go faster.  It would mess up profiling.

You can't have everything.  But hey, didn't you just say that
debugging code doesn't matter anyway, so why would you want to profile
it?

> It bloats the compiled code because the macro is larger than just a
> function call.

If you had bothered to check the generated assembly--I did--before
making this statement, you would have known that it is wrong.

> You shouldn't use a macro unless there is a good reason not to use a
> function.

I think that macros are as good a way as any to abstract certain
tasks.  Macros have inherent limits that crop up most frequently when
trying to abstract something that is too large or complex.  However,
when the task in question does not push these boundaries they are not
an issue.

Incidentally, I have noticed that you approve of Jason's use of macros
in directions' patch.  So do I.  It would be interesting to know why
you think macros are appropriate in the case of directions, but not in
this case.

> There is no good reason to use a macro here.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
Am I SHOPLIFTING?


[Prev in Thread] Current Thread [Next in Thread]