From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-01-16 17:11:55
On 01/15/2005 05:26 PM, David Abrahams wrote:
> Larry Evans wrote:
>>I've replaced the file with another, get_inherit_side_test.cpp, which,
>>in test_instantiate(void), actually creates an instance of the
>>tuple_type and accesses the 0-th element with:
>>>The code in your posting used the construct
>>> r.get_tail< .... >
>>>I don't see how that can compile unless something is defined with a
>>>member template called "get_tail."
>>Sorry, I should have said:
> That wouldn't have changed anything. I wasn't confused about the lack
> of something after ">" (heck, it might have been there for all I know).
> There was no member function template called get_tail, which makes the
> above just as un-compilable as whatever you wrote before.
But the aforementioned
does compile? OK, now I see. Instead of >::head_type, there
should have been >::type::head_type. Does it make sense now?
After all, it's no different than:
for some super_type_expr which access's some super_type of t and
where member_var_name is some member variable defined in that
Anyway, I've uploaded get_ith_head_test.cpp to sandbox/vault which
does include the member function:
< typename Head
, typename Tail
which does what tuple's get<Depth> does, AFAICT. The code compiles
and passes the tests with both intel and gcc compilers.
>>OK, but I, and maybe others, are interpreting the page as meaning
>>inherit_linearly is less capable than tuple as far as accessing
> First of all, nothing in the book gives you any reason to think the text
> is saying it's difficult compared to working with boost::tuple. We
> don't even mention boost::tuple there.
True, but the reader can only assume:
it's difficult to access the value member
in the last paragraph of p. 191 meant difficult w.r.t. some
"standard", which I assume was t.member_var_name or, in the case of
the example from p. 191, t.value. I only chose tuple as a comparison
candidate because I assumed you thought its element access was not
"too difficult" w.r.t. the standard since the following post:
implied tuple's element access complexity was less than that of the
OK, you're right, this also mentioned nothing about inherit_linearly,
but I hope you can see how it would be easy to jump to this
> Second of all, by itself, of course the **result of invoking
> inherit_linearly** shown on that page is less capable than tuple,
> because there's no convenient access function like get<> provided.
Yes, but since the difficulty of element access is mentioned, and no
easy solution provided, and since the book is about solution's
provided by mpl, and since other book sections pose problems and then
provide solutions, it's only natural for the reader to assume a
solution is either impossible or very difficult; yet,
get_ith_head_test.cpp demonstrates that it's neither. The only change
involves using inherit_head_tail instead of inherit and defining
get_ith_tail, which, as you say, is not particularly original; hence,
the method used by get_ith_tail should be at least mentioned as a
solution to the problem.
> Finally, the kind of access being done is completely different from
> what's done with tuple.
I've not looked *real* close at tuple, but I assumed boost::tuple had
the following type of access:
tuple member function template, get<i>, provides access to the
i-th value in an instance of tuple<T0,T1,...Tn> where i varies
Likewise, tuple_type in test_instantiate in get_ith_head_test.cpp in
sandbox/value has a very similar kind of access:
tuple_type member function template, get_ith_head<i>, provides
access to the i-th value in an instance of:
where types is some type sequence with type elements:
and pexp<_2> is some placeholder expression containing
placeholder _2, where i varies from 0..n-1.
Could you elaborate on how the kinds of element access in boost::tuple
and that of tuple_type in get_ith_head_test.cpp are different?
> I think I'll wait to see if anyone else is confused by this before
> worrying about it. :o)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk