我有一个带有以下签名的第三方函数：
std::vector<T> f(T t);
auto rng = src | view::transform(f) | view::join;
看起来 range-v3库现在有测试用例展示了如何正确地完成此操作。需要将views::cache1运算符添加到管道中：
auto rng = views::iota(0,4)
| views::transform([](int i) {return std::string(i, char('a'+i));})
| views::cache1
| views::join('-');
check_equal(rng, {'-','b','-','c','c','-','d','d','d'});
CPP_assert(input_range<decltype(rng)>);
CPP_assert(!range<const decltype(rng)>);
CPP_assert(!forward_range<decltype(rng)>);
CPP_assert(!common_range<decltype(rng)>);
那么对于原帖中的问题，解决方案是编写：
auto rng = src | views::transform(f) | views::cache1 | views::join;
views::cache1会将范围中最近生成的元素缓存在视图对象本身中。解引用迭代器将返回对缓存对象的引用。这给它一个稳定的地址，所以views::join可以在不使其悬空的情况下对其进行迭代。 - Eric Nieblerrange-v3禁止在临时容器上使用视图，以帮助我们避免创建悬空迭代器。您的示例恰好说明了为什么在视图组合中需要此规则：
auto rng = src | view::transform(f) | view::join;
view::join存储由f返回的临时向量的begin和end迭代器，那么它们将在使用之前失效。#include <iostream>
#include <vector>
#include <range/v3/range_for.hpp>
#include <range/v3/utility/functional.hpp>
#include <range/v3/view/iota.hpp>
#include <range/v3/view/join.hpp>
#include <range/v3/view/transform.hpp>
using T = int;
std::vector<T> f(T t) { return std::vector<T>(2, t); }
int main() {
std::vector<T> buffer;
auto store = [&buffer](std::vector<T> data) -> std::vector<T>& {
return buffer = std::move(data);
};
auto rng = ranges::view::ints
| ranges::view::transform(ranges::compose(store, f))
| ranges::view::join;
unsigned count = 0;
RANGES_FOR(auto&& i, rng) {
if (count) std::cout << ' ';
else std::cout << '\n';
count = (count + 1) % 8;
std::cout << i << ',';
}
}
view::join 是一个输入范围，因此是单遍的。views::cache1，正如用户 bradgonesurfing 在下面的回答中所示。 - Eric Niebler我怀疑它无法这样做。没有任何一个view具有存储临时对象的机制 - 这明确违反了来自文档中视图的概念：
视图是一种轻量级包装器，以某种自定义方式呈现底层元素序列的视图，而不对其进行变异或复制。视图创建和复制都很便宜，并具有非拥有引用语义。
因此，为了使那个join起作用并在表达式结束后仍然存在，必须在某个地方保存这些临时对象。那个东西可能是一个action。这将起作用 (演示):
auto rng = src | view::transform(f) | action::join;
除了src无限大的情况，即使对于有限的src来说，它可能会增加太多开销，你也不想使用。
你可能需要复制/重写view::join，以使用一些微调版本的view::all(这里需要查看)，而不是要求一个左值容器（并返回一个迭代器对到其中），允许存储内部的右值容器(并返回一个迭代器对到存储的版本)。但是，那需要复制几百行代码，所以似乎相当不令人满意，即使它能正常工作。
views::cache1。请参见 bradgonesurfing 的答案。 - Eric Niebler编辑
显然，下面的代码违反了视图不能拥有它们所引用数据的规则。（但我不知道像这样写是否严格禁止。）
我使用 ranges::view_facade 创建自定义视图。它保存由 f 返回的向量（一次一个），将其更改为范围。这使得可以在这些范围的范围上使用 view::join。当然，我们不能随机或双向访问元素（但 view::join 本身会将范围降级为输入范围），也不能对它们进行赋值。
我从 Eric Niebler 的存储库中复制了 struct MyRange，稍作修改。
#include <iostream>
#include <range/v3/all.hpp>
using namespace ranges;
std::vector<int> f(int i) {
return std::vector<int>(static_cast<size_t>(i), i);
}
template<typename T>
struct MyRange: ranges::view_facade<MyRange<T>> {
private:
friend struct ranges::range_access;
std::vector<T> data;
struct cursor {
private:
typename std::vector<T>::const_iterator iter;
public:
cursor() = default;
cursor(typename std::vector<T>::const_iterator it) : iter(it) {}
T const & get() const { return *iter; }
bool equal(cursor const &that) const { return iter == that.iter; }
void next() { ++iter; }
// Don't need those for an InputRange:
// void prev() { --iter; }
// std::ptrdiff_t distance_to(cursor const &that) const { return that.iter - iter; }
// void advance(std::ptrdiff_t n) { iter += n; }
};
cursor begin_cursor() const { return {data.begin()}; }
cursor end_cursor() const { return {data.end()}; }
public:
MyRange() = default;
explicit MyRange(const std::vector<T>& v) : data(v) {}
explicit MyRange(std::vector<T>&& v) noexcept : data (std::move(v)) {}
};
template <typename T>
MyRange<T> to_MyRange(std::vector<T> && v) {
return MyRange<T>(std::forward<std::vector<T>>(v));
}
int main() {
auto src = view::ints(1); // infinite list
auto rng = src | view::transform(f) | view::transform(to_MyRange<int>) | view::join;
for_each(rng | view::take(42), [](int i) {
std::cout << i << ' ';
});
}
// Output:
// 1 2 2 3 3 3 4 4 4 4 5 5 5 5 5 6 6 6 6 6 6 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 9 9 9 9 9 9
使用gcc 5.3.0编译。
view::transform 只能提供一个 rvalue 引用，因为你的函数 f(T t) 返回一个容器，而view::join 希望一个 lvalue，因为它试图将视图(view::all)绑定到内部容器。view::all that can internally store a container passed by an rvalue reference (As suggested by Barry). From my point of view, this violates the
"non-storing view" conception and also requires some painful template
coding so I would suggest against this option.Use a temporary container for the whole intermediate state after the view::transform step. Can be done either by hand:
auto rng1 = src | view::transform(f)
vector<vector<T>> temp = rng1;
auto rng = temp | view::join;
Or using action::join. This would result in "premature evaluation", will not work with infinite src, will waste some memory, and overall has a completely different semantics from your original intention, so that is hardly a solution at all, but at least it complies with view class contracts.
Wrap a temporary storage around the function you pass into view::transform. The simpliest example is
const std::vector<T>& f_store(const T& t)
{
static std::vector<T> temp;
temp = f(t);
return temp;
}
and then pass f_store to the view::transform. As f_store returns an lvalue reference, view::join will not complain now.
This of course is somewhat of a hack and will only work if you then streamline the whole range into some sink, like an output container. I believe it will withstand some straightforward transformations, like view::replace or more view::transforms, but anything more complex can try to access this temp storage in non-straightforward order.
In that case other types of storage can be used, e.g. std::map will fix that problem and will still allow infinite src and lazy evaluation at the expense of some memory:
const std::vector<T>& fc(const T& t)
{
static std::map<T, vector<T>> smap;
smap[t] = f(t);
return smap[t];
}
If your f function is stateless, this std::map can also be used to potentially save some calls. This approach can possibly be improved further if there is a way to guarantee that an element will no longer be required and remove it from the std::map to conserve memory. This however depends on further steps of the pipeline and the evaluation.
view::transform 和 view::join 之间引入临时存储的所有位置，因此我认为这些是您的所有选项。我建议选择第三种方案，因为它将使您保持整体语义完整，并且实现起来非常简单。auto&& x = f();扩展了f的结果的生命周期，但是auto&& x = g(f());不会，并且由g来确保它的生命周期与其返回值一样长。 - R. Martinho Fernandesf()返回的任何值存储在这个“rvalue view”中，就像其他答案建议的那样。我想“绑定”这个词不太合适。然而，我认为无法避免使用临时变量，因为沿着线路堆叠的view允许（并且view::join将）尝试多次访问这些元素。 - Ap31view::join 违反了这种函数式行为，因为它通过存储左值引用来实现 - 适当的函数式实现只需在需要时每次调用底层视图即可。在这种情况下，这将导致额外的 f() 调用，从函数式的角度来看这是完全可以接受的，但在现实中，函数会消耗 CPU 并且有时具有状态。但是，是的，这个“修复”的 view::join 将是 rvalue-friendly 的，这将是一个 - 适当的 - 解决方案，我想。 - Ap31更新
range-v3现在有一个名为views::cache1的视图，它将最近的元素缓存在视图对象本身中，并返回对该对象的引用。正如用户@bradgonesurfing在他的答案中指出的那样，这是今天清晰高效地解决此问题的方法。
下面是旧的、过时的答案，仅作历史趣味保留。
这是另一种不需要太多花哨技巧的解决方案。它的代价是每次调用f都需要调用std::make_shared。但是，在f中分配和填充容器，因此可能这是一个可以接受的代价。
#include <range/v3/core.hpp>
#include <range/v3/view/iota.hpp>
#include <range/v3/view/transform.hpp>
#include <range/v3/view/join.hpp>
#include <vector>
#include <iostream>
#include <memory>
std::vector<int> f(int i) {
return std::vector<int>(3u, i);
}
template <class Container>
struct shared_view : ranges::view_interface<shared_view<Container>> {
private:
std::shared_ptr<Container const> ptr_;
public:
shared_view() = default;
explicit shared_view(Container &&c)
: ptr_(std::make_shared<Container const>(std::move(c)))
{}
ranges::range_iterator_t<Container const> begin() const {
return ranges::begin(*ptr_);
}
ranges::range_iterator_t<Container const> end() const {
return ranges::end(*ptr_);
}
};
struct make_shared_view_fn {
template <class Container,
CONCEPT_REQUIRES_(ranges::BoundedRange<Container>())>
shared_view<std::decay_t<Container>> operator()(Container &&c) const {
return shared_view<std::decay_t<Container>>{std::forward<Container>(c)};
}
};
constexpr make_shared_view_fn make_shared_view{};
int main() {
using namespace ranges;
auto rng = view::ints | view::transform(compose(make_shared_view, f)) | view::join;
RANGES_FOR( int i, rng ) {
std::cout << i << '\n';
}
}
shared_view 的构造函数从 Container const& 中移除，以防止未来的更改将 O(1) 构造变成 O(N) 构造，这个想法怎么样？ - Caseyauto rng = src | views::transform(f) | views::cache1 | views::join; - horseyguyview::cache1并不存在。 - Eric Niebler
for (int i : std::vector({1,2,3}) | mytransform([](int i) { return i+1; })) { std::cout << i << std::endl; }。 我的mytransform函数会因为std::vector过早被删除（基于范围的for循环的右手边的临时变量的生命周期会延长到循环结束，但其他任何临时变量都不会被延长）而产生垃圾或崩溃。@bradgonesurfing上面的评论解决了这个问题。 - Don Hatch