Re: class static constants, mpl, and linker problems
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. -- Dave Abrahams Boost Consulting www.boost-consulting.com
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
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
David Abrahams schrieb:
Daniel Krügler <dsp@bdal.de> writes:
So you mean, if I use integral_c<T,n>::value, the definition of value is provided by boost?
Yes.
That is really nice and as I said in my first posting, you can blame me now for incomplete testing. It seems to me, that VC7.1 is an open question, but that is part of the other posting of you.
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.
Thanks for the correction.
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.
All initial answers implied to me, that the corresponding definitions where not provided by boost, so I just was fighting for them ;-) Just forget that b..dozer.
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.
I will do that, thanks Dave. Greetings, Daniel
participants (6)
-
Daniel Krügler -
David Abrahams