After testing the current boost-implementation of std::tr1 found at

http://boost-sandbox.sourceforge.net/vault/index.php?&direction=3D0&order=
=3D&directory=3Dtr1=20


combined with similar tests of the implementation of boost::tuples
library (1.32 and 1.33 RC 2).

I observed that the implementation of both class templates

std::tr1::tuple_length

and

boost::tuples::size

is not invariant concerning cv qualifications of the template arguments
for **empty** tuples. E.g. the following code

int len =3D std::tr1::tuple_length<const std::tr1::tuple<> >::value;

does not compile. The reason is simply explainable by the fact that
std::tr1::tuple_length<> is specialized only for non-cv qualified
std::tr1::tuple<> (and null_type, which is the implementation-defined
backend type of tuple<>) and the generic implementation cannot handle
empty tuples.

To my opinion the reading of

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf

which is given by

"Valid expressions for tuple types
tuple_size<T>::value
Requires: T is an instantiation of class template tuple.
Type: integral constant expression.
Value: Number of elements in T."

and even TR1 papers like

http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf

does not say different and implies that cv-qualification of tuples
should not influence the outcome of std::tr1::tuple_length.

Similar problems arise for **any** cv-qualified std::tr1::array<typename
T, int N> (independent of N!) and for cv-qualified std::pair<typename,
typename> as arguments of std::tr1::tuple_length<>. Another cv-variance
violation can be found for std::tr1::tuple_element for the instances:

std::tr1::tuple_element<I, cv std::pair<T1, T2> >
std::tr1::tuple_element<I, cv std::tr1::array<T, N> >


To my opinion this article can be related to the still open issue

http://www2.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#251

which astonishingly has not been resolved since 5 years.

Another interesting question is, whether for tuple_size-compatible types
their corresponding **references** should work as arguments for
std::tr1::tuple_length<>. One point of view is that reference T& can be
interpreted as an alias for T. In this position td::tr1::tuple_length<cv
T&>::value would absolutely make sense.

Greetings from Bremen,

Daniel Kr=FCgler

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]