10

I usually create custom structs when grouping values of different types together. This is usually fine, and I personally find the named member access easier to read, but I wanted to create a more general purpose API. Having used tuples extensively in other languages I wanted to return values of type std::tuple but have found them much uglier to use in C++ than in other languages.

What engineering decisions went into making element access use an integer valued template parameter for get as follows?

#include <iostream> #include <tuple> using namespace std; int main() { auto t = make_tuple(1.0, "Two", 3); cout << "(" << get<0>(t) << ", " << get<1>(t) << ", " << get<2>(t) << ")\n"; }

Instead of something simple like the following?

t.get(0)

or 

get(t,0)

What is the advantage? I only see problems in that:

  • It looks very strange using the template parameter like that. I know that the template language is Turing complete and all that but still...
  • It makes indexing by runtime generated indices difficult (for example for a small finite ranged index I've seen code using switch statements for each possibility) or impossible if the range is too large.

Edit: I've accepted an answer. Now that I've thought about what needs to be known by the language and when it needs to be known I see it does make sense.

Improve this question
11
  • 16
    " indexing by runtime". That is the point, type should be known at compile time, so you cannot use runtime value as index. Commented Jul 8, 2019 at 15:11
  • 2
    Not a reason for why it has to be a template function but here is the reason it wasn't made a member function: stackoverflow.com/questions/3313479/… Commented Jul 8, 2019 at 15:12
  • with your get how can you have a dedicated return type depending on a computed index ? In a collection you have one type, not with a tuple Commented Jul 8, 2019 at 15:13
  • @Jarod42 Isn't that a major disadvantage though? Why use that mechanism for implementing them if it imposes such a severe restriction on their use? Commented Jul 8, 2019 at 15:13
  • 2
    "It looks very strange using the type parameter like that." - it's not a type parameter. Template parameters can be compile-time integral values instead of types (and are for get<N>). Commented Jul 8, 2019 at 15:13

4 Answers 4

Reset to default
14

The second you've said:

It makes indexing by runtime generated indices difficult (for example for a small finite ranged index I've seen code using switch statements for each possibility) or impossible if the range is too large.

C++ is a strongly static typed language and has to decide the involved type compile-time

So a function as

template <typename ... Ts> auto foo (std::tuple<Ts...> const & t, std::size_t index) { return get(t, index); }

isn't acceptable because the returned type depends from the run-time value index.

Solution adopted: pass the index value as compile time value, so as template parameter.

As you know, I suppose, it's completely different in case of a std::array: you have a get() (the method at(), or also the operator[]) that receive a run-time index value: in std::array the value type doesn't depends from the index.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Unless I'm mistaken, this is about static typing, not strong typing. Python is also strongly (but not statically) typed. That's why you can get type errors in Python at run-time that would've been caught at compilation time in (equivalent) C++, but also why tuple access is less restricted in Python. See en.wikipedia.org/wiki/Type_system#Type_checking
So strongly typed languages that have some common base type like Object could get away with returning that but because C++ doesn't it needs to know the exact type when you call get?
@DuncanACoulter If you have a common polymorphic base type, you can use something like std::vector<std::unique_ptr<Base>> to get what you want. But that only works if every type your container can store is a Base or Base derived type. If there is even a single other type, you have to fall back to std::vector<std::variant<[supported types]>> or std::vector<std::any> instead. Edit : std::variant constrains how you can structure your code and may help illustrate why std::get is the way that it is.
@FrançoisAndrieux Okay in my case that is the case. Thanks for that.
I've accepted the answer. Now that I've thought about what needs to be known by the language and when it needs to be known I see it does make sense.
6

The "engineering decisions" for requiring a template argument in std::get<N> are located way deeper than you think. You are looking at the difference between static and dynamic type systems. I recommend reading https://en.wikipedia.org/wiki/Type_system, but here are a few key points:

  • In static typing, the type of a variable/expression must be known at compile-time. A get(int) method for std::tuple<int, std::string> cannot exist in this circumstance because the argument of get cannot be known at compile-time. On the other hand, since template arguments must be known at compile-time, using them in this context makes perfect sense.

  • C++ does also have dynamic typing in the form of polymorphic classes. These leverage run-time type information (RTTI), which comes with a performance overhead. The normal use case for std::tuple does not require dynamic typing and thus it doesn't allow for it, but C++ offers other tools for such a case.
    For example, while you can't have a std::vector that contains a mix of int and std::string, you can totally have a std::vector<Widget*> where IntWidget contains an int and StringWidget contains a std::string as long as both derive from Widget. Given, say,

    struct Widget { virtual ~Widget(); virtual void print(); };

    you can call print on every element of the vector without knowing its exact (dynamic) type.

Improve this answer

2 Comments

+1 for bringing up RTTI. I will try not to be offended by your recommendation of the type systems wikipedia page but then again I was being dense so I suppose it is fair.
To be accurate, runtime polymorphism works fine without RTTI though, as long as you don't also use things like dynamic_cast.
3
  • It looks very strange

This is a weak argument. Looks are a subjective matter.

The function parameter list is simply not an option for a value that is needed at compile time.

  • It makes indexing by runtime generated indices difficult

Runtime generated indices are difficult regardless, because C++ is a statically typed language with no runtime reflection (or even compile time reflection for that matter). Consider following program:

std::tuple<std::vector<C>, int> tuple; int index = get_at_runtime(); WHATTYPEISTHIS var = get(tuple, index);

What should be the return type of get(tuple, index)? What type of variable should you initialise? It cannot return a vector, since index might be 1, and it cannot return an integer, since index might be 0. The types of all variables are known at compile time in C++.

Sure, C++17 introduced std::variant, which is a potential option in this case. Tuple was introduced back in C++11, and this was not an option.

If you need runtime indexing of a tuple, you can write your own get function template that takes a tuple and a runtime index and returns a std::variant. But using a variant is not as simple as using the type directly. That is the cost of introducing runtime type into a statically typed language.

Improve this answer

1 Comment

I know that strangeness is subjective and a weak argument. It was more a commentary when compared with other containers. However I see that other statically typed tuples like those in Scala are also accessed via "strange" compile type visible members like ._1 ._2 etc. so it does make sense on reflection. +1 for mentioning std::variant though I won't be using it.
2

Note that in C++17 you can use structured binding to make this much more obvious:

#include <iostream> #include <tuple> using namespace std; int main() { auto t = make_tuple(1.0, "Two", 3); const auto& [one, two, three] = t; cout << "(" << one << ", " << two << ", " << three << ")\n"; }
Improve this answer

2 Comments

I am going to steal this. Haha! Nice solution. =)
I now use structured binding a lot. +1 for a nice option.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.