[config] consexpr workaround
Hi, 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 For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
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 OK
We could also add a STATIC_CONSTEXPR macro
#define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST
For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used.
I don't see how that can work: * If the type being initialized is known to be an integer type then we can use BOOST_STATIC_CONSTANT and we wouldn't gain anything from using constexp? * If the type being initialized might not be an integer type, then we can use constexp or a static const declaration, but we can't use BOOST_STATIC_CONSTANT (because it may be implemented in terms of an enum). Other than that, care to provide a patch? Cheers, John.
On 13/11/10 09:40, John Maddock wrote:
For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used.
I don't see how that can work:
* If the type being initialized is known to be an integer type then we can use BOOST_STATIC_CONSTANT and we wouldn't gain anything from using constexp?
One small thing you gain is that there will be an error if someone misuses BOOST_STATIC_CONSTANT thus (outside a class body): int f() { return 0; } BOOST_STATIC_CONSTANT(int, b = f()); whereas at present there is no such error for the 'static const' implementation, only the 'enum' implementation.
* If the type being initialized might not be an integer type, then we can use constexp or a static const declaration, but we can't use BOOST_STATIC_CONSTANT (because it may be implemented in terms of an enum).
If you only intend to support compilers on which it is not implemented as an enum, it might be reasonable to use it for non-integer types (though one would have to take care of static initialization order...). John Bytheway
* If the type being initialized might not be an integer type, then we can use constexp or a static const declaration, but we can't use BOOST_STATIC_CONSTANT (because it may be implemented in terms of an enum).
If you only intend to support compilers on which it is not implemented as an enum, it might be reasonable to use it for non-integer types (though one would have to take care of static initialization order...).
The point is, the only reason for BOOST_STATIC_CONSTANT existing is as a workaround for broken compilers that require the enum workaround, so if we're excluding those, there's nothing really left ;-) John.
----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Saturday, November 13, 2010 10:40 AM Subject: Re: [boost] [config] consexpr workaround
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
OK
I will provide a patch with doc and tests.
We could also add a STATIC_CONSTEXPR macro
#define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST
For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used.
I don't see how that can work:
* If the type being initialized is known to be an integer type then we can use BOOST_STATIC_CONSTANT and we wouldn't gain anything from using constexp?
I think I'm missing something. Do you mean that we don't need to use constexpr for the variable value? template<typename _Tp, _Tp __v> struct integral_constant { static constexpr _Tp value = __v; typedef _Tp value_type; typedef integral_constant<_Tp, __v> type; constexpr operator value_type() { return value; } }; Why then the C++0x proposal includes it?
* If the type being initialized might not be an integer type, then we can use constexp or a static const declaration, but we can't use BOOST_STATIC_CONSTANT (because it may be implemented in terms of an enum).
Right, in this case nothing can be done . Best, Vicente
vicente.botet wrote:
"John Maddock" <boost.regex@virgin.net> wrote:
For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used.
I don't see how that can work:
* If the type being initialized is known to be an integer type then we can use BOOST_STATIC_CONSTANT and we wouldn't gain anything from using constexp?
I think I'm missing something. Do you mean that we don't need to use constexpr for the variable value?
The purpose of constexpr is to mark something as a compile time constant such that it can be used in other compile time expressions, including types that weren't allowed as compile time constants before. It allows for constant-expression functions, data, and even constructors. Constant-expression data disallows dynamic initialization which const objects can undergo. Without constexpr support, neither constant-expression functions nor constructors are supported, nor is floating point constant-expression data. Thus, const is inappropriate in those cases, so BOOST_CONSTEXPR_OR_CONST cannot be used. For non-floating point constant-expression data, const could work fairly well, but it permits dynamic initialization, so for platforms supporting constexpr, code would fail to compile that mistakenly compiled on platforms without constexpr support. Thus, BOOST_CONSTEXPR_OR_CONST would lead to maintenance issues. That means library code using BOOST_CONSTEXPR_OR_CONST and client code using that library code must either assume that BOOST_CONSTEXPR_OR_CONST merely means "const" or it must be conditionally compiled to account for either "const" or "constexpr." In that case, BOOST_CONSTEXPR_OR_CONST does nothing to help. I don't think BOOST_CONSTEXPR_OR_CONST is helpful. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Monday, November 15, 2010 1:29 PM Subject: Re: [boost] [config] consexpr workaround
vicente.botet wrote:
"John Maddock" <boost.regex@virgin.net> wrote:
For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used.
I don't see how that can work:
* If the type being initialized is known to be an integer type then we can use BOOST_STATIC_CONSTANT and we wouldn't gain anything from using constexp?
I think I'm missing something. Do you mean that we don't need to use constexpr for the variable value?
The purpose of constexpr is to mark something as a compile time constant such that it can be used in other compile time expressions, including types that weren't allowed as compile time constants before. It allows for constant-expression functions, data, and even constructors. Constant-expression data disallows dynamic initialization which const objects can undergo. Without constexpr support, neither constant-expression functions nor constructors are supported, nor is floating point constant-expression data. Thus, const is inappropriate in those cases, so BOOST_CONSTEXPR_OR_CONST cannot be used.
I think that we need to declare a constant variable as constexpr if we want it to be part of other constexpr. Am I wrong?
For non-floating point constant-expression data, const could work fairly well, but it permits dynamic initialization, so for platforms supporting constexpr, code would fail to compile that mistakenly compiled on platforms without constexpr support.
You are right. But it works well when the the data is staticaly initialized, which is the case for most of the constants.
Thus, BOOST_CONSTEXPR_OR_CONST would lead to maintenance issues. That means library code using BOOST_CONSTEXPR_OR_CONST and client code using that library code must either assume that BOOST_CONSTEXPR_OR_CONST merely means "const" or it must be conditionally compiled to account for either "const" or "constexpr." In that case, BOOST_CONSTEXPR_OR_CONST does nothing to help.
If the client code must be portable also, it can assume only that the constant is "const". But for clients that use only c++, the constant must be declared constexpr, or not?
I don't think BOOST_CONSTEXPR_OR_CONST is helpful.
Do you mean that a library that must provide a C++03 interface can not use constexpr on C++0x compilers as the meaning can change? In Boost.Ratio "num" and "den" are defined as const for C++03 compilers, and need to be constexpr for C++0x compilers. How do you write such a code in a "portable" way? ??? boost::intmax_t num = SIGN * ABS_N / GCD; ??? boost::intmax_t den = ABS_D / GCD; For the moment I write it like that BOOST_RATIO_STATIC_CONSTEXPR boost::intmax_t num = SIGN * ABS_N / GCD; BOOST_RATIO_STATIC_CONSTEXPR boost::intmax_t den = ABS_D / GCD; But maybe you prefer the following? #ifdef BOOST_NO_CONSTEXPR const boost::intmax_t num = SIGN * ABS_N / GCD; const boost::intmax_t den = ABS_D / GCD; #else constexpr boost::intmax_t num = SIGN * ABS_N / GCD; constexpr boost::intmax_t den = ABS_D / GCD; #endif Best, Vicente
vicente.botet wrote:
From: "Stewart, Robert" <Robert.Stewart@sig.com>
The purpose of constexpr is to mark something as a compile time constant such that it can be used in other compile time expressions, including types that weren't allowed as compile time constants before. It allows for constant-expression functions, data, and even constructors. Constant-expression data disallows dynamic initialization which const objects can undergo. Without constexpr support, neither constant-expression functions nor constructors are supported, nor is floating point constant-expression data. Thus, const is inappropriate in those cases, so BOOST_CONSTEXPR_OR_CONST cannot be used.
I think that we need to declare a constant variable as constexpr if we want it to be part of other constexpr. Am I wrong?
You're partly right. Compile time constant integral values can be expressed several ways and all can be used in a constexpr. If you need a constexpr for another purpose, then the other approaches don't apply. However, in that case, BOOST_CONSTEXPR_OR_CONST doesn't apply. If that macro does apply, then you don't need constexpr.
For non-floating point constant-expression data, const could work fairly well, but it permits dynamic initialization, so for platforms supporting constexpr, code would fail to compile that mistakenly compiled on platforms without constexpr support.
You are right. But it works well when the the data is staticaly initialized, which is the case for most of the constants.
Sure, but you don't need constexpr in that case, so you don't need BOOST_CONSTEXPR_OR_CONST.
I don't think BOOST_CONSTEXPR_OR_CONST is helpful.
Do you mean that a library that must provide a C++03 interface can not use constexpr on C++0x compilers as the meaning can change? In Boost.Ratio "num" and "den" are defined as const for C++03 compilers, and need to be constexpr for C++0x compilers. How do you write such a code in a "portable" way?
They don't need to be constexpr. The C++03 code will work. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2010/11/13 vicente.botet <vicente.botet@wanadoo.fr>
Hi,
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? Cheers, Kris
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.
2013/3/19 John Maddock <boost.regex@virgin.net>
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
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?
If you mean: BOOST_FORCEINLINE BOOST_CONSTEXPR T foo(); Then yes, that's what Multiprecision does for performance critical functions. John.
Le 19/03/13 17:00, Krzysztof Czainski a écrit :
2013/3/19 John Maddock <boost.regex@virgin.net>
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
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
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.
Le 19/03/13 22:25, Krzysztof Czainski a écrit :
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
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
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
Le 19/03/13 22:25, Krzysztof Czainski a écrit :
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
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
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. Ticket #8318 created with a patch. Cheers, Kris
Le 20/03/13 18:57, Krzysztof Czainski a écrit :
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
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 <vicente.botet@wanadoo.fr> 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
2013/3/20 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
Le 20/03/13 18:57, Krzysztof Czainski a écrit :
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
Le 19/03/13 22:25, Krzysztof Czainski a écrit :
2013/3/19 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
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)?
They already are inline, and I had missed that, sorry for the noise ;-)
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
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 .
This problematic TI compiler doesn't inline any constructors, unless marked BOOST_FORCEINLINE. I haven't identified any other conditions requiring BOOST_FORCEINLINE yet ;-)
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?
FWIU so far, no. Only constructors need BOOST_FORCEINLINE.
Ticket #8318 created with a patch.
I will apply the patch soon.
Thanks, Kris
participants (6)
-
John Bytheway -
John Maddock -
Krzysztof Czainski -
Stewart, Robert -
Vicente J. Botet Escriba -
vicente.botet