Dear boost users,
I have a question regarding mpl.
Consider the following piece of code:
typedef boost::mpl::vector
Karl Meerbergen
Dear boost users,
I have a question regarding mpl.
Consider the following piece of code:
typedef boost::mpl::vector
v_i_d_t ; typedef boost::mpl::pop_front ::type v_d_t ; Is v_d_t equal to boost::mpl::vector<double> ? I do not have the impression.
boost::mpl::equal
Hi Dave, The documentation at http://www.boost.org/libs/mpl/doc/refmanual/vector.html says for pop_front<v>::type: A new vector of following elements: [next< begin<v>::type>::type,end<v>::type) It suggests (in my opinion) that the result_type of pop_front is a vector. Should the documentation be clearer about this? Thanks, Karl On Thursday 22 September 2005 19:31, David Abrahams wrote:
Karl Meerbergen
writes: Dear boost users,
I have a question regarding mpl.
Consider the following piece of code:
typedef boost::mpl::vector
v_i_d_t ; typedef boost::mpl::pop_front ::type v_d_t ; Is v_d_t equal to boost::mpl::vector<double> ? I do not have the impression.
boost::mpl::equal
::value is true but boost::is_same ::value may be false. HTH,
Karl Meerbergen wrote:
Hi Dave,
The documentation at http://www.boost.org/libs/mpl/doc/refmanual/vector.html says for pop_front<v>::type: A new vector of following elements: [next< begin<v>::type>::type,end<v>::type)
It suggests (in my opinion) that the result_type of pop_front is a vector. Should the documentation be clearer about this?
Does look that way...
Thanks,
Karl
Karl Meerbergen
Hi Dave,
The documentation at http://www.boost.org/libs/mpl/doc/refmanual/vector.html says for pop_front<v>::type: A new vector of following elements: [next< begin<v>::type>::type,end<v>::type)
It suggests (in my opinion) that the result_type of pop_front is a vector.
It is a vector. A vector does not necessarily have to be a specialization of mpl::vector. Hmm, I think in this case "vector" should not be set in code font, though. Aleksey?
Should the documentation be clearer about this?
That's what the use of "concept-identical" in the reference manual is intended to convey. http://www.boost.org/libs/mpl/doc/refmanual/extensible-sequence.html Do you have a specific suggestion that should be used to clarify the docs? BTW, this point is also very clearly explained in "C++ Template Metaprogramming," in case you haven't read it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Friday 23 September 2005 15:35, David Abrahams wrote:
Karl Meerbergen
writes: Hi Dave,
The documentation at http://www.boost.org/libs/mpl/doc/refmanual/vector.html says for pop_front<v>::type: A new vector of following elements: [next< begin<v>::type>::type,end<v>::type)
It suggests (in my opinion) that the result_type of pop_front is a vector.
It is a vector. A vector does not necessarily have to be a specialization of mpl::vector.
Hmm, I think in this case "vector" should not be set in code font, though. Aleksey?
Should the documentation be clearer about this?
That's what the use of "concept-identical" in the reference manual is intended to convey. http://www.boost.org/libs/mpl/doc/refmanual/extensible-sequence.html
Do you have a specific suggestion that should be used to clarify the docs?
Perhaps it could be mentioned that pop_front, pop_back, insert etc return a VariadicSequence, (which it is I suppose?). For me it would be clear it is not an mpl::vector type. I am not enough familiar with the mpl concepts to be sure that my suggestion is correct.
BTW, this point is also very clearly explained in "C++ Template Metaprogramming," in case you haven't read it.
I have read part of it. I agree that after a closer look, it is clearly explained. Karl
Karl Meerbergen
Perhaps it could be mentioned that pop_front, pop_back, insert etc return a VariadicSequence, (which it is I suppose?). For me it would be clear it is not an mpl::vector type.
Well, it is concept-identical to a vector, so that doesn't add any new information.
I am not enough familiar with the mpl concepts to be sure that my suggestion is correct.
It's technically correct, but I don't think it would help anyone else. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams
-
Karl Meerbergen
-
Simon Buchan