Structured binding to replace std::tie abuse

Question

In reading this summary of the c++17 final features I was a bit surprised by the section on structured bindings (emphasis mine):

structured bindings

Until now, there was a known trick to abuse std::tie to assign a tuple or pair to different variables directly, instead of having to deal with the result type manually. This was a hack, and also the variables had to exist, now you can declare the variables and initialize them in one line:

auto [a , b , c] = getvalues();

The braces are needed, getvalues returns a tuple. std::pair is not mentioned in the proposal, so its unclear if this works with pair, which is returned by the STL in some insert methods.

I am assuming they refer to this kind of usage of std::tie

int a,b,c;
std::tie(a,b,c) = std::make_tuple(1,2,3);

which I believed to be a recommended practice.

Can someone offer an explanation as to why they are referring to above example as a hack?

Answer 1

I'm hoping nobody minds me bringing my opinion to the mix because I think it's still valid. I agree with a lot of what is said, but I don't think structured bindings will replace std::tie. There is a specific use-case for std::tie that you simply can't do with structured bindings because the variables are declared at site. Now don't get me wrong, I'm a fan of structured bindings, but I recently came across a case where they just just didn't cut it. I had this structure...

std::vector<std::tuple<std::string, uint32_t, uint64_t>> values;

typedef struct
{
    std::string s;
    uint32_t o;
    uint64_t v;
} A;

std::vector<A> my_objs;

Okay, so I had vector of tuples and a vector of objects and what I want to do was to take the values from the tuples and assign these values to each of the existing objects in the vector as below:

// (This is a very contrived example and you should assume that the
// objects in my_obj are much more complex, already exist and you just want
// to set some values in them)

for (size_t i = 0; i < my_obj.size(); i++)
    std::tie(my_objs.at(i).s, my_objs.at(i).o, my_objs.at(i).v) = values.at(i);

// Sure, you could create a method for my_obj that takes the values, but that's a very
// heavy handed approach and missing the point.

If the variable doesn't exist, then structured bindings are your best friend, but if it does, they simply don't help. Also, as someone has mentioned, there are a number of other omissions from structured bindings that for me, means they come up lacking. Firstly the ability to nest them, such that one of the variables might itself be a tuple/pair etc. Secondly, although this is a little different, the inability to use structured bindings in lambda expression declarators like this:

std::unordered_map<std::string, Item*> items;

std::for_each(items.begin(), items.end(), [](const auto&[s, item]) { delete item; });   // Not allowed, you have to do...
std::for_each(items.begin(), items.end(), [](const auto& item_pair) { delete item_pair.second; });   // Acceptable

What I think would have been useful for structured bindings would be to have the ability that the declared variables could be references to existing objects. So although I feel that some people think that std::tie will be replaced by structured bindings, the reality is that std::tie still serves a very useful purpose that structured bindings could deliver, but just doesn't.

Answer 2

A very noticeable difference is std::ignore. Look at the example

std::tuple<string, string> data {"Lord", "Buddha"};
auto [a, b] = data; //valid
auto [ , b] = data; //not valid as the identifier is strongly required
string y;
std::tie( std::ignore, y ) = data; //voila

Answer 3

std::tie in itself has another functionality.

It was meant for creating a tuple with references to variables

Creates a tuple of lvalue references to its arguments or instances of std::ignore.

This is useful for creating on-the-fly tuples without having to copy the variables because they are references. I just take the example from cppreference for a usecase.

bool operator<(const S& rhs) const
{
    // compares n to rhs.n,
    // then s to rhs.s,
    // then d to rhs.d
    return std::tie(n, s, d) < std::tie(rhs.n, rhs.s, rhs.d);
}

Here tuples are created but they don't copy the variables but have references.

Now because they hold references you could "hack" it to do something like this

int a,b,c;
std::tie(a,b,c) = std::make_tuple(1,2,3);

It assigns the values of the returned tuple to the one with the references in itself.

This is even on cpprefence just mentioned as a "note"

std::tie may be used to unpack a std::pair because std::tuple has a converting assignment from pairs

In c++17 they introduced "structured bindings" to take care of the scenario to assign multible variables at once. So whether it was intentional or a hack, since c++17 this usage of tie should not be necessary anymore.

Whether std::tie was meant to be used that way or is a "hack" may be personal opinion, I guess the people who introduced std::tie know best for this. But considering how structured binding kind of replaces std::tie in that instance, they came up with a solution they think is better.

Answer 4

I can put it simply like that:

In a language where functions can return just one variable

int a,b,c;
std::tie(a,b,c) = function_returning_multiple_values();

is a hack for:

auto [a, b, c] = function_returning_multiple_values();

just as in the hypothetical world where C++ would allow just one parameter for functions

int p1, p2, p3;
p1 = ...;
p2 = ...;
p3 = ...;

function_taking_multiple_params(std::tie_params(p1, p2, p3));

would be a hack for:

function_taking_multiple_params(p1, p2, p3)

---

You are so accustomed with the C++ restriction that a function can return at most one object, but in fact it is just an artificial language restriction, just as a restriction to accept at most one parameter would be an artificial language restriction.

The std::tie is a library hack for a missing language feature. And it has some drawbacks:

• the variables need be declared beforehand
• the variable types must be declared explicitly
• Inefficient or can't be used with types that are not default constructible

---

Are structured bindings everything that they could have been? No, but for the most cases they are everything we need.

What is missing?

• Explicit type for some elements: e.g.:

auto [a, std::string b, c] = foo();

where a and c have the type deduced and b is explicit "std::string"

• Nesting. E.g.:

auto [a, [b1, b2], c] = foo();

where the second returned object from foo is a tuple like object.

• Language feature at the return site (bypassing std::tuple all together):

auto foo() -> [int, int]

instead of

auto foo() -> std::tuple<int, int>

• Named return objects

auto foo() -> [int& key, int& value]

... well... wouldn't that be nice

• and combine that with... - get ready for a cool new name - Generalized return initialization:

auto minmax_element(It begin, It end) -> [It min_it, It max_it];

auto [min = *min_it, max = *max_it] = minmax_element(...);