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

["rwetmore@xxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>]

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.

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

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

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

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

>       Raimar
>
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
>  Windows: From the people who brought you edlin...

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

>jason

Cheers,
RossW
=====