Boost logo

Boost :

Subject: Re: [boost] BOOST_FORCE_INLINE
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-10-09 20:51:58

On 10/10/2011 02:02 AM, Olaf van der Spek wrote:
> On Mon, Oct 10, 2011 at 1:50 AM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]> wrote:
>> They're slightly different: __forceinline works just like the normal inline
>> specifier, while __attribute__((always_inline)) can be placed in various
>> places like other GCC attributes, but only has an effect if the function is
>> also inline.
> Shouldn't the decision to inline be left to the compiler?

The point of that macro is to override the compiler analysis.

Compilers are not perfect, so it is beneficial to mark to functions
inline manually for a variety of reasons:

  - you'll get an error or warning if the compiler cannot inline it
  - you can still get the inlining in debug mode, which can be necessary
to make applications that depend a lot on meta-programming to run at
acceptable performance
  - compiling for size is not always very aggressive with inlining, but
a lot of meta-programming things rely a lot on aggressive inlining to happen
  - for codebases with a lot of forwarding the compiler can easily get
  - inlining doesn't seem to take into account the costs of register
spilling required by a function call, which is important to avoid in
low-level code.

Do people generally agree it is ok to add this in Boost.Config, and
maybe make some key libraries use it?

Boost list run by bdawes at, gregod at, cpdaniel at, john at