Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: inlining functions
Home

[Freeciv-Dev] Re: inlining functions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Kevin Brown <kevin@xxxxxxxxxxxxxx>
Cc: Jason Dorje Short <jshort@xxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: inlining functions
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 20 Aug 2001 08:51:14 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Aug 19, 2001 at 03:43:19PM -0700, Kevin Brown wrote:
> Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, Aug 17, 2001 at 09:41:32PM -0700, Kevin Brown wrote:
> > > Jason Dorje Short <jshort@xxxxxxxxxxxxx> wrote:
> > > > Tony Stuckey points out that "GCC doesn't do cross-procedural
> > > > optimization, nor cross-source-file inlining of small functions", and so
> > > > macros are better [1].  Again, I think this is a compiler issue.
> > > 
> > > Even if this is an issue, cross-source-file inlining is resolved by
> > > doing
> > > 
> > >   static inline type name(args) {
> > >       ...
> > >   }
> > > 
> > > in the header files.
> > 
> > Which in my opinion are ugly.
> 
> More so than putting multiline macros in the very same header files???
> At least the static inline functions won't have continuation marks at
> the end of each line...

My personal top 5 of ugliness:
 5) normal methods
 4) macros which does special magic like the *_iter ones or fc_malloc
 3) macros which have normal method names and also behave like methods
 2) methods in header files
 1) remaining macros

3) and 1) have the big disadvantage to be unprofileable.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Sit, disk, sit. Good boy. Now spin up. Very good. Here's a netscape
  cookie for you. Fetch me some data. Come on, you can do it. No, not that
  data. Bad disk. Bad." 
    -- Calle Dybedahl, alt.sysadmin.recovery


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