Programming puzzle / quiz.

[Critkeeper]

suppose i have a tuple containing tuples and arrays

Code: [Select]

tuple
< tuple
< map<int, int>
, float
>
, tuple
< int
, int
>
, array
< int
5
>
, tuple
< vector<int>
, queue<float>
>
>
state;

the normal way to access an element in a tuple is to use

Code: [Select]

get <Index> (tuple);
so for the above, to access the array I would use

Code: [Select]

get <2> (state);
but in order to access the 3rd element of the array I would have to say:

Code: [Select]

get <3> ( get <2> (state) );
this is quite ugly.


here is an imaginary function that looks prettier:

Code: [Select]

get <3> (state, 2);
what would the full function signature for such a function look like?

[Hiura]

You can't do that because 2 is a template parameter which need to be known at compile time. You might do something with some template magic but honestly... why so many tuples? A struct would be way much simpler...

[Nexus]

The index must be a constant expression. You can write a function template func<N, M>(tuple) that wraps get<M>(get<N>(tuple)). But as Hiura says, it's going to be ugly, especially since you mix tuples with arrays. Try to find an easier solution.

And can we please stop this bad habit of posting everything in General Discussions? This subforum clearly revolves around discussions about the library, not help requests. Your topic is not even related to SFML

[Hiura]

Ho, and I remember now: I've read something along those line recently. Here: http://kirkshoop.github.io/2015/06/16/user_defined_literal__idx_and_operator_for_tuple_pair_and_any.html

[Critkeeper]

The index must be a constant expression. You can write a function template func<N, M>(tuple) that wraps get<M>(get<N>(tuple)). But as Hiura says, it's going to be ugly, especially since you mix tuples with arrays.

Code: [Select]

template <int s, int i, class... Types>
typename tuple_element <s, tuple_element<i, tuple<Types...>>&>::type&
get ( tuple <Types...>& T )
{
    return get <i> (get <s> (T));
}

[Hiura]

Well, you're missing at least two overloads (if we don't count the `get<type>(tuple)` versions) and both i and s should not be ints.