David Abrahams schrieb:
Daniel Krügler <dsp@bdal.de> 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