2013/4/20 Vicente J. Botet Escriba :

Would it be preferable to add BOOST_STATIC_CONSTANT_11 and change every use of BOOST_STATIC_CONSTANT by BOOST_STATIC_CONSTANT_11 and deprecate BOOST_STATIC_CONSTANT?

I would rather change the definitioon of BOOST_STATIC_CONSTANT to # ifdef BOOST_NO_INCLASS_MEMBER_INITIALIZATION # define BOOST_STATIC_CONSTANT(type, assignment) enum { assignment } # else # define BOOST_STATIC_CONSTANT(type, assignment) static *BOOST_CONSTEXPR_OR_CONST* type assignment # endif Code from example: template <typename T> const bool trait::value; newer was correct, because compilers with BOOST_NO_INCLASS_MEMBER_INITIALIZATION define it to enum. So proposed change shall not break correct code. -- Best regards, Antony Polukhin

2013/4/20 Vicente J. Botet Escriba : <...>

#ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION template bool const ice_eq::value; // ********* template bool const ice_ne::value; // ********* #endif

for which I have needed to change const by BOOST_CONSTEXPR_OR_CONST. <...> What am I missing?

Looks like it shall be #ifdef BOOST_NO_INCLASS_MEMBER_INITIALIZATION not #ifndef But how did it work before? Or nobody tested it on ancient compilers? -- Best regards, Antony Polukhin

2013/4/20 John Maddock : <...>

No that's correct as is:

* if BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined, then the constant is really an enum and there should be no out-of-line definitions. * if BOOST_NO_INCLASS_MEMBER_INITIALIZATION is *not* defined, then the constant *should* have the out-of-line definition in case it's address is taken/used.

Oh, now I see, thanks.

As for the original question, this is such a pervasive breaking change, I think a new macro is inevitable I'm afraid :-(

New macro will do exactly what the old macro did, but using C++11 feature. Code in all Boost libraries will be changed to use new macro. So the old macro will be required only for users code that use macro and attempts to take address of constant... To me, it looks less obscuring to have one macro and a note for users to use BOOST_CONSTEXPR_OR_CONST for out-of-line definition; than two macro (which one shall be used by default?) that do the same thing but very slightly differ in details. -- Best regards, Antony Polukhin

Le 21/04/13 13:08, John Maddock a écrit :

...

...

As for the original question, this is such a pervasive breaking change, I think a new macro is inevitable I'm afraid :-(

New macro will do exactly what the old macro did, but using C++11 feature. Code in all Boost libraries will be changed to use new macro. So the old macro will be required only for users code that use macro and attempts to take address of constant...

To me, it looks less obscuring to have one macro and a note for users to use BOOST_CONSTEXPR_OR_CONST for out-of-line definition; than two macro (which one shall be used by default?) that do the same thing but very slightly differ in details.

Here's a radical idea: are there any compilers still around that we care about which require the enum workaround? Certainly not VC6 ;-)

So we could recomend libraries use:

template <class T> struct foo { BOOST_STATIC_CONSTEXPR bool value = some_value; or static BOOST_CONSTEXPR_OR_CONST bool value = some_value;

};

template <class T> BOOST_CONSTEXPR_OR_CONST bool foo<T>::value;

Thoughts?

I'm not against this radical alternative, and I even like it. I don't know which compilers need the enum workaround and if Boost should support them. What I want is just that integral_constant use them so that all the traits in Boost conforms to the C++11 standard. I have applied some changes to [config][mpl][type_traits][integer] and the number of changes to make integral_constant work is not so big. I will comeback later with more information. Best, Vicente

Le 21/04/13 17:45, John Maddock a écrit :

...

I'm not against this radical alternative, and I even like it. I don't know which compilers need the enum workaround and if Boost should support them.

The list seems to be:

VC7 and earlier Vacpp 5.02 and earlier (currently 11.1) Sunpro 5.6 and earlier. MPW all versions?

...

What I want is just that integral_constant use them so that all the traits in Boost conforms to the C++11 standard.

Out of curiosity, can you detect the difference? What can you do with constexpr values that you can't with static const ones?

Even if most of the uses of integral_constant is to use its member ::value integral constant defines also the operator(), so it is a nullary functor. integral_constant a; constexpr int f(); template <int I> void g(); template <typename F> void h(F&& fct) { g(); } h(&f); h(a); The last sentence will not compile if the operator() is not a constexpr and it can not be a constexpr if ::value is not a consexpr, or can it? As you can see the case is not current, but who know what the user want to do with boost::integral_constant. The status quo means that it can not do the same thing that with std::integral_constant. Note that the operator() has just been proposed for C++14, but there is however the conversion operator to the value type. Best, Vicente

Le 22/04/13 16:24, Krzysztof Czainski a écrit :

2013/4/22 Vicente J. Botet Escriba

...

Out of curiosity, can you detect the difference? What can you do with

...

constexpr values that you can't with static const ones?

Even if most of the uses of integral_constant is to use its member ::value integral constant defines also the operator(), so it is a nullary functor.

integral_constant a; constexpr int f();

template <int I> void g();

template <typename F> void h(F&& fct) { g(); } h(&f); h(a);

The last sentence will not compile if the operator() is not a constexpr and it can not be a constexpr if ::value is not a consexpr, or can it?

Really?? I thought a static constant can be used in constexpr functions, just like in C++03 it could be used as a non-type template parameter or static array size. Am I wrong here?

You are right, but I was not using an static constant but a static function. Best, Vicente

2013/4/21 John Maddock :

...

I'm not against this radical alternative, and I even like it. I don't know which compilers need the enum workaround and if Boost should support them.

The list seems to be:

VC7 and earlier Vacpp 5.02 and earlier (currently 11.1) Sunpro 5.6 and earlier. MPW all versions?

Deprecating BOOST_STATIC_CONSTANT macro (and removing it in future releases) will cause a lot of code changes in existing Boosts and users projects. I still think that making BOOST_STATIC_CONSTANT macro to use constexpr by default will cause less troubles and code changes. All libraries will be updated automatically and we'll avoid situation where some libraries use old macro, some use new macro. User won't be confused by 'oh, can I call operator() at compile time for trait X or not?'. Note about that change on the title page and in BOOST_STATIC_CONSTANT docs will help users to adopt changes smooth. -- Best regards, Antony Polukhin

Le 20/04/13 12:12, Antony Polukhin a écrit :

2013/4/20 Vicente J. Botet Escriba : <...>

...

#ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION template bool const ice_eq::value; // ********* template bool const ice_ne::value; // ********* #endif

for which I have needed to change const by BOOST_CONSTEXPR_OR_CONST. <...> What am I missing? Looks like it shall be #ifdef BOOST_NO_INCLASS_MEMBER_INITIALIZATION not #ifndef

But how did it work before? Or nobody tested it on ancient compilers? The documentation says

|BOOST_NO_INCLASS_MEMBER_INITIALIZATION| Compiler Compiler violates std::9.4.2/4. and 9.4.2 Static data members [class.static.data] 2 The declaration of a static data member in its class definition is not a definition and may be of an incomplete type other than cv-qualified void. The definition for a static data member shall appear in a namespace scope enclosing the member's class definition. I think that the definition must be done when |BOOST_NO_INCLASS_MEMBER_INITIALIZATION is not defined, but the initialization could be done on the declaration. Could someone clarify this point? Best, Vicente |