How can I take ownership of a collection using range-v3? - c++

Question

I want to return a range from a function that represents a view on a STL collection, something like this:
auto createRange() {
std::unordered_set<int> is = {1, 2, 3, 4, 5, 6};
return is | view::transform([](auto&& i) {
return i;
});
}
However, view::transform does not take ownership of is, so when I run this, there is undefined behavior, because is is freed when createRange exits.
int main(int argc, char* argv[]) {
auto rng = createRange();
ranges::for_each(rng, [](auto&& i) {
std::cout << std::to_string(i) << std::endl;
});
}
If I try std::move(is) as the input, I get a static assert indicating that I can't use rvalue references as inputs to a view. Is there any way to ensure that the view takes ownership of the collection?
Edit: Some Additional Info
I want to add some clarifying info. I have a stream of data, data that I have a view on that transforms the data into a struct, Foo, that looks something like this:
struct Foo {
std::string name;
std::unordered_set<int> values;
}
// Take the input stream and turn it into a range of Foos
auto foos = data | asFoo();
What I want to do is create a range of std::pair<std::string, int> by distributing the name throughout the values. My naive attempt looks something like this:
auto result = data | asFoo() | view::transform([](auto&& foo) {
const auto& name = foo.name;
const auto& values = foo.values;
return values | view::transform([name](auto&& value) {
return std::make_pair(name, value);
}
}) | view::join;
However, this results in the undefined behavior because values is freed. The only way that I have been able to get around this is to make values a std::shared_ptr and to capture it in the lambda passed to view::transform to preserve it's lifetime. That seems like an inelegant solution.
I think what I am looking for is a view that will take ownership of the source collection, but it does not look like range-v3 has that.
Alternatively, I could just create the distributed version using a good old fashioned for-loop, but that does not appear to work with view::join:
auto result = data | asFoo() | view::transform([](auto&& foo) {
const auto& name = foo.name;
const auto& values = foo.values;
std::vector<std::pair<std::string, std::string>> distributedValues;
for (const auto& value : values) {
distributedValues.emplace_back(name, value);
}
return distributedValues;
}) | view::join;
Even if this did work with view::join, I also think that the mixed metaphor of ranges and loops is also inelegant.

Answer 1

Views do not own the data they present. If you need to ensure the persistence of the data, then the data itself needs to be preserved.
auto createRange() {
//We're using a pointer to ensure that the contents don't get moved around, which might invalidate the view
std::unique_ptr<std::unordered_set<int>> is_ptr = std::make_unique<std::unordered_set<int>>({1,2,3,4,5,6});
auto & is = *is_ptr;
auto view = is | view::transform([](auto&& i) {return i;});
return std::make_pair(view, std::move(is_ptr));
}
int main() {
auto[rng, data_ptr] = createRange();
ranges::for_each(rng, [](auto&& i) {
std::cout << std::to_string(i) << std::endl;
});
}
An alternate method is to make sure the function is provided the data set from which the view will be created:
auto createRange(std::unordered_set<int> & is) {
return is | view::transform([](auto&& i) {return i;});
}
int main() {
std::unordered_set<int> is = {1,2,3,4,5,6};
auto rng = createRange(is);
ranges::for_each(rng, [](auto&& i) {
std::cout << std::to_string(i) << std::endl;
});
}
Either solution should broadly represent what your solution for your project will need to do.