2013/3/19 John Maddock

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();

Oh yeah, I didn't think about code, that already uses both BOOST_CONSTEXPR together with inline ;-) 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.

Right. So you pretty much answered my initial question, John ;-) Thanks. My initial reasoning was based on this: I analysed performance of some C++03 code, that uses Boost.Chrono. And I discovered, that a lot of trivial functions didn't get inlined. So now, narrowing the question to use of BOOST_CONSTEXPR in Boost.Chrono: 1. Could the functions marked BOOST_CONSTEXPR be also marked inline (and this question probably applies to other Boost libraries)? 2. This is probably related only to the TI compiler I use: marking constructors inline doesn't work for me, they need to be marked BOOST_FORCEINLINE (I've configured it), so could the constexpr constructors in Boost.Chrono be marked with BOOST_FORCEINLINE as well? Cheers, Kris

Le 19/03/13 17:00, Krzysztof Czainski a écrit :

2013/3/19 John Maddock

...

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();

Oh yeah, I didn't think about code, that already uses both BOOST_CONSTEXPR together with inline ;-)

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.

Right. So you pretty much answered my initial question, John ;-) Thanks.

My initial reasoning was based on this: I analysed performance of some C++03 code, that uses Boost.Chrono. And I discovered, that a lot of trivial functions didn't get inlined. So now, narrowing the question to use of BOOST_CONSTEXPR in Boost.Chrono: 1. Could the functions marked BOOST_CONSTEXPR be also marked inline (and this question probably applies to other Boost libraries)? 2. This is probably related only to the TI compiler I use: marking constructors inline doesn't work for me, they need to be marked BOOST_FORCEINLINE (I've configured it), so could the constexpr constructors in Boost.Chrono be marked with BOOST_FORCEINLINE as well?

Hi, could you point me to the cases that need to be inlined that the compiler doesn't inline by itself? Please create a ticket so that I don't forget it. Best, Vicente

Le 19/03/13 22:25, Krzysztof Czainski a écrit :

2013/3/19 Vicente J. Botet Escriba

...

Le 19/03/13 17:00, Krzysztof Czainski a écrit : So now, narrowing the question to use of

...

BOOST_CONSTEXPR in Boost.Chrono: 1. Could the functions marked BOOST_CONSTEXPR be also marked inline (and this question probably applies to other Boost libraries)? 2. This is probably related only to the TI compiler I use: marking constructors inline doesn't work for me, they need to be marked BOOST_FORCEINLINE (I've configured it), so could the constexpr constructors in Boost.Chrono be marked with BOOST_FORCEINLINE as well?

Hi, could you point me to the cases that need to be inlined that the compiler doesn't inline by itself?

Please create a ticket so that I don't forget it.

Best, Vicente

Hi Vincente,

Thanks for looking at this.

I think this TI compiler doesn't inline anything not marked inline. Additionally it doesn't seem to inline constructors, unless marked BOOST_FORCEINLINE [1].

So if there aren't any thoughts against this, I suggest all constexpr functions in duration and time_point to be marked inline, and constexpr constructors to be marked forceinline. Or should I just touch the cases, that need to be inline in my example situation? I'd prefer the former ;-)

I'll create a ticket and supply a patch shortly.

Cheers, Kris

[1] The TI compiler supports the GCC extension attribute forceinline.

What makes the consexpr functions different from the other functions that the compiler could inline and it doesn't? Are you proposing that all the boost libraries uses BOOST_FORCEINLINE on all the functions defined in the declaration? Vicente

Le 20/03/13 18:57, Krzysztof Czainski a écrit :

2013/3/19 Vicente J. Botet Escriba

...

Le 19/03/13 22:25, Krzysztof Czainski a écrit :

...

Le 19/03/13 17:00, Krzysztof Czainski a écrit :

...

So now, narrowing the question to use of

BOOST_CONSTEXPR in Boost.Chrono:

...

1. Could the functions marked BOOST_CONSTEXPR be also marked inline (and this question probably applies to other Boost libraries)? 2. This is probably related only to the TI compiler I use: marking constructors inline doesn't work for me, they need to be marked BOOST_FORCEINLINE (I've configured it), so could the constexpr constructors in Boost.Chrono be marked with BOOST_FORCEINLINE as well?

Hi,

could you point me to the cases that need to be inlined that the compiler doesn't inline by itself?

Please create a ticket so that I don't forget it.

Best, Vicente

Hi Vincente,

Thanks for looking at this.

I think this TI compiler doesn't inline anything not marked inline. Additionally it doesn't seem to inline constructors, unless marked BOOST_FORCEINLINE [1].

So if there aren't any thoughts against this, I suggest all constexpr functions in duration and time_point to be marked inline, and constexpr constructors to be marked forceinline. Or should I just touch the cases, that need to be inline in my example situation? I'd prefer the former ;-)

I'll create a ticket and supply a patch shortly.

Cheers, Kris

[1] The TI compiler supports the GCC extension attribute forceinline.

What makes the consexpr functions different from the other functions

2013/3/19 Vicente J. Botet Escriba that the compiler could inline and it doesn't? Are you proposing that all the boost libraries uses BOOST_FORCEINLINE on all the functions defined in the declaration?

Vicente

I misread those files, all constexpr function are already inline ;-)

So I'm only talking about constructors (3 constructors of class duration, and 3 constructors of class time_point), and constexpr doesn't have much to do with this, sorry for the noise.

I don't understand the conditions that need to use BOOST_FORCEINLINE . There are a lot of functions that are not marked inline and I expect the compiler to inline as e.g. BOOST_CONSTEXPR duration time_since_epoch() const { return d_; } Should I add BOOST_FORCEINLINE to this kind of code also?

Ticket #8318 created with a patch.

I will apply the patch soon. Best, Vicente