On 01/15/2005 10:11 AM, David Abrahams wrote:
Larry Evans wrote:
The code in:
http://boost-sandbox.sourceforge.net/vault/inherit_linearly_test.cpp
provides easy access to the elements of inherit_linearly
?? inherit_linearly is a metafunction. It doesn't have elements. Maybe you mean the result of invoking it?
Yes.
with:
get_tail<inherit_linearly<...>, i>::head_type
which returns the i-th element in the inheritance heirarchy. Couldn't this be used to generate member names using templates?
No, as the book says, there really is no way to generate member names using templates.
[snip]
book would be:
r.get_tail<inherit_linearly<...>, i>::head_type::value
That's not a name; it's an expression.
Well, sure, just as 1+1 is an expression, but it's an "alias" for 2, just as the expression r.x is an "alias" for element x in record r, or r[2] is an "alias" for the 2nd element in an array, or r.::tail_type::tail_type::head_type.value is an "alias" for 2nd element in a record like that in the example code. Maybe the definition of name I'm thinking about includes any compile-time evaluated expression. I can't remember where, but it was in some computer science textbook where expressions were called names for the result of the expression, and that's why I used the term "name". Besides, if an expression provides the same capability as a name, i.e. the ability to access the element, what's the importance of providing a "real name" (i.e. a c++ identifier) for the element? Anyway, my definition of name differs from yours, but if the only purpose is to provide a compile-time evaluated offset from some container, then both definitions satisfy the purpose.
Also, your sample code has no get_tail member template, so I don't see how that could compile...
I just downloaded it and it has get_tail specializations on lines 34 and 46. I've compiled it with intel 8.0 and maybe it's not standard, but I don't think the primary template needs to be defined if it's not used.
where r is an instance of:
inherit_linearly<types, inherit_head_tail<wrap<_2>,_1> >::type
...that said, this doesn't seem like a particularly original idea. It
True, but I'm not claiming it's originality, just that it allows access to the elements with the same runtime cost as that provided by a "real name".
seems like a complicated way of expressing what boost::tuples::get
It's no more complicated than that provided by tuples::get. It's just an adaptation of the same (or very similar, AFAICT) method to access the elements.
already provides. Am I missing something?
Just that the book seems to indicate there's a difficulty in accessing the elements which isn't really there, unless you define typing a long compile-time evaluated expression as difficult.