Re: [boost] Re: class static constants, mpl, and linker problems

From: Matthias Troyer (troyer_at_[hidden])
Date: 2004-01-27 12:24:07

On Tuesday, January 27, 2004, at 01:45 PM, Daniel Krügler wrote:

> Hello Matthias,
>
> Matthias Troyer schrieb:
>> Dear Daniel,
>> If you use BOOST_STATIC_CONSTANT you need to additionally provide a 
>> definition on conforming compilers. The correct usage is like in:
>> // declaration
>> class A {
>>   BOOST_STATIC_CONSTANT(int , x=1);
>> };
>> ....
>> //definition
>> #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION
>> int A::x;
>> #endif
>> I hope that clarifies this issue,
>
> No, it doesn't, please read the original thread carefully. I am aware 
> of the fact, that an integral or enumeration type static member needs 
> a corresponding definition and I hope my contribution has made that 
> clear to everyone.
> Your answer implies, that users of the boost library are responsible 
> for providing these definitions for boost constants. If so, I think 
> that would be bad news. Consider those many hidden constants in 
> whatever boost::details namespace or other implementation-dependent 
> data items. How should the boost user correctly provide the necessary 
> definitions?
> To my opinion boost should at least provide in the libs section source
> files with possibly necessary definitions of all externally accessible
> constants, which the user can translate if necessary.
> I also want to add, that although my example seems artifical, it should
> show a basic problem. Consider a simple "algorithm" like std::max which
> takes constant references as arguments. You cannot demand, that boost
> users must watch out for those or similar expressions in their code and
> take proper resolutions by hand??

As far as I know, Boost currently provides these definitions for all 
static member constants that you ask for. If you find one that is 
missing it should be reported to the author as a bug. If, on the other 
hand, you use the BOOST_STATIC_CONSTANT macro in your own classes you 
are of course required to add the definition yourself.

> Second, your response did not take into account the problems with the
> effects of the /Ze and /Za flags of the current VC7.1 compiler which I 
> also think is a very important issue.

For that you'll have to ask people who know more about Windows 
compilers. Since I do not use Windows but just MacOS, Unix and Linux I 
cannot help with bugs or compiler options of that compiler.

Matthias