Hello David, David Abrahams schrieb:
Matthias Troyer <troyer@itp.phys.ethz.ch> writes:
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,
Another approach is to use mpl::int_<n> or integral_c<T,n> which supply the definitions themselves.
So you mean, if I use integral_c<T,n>::value, the definition of value is provided by boost? According to my assumptions (which might be wrong, as I said) here applies the same problem, because integral_c<T,n> also contains a BOOST_STATIC_CONSTANT and thus a possibly addressable object, but I am willing to be corrected, of course. To make my request more clear: I am **not** speaking of a programming style which **should** take advantage of using integral_c<T,n> instead of an addressable (constant) object, I am speaking of daily programming practice. Since e.g. integral_c<T,n>::value is not a boost-internal "you-should-not-use-or-you-are-fired", it seems legal code to write something like const long myvalue = foo(); // run-time determined value const long max_value = std::max(myvalue, boost::mpl::integral_c<long,15>::value); // Combine compile-time and // run-time information here without knowing too much about the internals of boost::mpl (besides the fact, that it might be necessary to additionally add some further mpl source files into my project). Greetings, Daniel