[Freeciv-Dev] Re: (PR#2370) Path finding

["Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>]

On Mon, Nov 25, 2002 at 09:23:07PM -0800, rwetmore@xxxxxxxxxxxx via RT wrote:
> At 01:13 AM 02/11/24 -0800, Raimar Falke via RT wrote:
> >
> >On Sat, Nov 23, 2002 at 03:43:45PM -0800, rwetmore@xxxxxxxxxxxx via RT wrote:
> >> At 08:57 AM 02/11/23 -0800, Raimar Falke via RT wrote:
> >> >
> >> >On Sat, Nov 23, 2002 at 07:52:45AM -0800, Per I. Mathisen via RT wrote:
> >> >> 
> >> >> On Sat, 23 Nov 2002, Raimar Falke via RT wrote:
> >> >> > First: inlining. It is critical that this is done. Gregory uses macros
> >> >> ...
> >> >> > while I use the inline keyword. Both can provide the same results.
> >> >> 
> >> >> That Greg's version does not need to open the inline can of worms is a
> >> >> good thing. If we do add inline at a later time, his macros can
> always be
> >> >> turned into functions at that time.
> >> >
> >> >I'm still for inline and I would like to restart the discussion.
> >> 
> >> <Begin discussion>
> >> Inline is very bad. 
> >
> >> It is non-portable.
> >
> >Show me a compiler which doesn't support it. To cope with different
> >syntax we have autoconf (which already has a test for it).
> 
> So you admit, it is non-portable and thus needs to be tested for.

I agree with "needs to be tested for".

> Non-portable is something like being pregnant, you are or aren't.

Nonsense.

> >> It obscures the difference between functions and real inline code
> >> (like macros) because it is advisory and 
> >
> >> not required for the compiler to actually inline.
> >
> >This is correct.
> 
> So it is unpredictably useless, unlike the alternatives.

Yes it may lead to unpredictable performance numbers on uncommon
compilers.

> >> It does not optimize as well so even when inlined, the performance
> >> is not as good as macros.
> >
> >Examples?
> 
> There have been many. Look through the email archives for the examples.

If I have some time I will search.

> In all but the one case Jason found which was somewhat ambiguous as to 
> what was happening, I think you will find inline never quite matched 
> the alternatives.
> 
> >> Big inline functions are an abuse of the technique, when big is big is
> >> also ambiguous with inline in addition to the compiler issues above.
> >
> >Not a real point.
> 
> Actually it is, but I'll accept you can't see why.
> 
> >> There is nothing good to say about inlining.
> >> <End discussion>
> >
> >One valid point raised.
> 
> So you do admit inline has no value - that should be enough :-).

> At 01:27 AM 02/11/24 -0800, Jason Short via RT wrote:
> >
> >Raimar Falke via RT wrote:
> [...]
> >>>Big inline functions are an abuse of the technique, when big is big is
> >>>also ambiguous with inline in addition to the compiler issues above.
> >> 
> >> Not a real point.
> >
> >In fact a negative point :-).  This argument applies much more quickly 
> >to function-style macros.
> 
> Not really, but the fact that it is more obvious to you in the macro
> case I think proves my point. Big macros are also very bad, in case 
> you didn't catch on the first time.
> 
> >- Less obviously, functions give you some abilities macros don't.  The 
> >main thing that comes to mind is the easy ability to return a value in a 
> >more-than-one-line function/macro.
> 
> You can return values from more than one line macros. The limitation is
> what you can put into an expression since all macros that return a value
> must be expressions.
> 
> Void functions of course can be macroized add nauseum. But one should 
> always return a status for any complex operation. If one doesn't then
> the only way to deal with errors is to throw an exception and "C"
> exception handling is rather poor. Thus the problem you outline of
> return values is a severe one. You cannot put loops into an expression
> for instance.
> 
> But then we are back to the earlier point, which gets proven true yet again 
> :-).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "This is Linux Country. On a quiet night, you can hear Windows reboot."