Daniel Krügler <dsp@bdal.de> writes:
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?
Yes.
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.
You stand corrected. If you don't believe me: use the source, Luke.
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",
I don't know what any of that means, sorry.
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).
It works. Try it or use the source. Cheers, -- Dave Abrahams Boost Consulting www.boost-consulting.com