Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: (PR#2370) Path finding
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#2370) Path finding
From: "Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>
Date: Sun, 24 Nov 2002 02:27:54 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sun, Nov 24, 2002 at 01:27:38AM -0800, Jason Short via RT wrote:
> 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. 
> 
> I much prefer inline to macros.
> 
> >>It does not optimize as well so even when inlined, the performance
> >>is not as good as macros.
> > 
> > 
> > Examples?
> 
> A while ago, Gaute did some tests with normalize_map_pos inlined versus 
> macro'd.  The results were faster when inlined.  The difference was small.
> 
> This was with an old version of gcc.  I would like to see new numbers 
> with gcc 3.  But either way, I do think it is _harder_ for the compiler 
> to optimize inline functions.
> 
> >>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.
> 
> >>There is nothing good to say about inlining.
> >><End discussion>
> > 
> > 
> > One valid point raised.
> 
> There are a couple of others:
> 
> - Macros give you some abilities functions don't, obviously.  Take the 
> ***_iterate macros.  But when this comes to function-style macros, it 
> usually just means you have the ability to give weird side effects if 
> you want to.

I don't propose the change the iterate macros. These are very useful.

> - 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 declare local variables.

You can profile inline functions by disabling the inline.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  A supercomputer is a computer running an endless loop in just a second



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