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

From: Daniel Krügler (dsp_at_[hidden])
Date: 2004-01-28 02:23:45

David Abrahams schrieb:
> Daniel Krügler <dsp_at_[hidden]> writes:
> 
> 
>>A contrived example for the first issue was given in my original
>>posting. I repeat it here again:
>>---------------------------------------------------------------
>>#include <boost/mpl/vector.hpp>
>>#include <boost/mpl/size.hpp>
>>
>>void foo(const long&)
>>{
>>}
>>
>>int main()
>>{
>>   typedef boost::mpl::vector<char, double> MyTypeContainer;
>>   typedef boost::mpl::size<MyTypeContainer> MPSizeType;
>>
>>   foo(MPSizeType::value);
>>}
>>---------------------------------------------------------------
>>
>>Switch to /Za, if you use the VC7.1, the mentioned mingw compiler will
>>choke anyway.
> 
> 
> I don't understand the assertion.  What does mingw have to do with vc7.1

Nothing. I just wanted to provide another strongly conforming compiler,
which shows the predicted linker errors.

>>The second problem would result **iff** boost provides the missing
>>definitions of boost::mpl::size<>::value and similar. In this case
>>the VC7.1 compiler would choke similarily (but fortuneatly not the
>>mingw compiler any longer), if instead of the /Za flag the
>>complimentary /Ze flag is set :-((
> 
> 
> Hmm.  I'm very surprised.  It appears that when /Za is supplied,
> *nothing* you can do will cause an integral static const member to be
> instantiated, and when /Za is not supplied, an out-of-line definition
> makes no difference because it's not needed.  Furthermore, according
> to the MS docs, the compiler supplies no preprocessor symbol we could
> use to detect /Za and switch to using enums.  I'm not sure there's a
> workaround for this one.

I am quite sure, that your interpretation of the meaning of /Za and /Ze
is not sufficient.

/Za disables language extensions and makes the linker choking on missing 
definitions of in-class static constant members, which were initialized 
in the class-definition, but nowhere defined, and were used in 
expressions where their addresses are necessary. That behaviour is what 
we both understand as C++ compliant behaviour.

/Ze enables language extensions and does not make the corresponding 
definition necessary (that is fine for me and I understand that as an 
extension), **but** it chokes on duplicate definitions, if the 
conforming definition is provided (that is not fine for me).

According to Eric, we seem to have chance by taking advantage of the
_MSC_EXTENSIONS flag - these are good news!

Thank you for your thorough answers and your patience concerning my 
rashly conclusions,

Daniel