mpl documentation question
Documentation for mpl::less<T> has the following section:
Expression semantics
For any Integral Constants c1 and c2:
typedef less
Le 07/04/12 09:13, Robert Ramey a écrit :
Documentation for mpl::less<T> has the following section:
Expression semantics For any Integral Constants c1 and c2: typedef less
::type r; Return type:Integral Constant. Semantics:Equivalent to typedef bool_< (c1::value< c2::value)> r;
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b if //a is used then the following yields bool_<true>
is_same< less
, r> if // b is used then the following yields bool_<false>
is_same< less
, r> So in what sense are //a and // b equivalent?
Hi,
they are not equivalents. The equivalence relation appears via the
::type access.
is_same< less
Vicente J. Botet Escriba wrote:
Le 07/04/12 09:13, Robert Ramey a écrit :
Documentation for mpl::less<T> has the following section:
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b if //a is used then the following yields bool_<true>
is_same< less
, r> if // b is used then the following yields bool_<false>
is_same< less
, r> So in what sense are //a and // b equivalent?
Hi, they are not equivalents. The equivalence relation appears via the
type access.
is_same< less
::type, r::type> should be true_type in both cases.
This is because integral_constant
defines a nested typedef 'type' as itself.
Hmmm - this helps understand why I've always been confused about
when to use "less
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b
is incorrect and misleading?
I'm thinking that it shouldn't even be in the documentation as written.
This raises the question as to what the documentation should say
about the type "less
HTH, Vicente
AMDG On 04/07/2012 10:47 AM, Robert Ramey wrote:
Vicente J. Botet Escriba wrote:
Le 07/04/12 09:13, Robert Ramey a écrit :
Documentation for mpl::less<T> has the following section:
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b if //a is used then the following yields bool_<true>
is_same< less
, r> if // b is used then the following yields bool_<false>
is_same< less
, r> So in what sense are //a and // b equivalent?
<snip> So you agree that the statement above (which appears in the documentation)
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b is incorrect and misleading?
I'm thinking that it shouldn't even be in the documentation as written. This raises the question as to what the documentation should say about the type "less
" ?
is_same doesn't work, but what you can
use is mpl::equal_to. mpl::equal_to
compares integral constants for equality
without requiring the types to match
exactly:
equal_to
Steven Watanabe wrote:
AMDG
On 04/07/2012 10:47 AM, Robert Ramey wrote:
Vicente J. Botet Escriba wrote:
Le 07/04/12 09:13, Robert Ramey a écrit :
Documentation for mpl::less<T> has the following section:
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b if //a is used then the following yields bool_<true>
is_same< less
, r> if // b is used then the following yields bool_<false>
is_same< less
, r> So in what sense are //a and // b equivalent?
<snip> So you agree that the statement above (which appears in the documentation)
typedef less
r; // a Return type:Integral Constant. Semantics:Equivalent to struct r : less
::type {}; //b is incorrect and misleading?
I'm thinking that it shouldn't even be in the documentation as written. This raises the question as to what the documentation should say about the type "less
" ? is_same doesn't work, but what you can use is mpl::equal_to. mpl::equal_to compares integral constants for equality without requiring the types to match exactly:
equal_to
, r> -> mpl::true_
That's interesting and useful. So I guess my problem is with the usage
of the term "equivalent". I had interpreted this as "can be substituted
for".
So I'm now thinking that my original concern is justified - that the
document
doesn't accurately convey what "less
In Christ, Steven Watanabe
AMDG On 04/07/2012 12:05 PM, Robert Ramey wrote:
That's interesting and useful. So I guess my problem is with the usage of the term "equivalent". I had interpreted this as "can be substituted for".
So I'm now thinking that my original concern is justified - that the document doesn't accurately convey what "less
" really is.
Yes. I agree that the documentation needs some work here.
This has always been confusing to me - and still is. I totally get what "less
::type" is supposed to mean but the meaning and intended usage of "less " is still lost on me.
Okay, I'll try to explain more clearly.
mpl::less
Steven Watanabe wrote:
AMDG
On 04/07/2012 12:05 PM, Robert Ramey wrote:
That's interesting and useful. So I guess my problem is with the usage of the term "equivalent". I had interpreted this as "can be substituted for".
So I'm now thinking that my original concern is justified - that the document doesn't accurately convey what "less
" really is. Yes. I agree that the documentation needs some work here.
This has always been confusing to me - and still is. I totally get what "less
::type" is supposed to mean but the meaning and intended usage of "less " is still lost on me. Okay, I'll try to explain more clearly. mpl::less
::type is the result of invoking the metafunction. This is the way all metafunctions work in MPL so no surprises here. Now, mpl::less
is itself an MPL Integral Constant. This works because MPL Integral Constant is a Concept rather than a specific template. In other words, if you only care about the *value* of the result, and not the *exact type*, then you can use mpl::less instead of typename mpl::less ::type. Just think of this as a convenient short-cut for arithmetic metafunctions. In Christ, Steven Watanabe
great answer - next time you come up to Santa Barbara, give me a call, I'll buy you lunch. Robert Ramey
participants (3)
-
Robert Ramey
-
Steven Watanabe
-
Vicente J. Botet Escriba