Re: [Boost-bugs] [Boost C++ Libraries] #5735: proto should force functions to be inline

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5735: proto should force functions to be inline
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-07-26 21:24:07

#5735: proto should force functions to be inline
  Reporter: mgaunard | Owner: eric_niebler
      Type: Bugs | Status: closed
 Milestone: To Be Determined | Component: proto
   Version: Boost 1.47.0 | Severity: Problem
Resolution: invalid | Keywords:

Comment (by mgaunard):

 Since Proto is used to build many performance sensitive libraries and
 applications, and there is no downside to implementing this feature, I
 don't understand why you're discarding this request so easily.

 Proto is a library for others to build upon, each having their own uses,
 requirements, compilers and toolchains. No compiler is perfect, and
 inlining is certainly not a perfect feature and is very dependent of the
 flags used -- which themselves may have other negative effects. That means
 that you cannot rely on the compiler to do it reliably, especially when
 large codebases are involved.
 There are always inlining issues, different ones with each version of GCC
 for example, including recent and widely deployed ones.

 Some Proto constructs make no sense to not be inlined, so it seems like a
 good idea to tell the compiler that yes, they should always be inlined,
 and if it cannot for some reason, it should emit an error.
 It is also important in order to get decent performance when running the
 code in debug mode or in modes that are not too aggressive with inlining,
 such as size-optimized builds, popular on embedded systems.

 I believe doing this would only improve the quality of Proto and make
 people more eager to rely on it.

 I think the following paper, in section 9, sums up the importance of
 inlining with expression templates pretty well:

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:07 UTC