For std::tr1::tuple there is no definitive template signature
because the number of elements is unspecified.

Without the signature it is not possible to detect in an
implementation independent way if some type T is a std::tr1::tuple.
There is no specific signature that can be matched.

In 6.13 in N1836 it states that M denotes the maximum elements to a
tuple.
It would be nice to have a standardised way to know the value of M.
One could then apply
(for example) a similar technique to the following which detects if a
type
is a (or is derived from ) a std::tr1::integral_constant.

I use is_integral_constant specifically to overload compile time
 math operations for std::tr1::integral constants
and static rational constants

// example implementation of is_integral_constant
// but requires the signature of the type to be known to work..
struct integral_constant_tester{
      struct yes_type{};
      struct no_type{
         char array [2 * sizeof(yes_type)];
      };
      template <typename T1, T1 N>
      static yes_type f( std::tr1::integral_constant<T1,N>* p);
      static no_type f(...);

      template <typename T>
      static T * fun();
   };

   template <typename T>
   struct is_integral_constant : std::tr1::integral_constant<
      bool,

(sizeof(integral_constant_tester::f(integral_constant_tester::fun<T>()))
         == sizeof(integral_constant_tester::yes_type))
   >{};


Detecting if some type "is_a" T is important in being able
to apply generic algorithms to types, both compile time and runtime.

In case of tuple it could be used to overload an algorithm iterating
over a sequence
based on whether a type is a (say) std::vector or a std::tr1::tuple.

If there was a standard way to get the implemntation defined maximum
number
 of template arguments,
it would at least be possible to use some MACRO magic to create a
signature to match.

regards
Andy Little

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1172472042.217240.305440@j27g2000cwj.googlegroups.com>,
 "kwikius" <andy@servocomm.freeserve.co.uk> wrote:

> For std::tr1::tuple there is no definitive template signature
> because the number of elements is unspecified.
>
> Without the signature it is not possible to detect in an
> implementation independent way if some type T is a std::tr1::tuple.
> There is no specific signature that can be matched.

The original tuple proposal (N1382) had:

is_tuple<T>::value
is_tuple_like<T>::value

which I personally found incredibly useful.  I know that they were not
dropped by accident, but I don't fully understand why they were dropped.
I'd love to see them come back.

-Howard

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Feb 26, 8:34 am, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
> Detecting if some type "is_a" T is important in being able
> to apply generic algorithms to types, both compile time and runtime.
>
> In case of tuple it could be used to overload an algorithm iterating
> over a sequence
> based on whether a type is a (say) std::vector or a std::tr1::tuple.
>
> If there was a standard way to get the implemntation defined maximum
> number
>  of template arguments,
> it would at least be possible to use some MACRO magic to create a
> signature to match.

I also see the need for a platform-independent way to recognize tuples
and similar variadic templates per compiletime template techniques
(or equivalent).

I would like to emphasize, that most of the above mentioned problems
can be solved via the "variadic templates" proposal, where the most
recent development can be read in

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2151.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2152.pdf

and its predecessors. In my opinion this proposal exactly fills a
missing gap (I hope this phrase does not mean anything rude in
english...).

Greetings from Bremen,

Daniel Kr   gler





---
[ 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.comeaucomputing.com/csc/faq.html                      ]