[boost] Re: [mpl] easy access to inherit_linearly elements

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-15 16:25:54

Larry Evans wrote:
> On 01/15/2005 10:11 AM, David Abrahams wrote:
>> Larry Evans wrote:
>> 

>>>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,

Not if you're interested in tokens.

> 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.

Maybe.  The one I'm using comes from the C++ Standard:

3 Basic concepts [basic]
....
4 A name is a use of an identifier (2.10) that denotes an entity or
label (6.6.4, 6.1). A variable is introduced by the declaration of an
object. The variable's name denotes the object.

> 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?

None other than ease-of-use.  The point of that note about names is to
say you can't access an arbitrary member of that composed class by
naming the member in the usual way, because all those members will have
the same name, and that's unavoidable with TMP.  Nothing more.

> 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.

Not really.  My definition doesn't really allow for much compile-time
evaluation.

>> 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.  

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."

>>>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.

It's certainly more difficult than typing

   r.foo

The book isn't making a very deep point there, but the point it does
make is valid.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com