Boost logo

Boost :

From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-01-15 18:31:36

On 01/15/2005 02:25 PM, David Abrahams wrote:
> Maybe. The one I'm using comes from the C++ Standard:

OK. As I said below, our definitions differ.

> 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.
OK. I read the page differently. I thought it meant that
there was difficult or impossible to access the elements. Then there's
the sentence on p. 191:

   We can't access any other than the first one directly.

OK, I guess "can't access directly" does not mean "can't access",
but then consider the next paragraph:

   it's difficult to access the value member of a given type even by
   casting to an appropriate base class.

This leaves me with the impression that it's "difficult" to access
members other than the first; yet a template member function such as
boost::tuple's, get<1>, doesn't seem difficult, at least to me.
>>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.

True, it's much simpler, but does involve compile-time evaluation of
offset from the start of the structure.

>>>Also, your sample code has no get_tail member template, so I don't see
> ^^^^^^^^^^^^^^^^^^^^^^^^

OK, the key work is *member*. I apologize. There is no
member template.

>>>how that could compile...

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:


Obviously, this could be shortened with a member template,


which simply returned the above expression. The uploaded code compiles
with just a warning about t being used before it's defined.

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

Sorry, I should have said:


but then I would have had to provide the code like that in the
newly uploaded file, and it didn't seem, at the time, necessary
to demonstrate my point.

>>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
> The book isn't making a very deep point there, but the point it does
> make is valid.

OK, but I, and maybe others, are interpreting the page as meaning
inherit_linearly is less capable than tuple as far as accessing
the elements. And with a member template, like boost's tuple, is not significantly more difficult than:


where foo is maybe an enumerator "naming" say the 2nd element in the

Boost list run by bdawes at, gregod at, cpdaniel at, john at