Re: [boost] [config] consexpr workaround

Subject: Re: [boost] [config] consexpr workaround
From: John Maddock (boost.regex_at_[hidden])
Date: 2013-03-19 05:18:22

>> in order to make easier the introduction of constexpr in a portable way I
>> would like we add a Boost Config workarround. We can define some macros
>> depending on whether BOOST_NO_CONSTEXPR is defined or not.
>>
>> #if defined(BOOST_NO_CONSTEXPR)
>> #define BOOST_CONSTEXPR
>> #define BOOST_CONSTEXPR_OR_CONST const
>> #else
>> #define BOOST_CONSTEXPR constexpr
>> #define BOOST_CONSTEXPR_OR_CONST constexpr
>> #endif
>>
>
> Hi,
>
> Could/should BOOST_CONSTEXPR expand to inline in C++03?
>
> If not, could a macro BOOST_CONSTEXPR_OR_INLINE be added?
>
> For one thing, constexpr functions are usually (but maybe not always?) 
> good
> candidates for inlines. But also please consider the following example.
> Suppose we put the following code in a header file:
>
> struct X { BOOST_CONSTEXPR int fun() const; };
>
> BOOST_CONSTEXPR int X::fun() const { return 0; }
>
> Now if this file is included in multiple .cpp files, this will fail at 
> link
> time in C++03 with message "multiple definition of `X::fun()", and it will
> link fine in C++11. But when BOOST_CONSTEXPR is inline in C++03, the above
> works.
>
> Would making BOOST_CONSTEXPR expand to inline in C++03 do any harm?

Yes, it would break lots of Boost.Multiprecision code that's declared [1]:

inline BOOST_CONSTEXPR T foo();

which begs the question why can't you do the same?

Particularly for templates where the constexpr-ness depends on the template 
argument, this is exactly what you want anyway.

John.

Note 1: Actually it's a __forceinline not inline.