range-v3

range-v3 how to action::join with delimiter

半世苍凉 提交于 2019-12-08 12:41:39
问题 I get range-v3 for MSVC from git. And compile by MSVC C++14 compiler. Consider code: auto getter2 = [](const std::string&r) { return r+r; }; std::vector<std::string> vv = { "11","22", "33" }; std::cout << (vv | view::transform(getter2) | action::join) << std::endl; It works as expected. But I want to add delimiter to join and if I write std::cout << (vv | view::transform(getter2) | action::join(",")) << std::endl; The code does not been compiled. What is wrong? Mass of compiler error is below

range v3 flattening a sequence

我只是一个虾纸丫 提交于 2019-12-07 09:51:23
问题 So I recently watched this talk on c++: https://www.youtube.com/watch?v=mFUXNMfaciE And I was very interested on trying it out. So after some toy program I am stuck on how to properly flatten a vector of vectors into a vector. According to the documentation here: https://ericniebler.github.io/range-v3/ This is possible using ranges::view::for_each . However I just can't seem to get it to work. Here is some minimal code. #include <range/v3/all.hpp> #include <iostream> #include <vector> int

How to concat two existing ranges::view?

给你一囗甜甜゛ 提交于 2019-12-06 17:00:41
I want to use an existing view for concatenation. In code: auto rng = view::empty<vector<int>>(); for(int i{0}; i < 5; ++i) { vector<int> const & v{foo()}; // returns a reference rng |= view::concat(v); // doesn't compile - error: no viable overloaded '|=' }; In other words - how can I create a view to multiple vectors whose number is not known until runtime? You can't compose views this way. Concatenating a view yields an object with a different type. You can't assign it back to the original view because its type is different. You can get the effect you're after with a combination of view:

Why is ranges::ostream_iterator default-constructible?

安稳与你 提交于 2019-12-05 06:55:17
This question follows a discussion in the comments here . In Eric Niebler's ranges-v3 library (which is sort-of becoming part of the standard for C++20), ranges::ostream_iterator is default-constructible - without an ostream. How come? I thought that "dummy" construction with effective construction later is an anti-pattern in C++, a wart we are gradually getting rid of. std::ostream iterator can only be constructed with a stream (for now - before C++20). And it's not as though we can do anything with the default-constructed range::ostream_iterator ... So, what's the deal? This follows the

Explicit range-v3 decltype evaluates to void?

我与影子孤独终老i 提交于 2019-12-02 01:29:13
问题 I am trying to get an explicit type of a range (I may want to store it as a field in a class in the future). However, for some reason, it evaluates to void ? #include <iostream> #include <set> #include <range/v3/view/transform.hpp> class Alpha { public: int x; }; class Beta : public Alpha { }; class Foo { public: std::set<Alpha*> s; using RangeReturn = decltype(std::declval<std::set<Alpha*>>() | ranges::v3::view::transform(std::function<Beta*(Alpha*)>())); RangeReturn r(); }; Foo::RangeReturn

How do I write a range pipeline that uses temporary containers?

别说谁变了你拦得住时间么 提交于 2019-11-29 22:47:55
I have a third-party function with this signature: std::vector<T> f(T t); I also have an existing potentially infinite range ( of the range-v3 sort ) of T named src . I want to create a pipeline that maps f to all elements of that range and flattens all the vectors into a single range with all their elements. Instinctively, I would write the following. auto rng = src | view::transform(f) | view::join; However, this won't work, because we cannot create views of temporary containers. How does range-v3 support such a range pipeline? I suspect it just can't. None of the view s have any machinery

Why aren't ranges' algorithms compatible with std's iterators?

别等时光非礼了梦想. 提交于 2019-11-27 16:14:30
问题 #include <vector> #include <iostream> #include <range/v3/all.hpp> int main() { auto coll = std::vector{ 1, 2, 3 }; ranges::copy( coll, ranges::ostream_iterator<int>{ std::cout, ", " } ); // ok ranges::copy( coll, std::ostream_iterator<int>{ std::cout, ", " } ); // error } The issue is shown in the code above. I use ranges-v3-0.3.7. To me, the generic algorithm copy shouldn't care about the destination iterator type as long as it meets the requirements of output iterator. If so, why aren't