Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2004:
[Freeciv-Dev] Re: (PR#7279) Macro optimizations
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: a-l@xxxxxxx
Cc: mburda@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7279) Macro optimizations
From: "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>
Date: Tue, 3 Feb 2004 09:26:57 -0800
Reply-to: rt@xxxxxxxxxxx

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


(Sigh)  People with attention spans that time out after reading 2 lines
and don't read postings fully do tend to clutter the list with a lot of
repeat noise.

hmap() and now hnat() are macros, but they are coded as pseudo-functions.

If they were functions the code in question would break, as you can have
a function return a value or a reference but not both. Because they are
macros, and the preprocessor generates "C" code, most compilers are smart
enough to remove the braces and compile the code as an l-value when used
to the left of an equals sign.

One should use HNAT() at a minumum to distinguish the lhs/macro form, and
can also give it is own storage to avoid the noise side effect.

It is poor form to use complex expressions as l-values in any event.

Cheers,
RossW
=====

Aside ...

The side effects of this cause the error that threw Jason, since you must
supply two independent storage areas to deal with evaluating lhs and rhs
expressions and returning the values of those expressions since the compiler
can evaluate lhs or rhs in either order. This is what the lintish warning
was all about. The code works, but the compiler does not know that you don't
care about the values in the temporaries and warns you that only one is
going to be returned at end of statement and which it is is indeterminate.

Gregory Berkolaiko wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >
[...]
>>Fact: there is there is a poor coding practice in the hmap() usage that
>>is being hidden again by use of the inline function. There is a new
>>patch that is going to propagate this practice as hnat(). It needs to
>>be fixed properly and documented to prevent this from continuing.
> 
> 
> What is wrong with hmap other than it's a global variable?
> 
> Anyway, I see no problem with propagating this into hnat, since whoever 
> will fix whatever is wrong with hmap can easily extend his fix to hnat.
> 
> G.




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