This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions

On Oct 20, 2012, at 20:23 , Richard Smith <> wrote:

> On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis
> <> wrote:
>> On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose <> wrote:
>>> While throwing things out there, why not just optionally allow constexpr functions to coexist with non-constexpr functions of the same name, like inline and non-inline?
> I think this is fundamentally the wrong approach. Constexpr functions
> aren't a different kind of function, they're just functions for which
> are sometimes required to be evaluated at translation time. Hence
> overload resolution should not depend on whether a function is
> constexpr. Also, this approach tends to require two definitions of
> constexpr functions even where the definitions are the same (if one
> calls a constexpr overload and the other calls a non-constexpr
> overload). What we want is just a mechanism to make function
> invocation substitution take a different path if it encounters a
> function which it can't process (because the runtime form of that
> function is somehow written in a way that it can't handle).

Just to clarify, I had assumed that if the constexpr function is the only visible declaration, it would be used as the runtime implementation as well, as it currently is in C++11. I guess in C++11 you can forward-declare a constexpr function without making it constexpr, though, so it's not backwards-compatible.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]