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