Re: Function Overload for tr1::tuple<T>, How To?
Pete Becker wrote:
Greg Herlihy wrote:
Pete Becker wrote:
There is no conversion taking place when passing a tuple to Log(), so
the Log() overload is certain to work for all tuple types. Every tuple
type in an implementation always has the same number of type parameters
- zero or more of which may be user-specified. So each one of Log's ten
parameterized types, T1 - T10, corresponds to a parameterized type in
the tuple. In this case, type parameters T1 - T3 correspond to the
tuple's user-specified types while type parameters T4 - T10 correspond
the same, implementation-defined "unspecified" type that the tuple
template provides as a default type parameter.
Having thought about it some more, you may be right that there's a
loophole here. That happens sometimes when the description of an
implementation is turned into a specification. I don't think that
loophole will survive. It makes too big a hole in type safety if a tuple
with three elements can pretend to be a tuple with four elements.
Being able to write just one function template that can match a tuple
argument type regardless of its "size" (that is, the number of
user-specified types contained therein) is not a "loophole" in either
the design or implementation of std::tr1::tuple. On the contrary, much
of the tuple template's usefulness and its expressive power depend on
precisely such abstractions being possible.
A program should have a choice when it comes to distinguishing the size
of a tuple type: whether a tuple's size is recognized at the interface
level (as in your example) or whether the size becomes an
implementation level detail (as in my mine). Supporting only the
former and not the latter would significantly (and needlessly)
eliminate some of the most useful ways that a program is likely to use
the tuple class template.
Take just one example. C++ is often described as a "better C than C"
because C++ does not merely extend C's capabilities, but in many cases
it offers a superior alternative to what is already available in C.
Inline functions over macros, constant declarations over #defines are
just two common examples. A std::tr1::tuple continues this tradition by
providing a better variable parameter list than varargs and the
ellipsis notation. A tuple lets a C++ program pass a variable number of
non-POD type arguments, pass an argument either by reference or by
value, and pass the entire argument list in a type safe manner. None of
those abilities are possible with varargs. So it is possible to imagine
reinventing printf routine as a C++ function:
using std::tr1::tuple;
using std::tr1::tuple_size;
template <class T1, class T2, class T3, class T4, class T5,
class T6, class T7, class T8, class T9, class T10>
int
PrintF( std::string& format, const tuple<T1, T2, T3, T4, T5,
T6, T7, T8, T9, T10>& s)
{
const int n = tuple_size<tuple<T1, T2, T3, T4, T5,
T6, T7, T8, T9, T10>::value;
for (int i = 0; i < n; i++)
{
// handle each parameter
}
}
Now requiring that this PrintF() routine be implemented as ten separate
functions would effectively eliminate the tuple class template's
usefulness as a superior alternative to varargs. Using a tuple as a
variable argument list would simply be too impractical. And in fact, if
a program were to have to implement ten separate routines, it would no
doubt be better off doing so without the tuple and just have the client
pass the arguments as individual parameters, directly.
Ultimately there is no loophole with std::tr1::tuple because there is
no conflict - only a choice. It's not the case that a function written
to accept a tuple of size four can be tricked into accepting a tuple
whose size is five. What is possible (and what the library should
continue to ensure is possible) is that the programmer can choose to
write just one function template and have it accept both four and five
(and in fact, any) size of tuple as an argument. Effectively a C++
programmer shoould be able to decide whether a tuple's size is an
interface-level - or an implementation-level - detail of their program.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]