Range library for C++14/17/20, basis for C++20's std::ranges

Overview

range-v3

Range library for C++14/17/20. This code was the basis of a formal proposal to add range support to the C++ standard library. That proposal evolved through a Technical Specification, and finally into P0896R4 "The One Ranges Proposal" which was merged into the C++20 working drafts in November 2018.

About:

Ranges are an extension of the Standard Template Library that makes its iterators and algorithms more powerful by making them composable. Unlike other range-like solutions which seek to do away with iterators, in range-v3 ranges are an abstration layer on top of iterators.

Range-v3 is built on three pillars: Views, Actions, and Algorithms. The algorithms are the same as those with which you are already familiar in the STL, except that in range-v3 all the algorithms have overloads that take ranges in addition to the overloads that take iterators. Views are composable adaptations of ranges where the adaptation happens lazily as the view is iterated. And an action is an eager application of an algorithm to a container that mutates the container in-place and returns it for further processing.

Views and actions use the pipe syntax (e.g., rng | adapt1 | adapt2 | ...) so your code is terse and readable from left to right.

Documentation:

Check out the (woefully incomplete) documentation here.

Other resources (mind the dates, the library probably has changed since then):

License:

Most of the source code in this project are mine, and those are under the Boost Software License. Parts are taken from Alex Stepanov's Elements of Programming, Howard Hinnant's libc++, and from the SGI STL. Please see the attached LICENSE file and the CREDITS file for the licensing and acknowledgments.

Supported Compilers

The code is known to work on the following compilers:

  • clang 5.0 (or later)
  • GCC 6.5 (or later)
  • Clang/LLVM 6 (or later) on Windows (older versions may work - we haven't tested.)
  • Visual Studio 2019 (or later) on Windows, with some caveats due to range-v3's strict conformance requirements:
    • range-v3 needs /permissive- and either /std:c++latest or /std:c++17

Development Status: This code is fairly stable, well-tested, and suitable for casual use, although currently lacking documentation. In general, no promise is made about support or long-term stability. This code will evolve without regard to backwards compatibility.

A notable exception is anything found within the ranges::cpp20 namespace. Those components will change rarely or (preferably) never at all.

Build status

  • on GitHub Actions: GitHub Actions Status

Building range-v3 - Using vcpkg

You can download and install range-v3 using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install range-v3

The range-v3 port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Building range-v3 - Using Conan

You can download and install range-v3 using the Conan dependency manager.

Setup your CMakeLists.txt (see Conan documentation on how to use MSBuild, Meson and others):

project(myproject CXX)

add_executable(${PROJECT_NAME} main.cpp)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake) # Include Conan-generated file
conan_basic_setup(TARGETS) # Introduce Conan-generated targets

target_link_libraries(${PROJECT_NAME} CONAN_PKG::range-v3)

Create conanfile.txt in your source dir:

[requires]
range-v3/0.10.0

[generators]
cmake

Install and run conan, then build your project as always:

pip install conan
mkdir build
cd build
conan install ../ --build=missing
cmake ../
cmake --build .

Building range-v3 - Using build2

You can use build2, a dependency manager and a build-system combined, to use range-v3 (or work on it):

Currently this package is available in these package repositories:

Usage:

For example, to make your build2 project depend on range-v3:

  • Add one of the repositories to your configurations, or in your repositories.manifest, if not already there; for example:
    :
    role: prerequisite
    location: https://pkg.cppget.org/1/alpha # v0.11.0 is there.
    
  • Add this package as a dependency to your manifest file (example for v0.11.x):
    depends: range-v3 ~0.11.0
    
  • Import the target and use it as a prerequisite to your own target using range-v3 in the appropriate buildfile:
    import range_v3 = range-v3%lib{range-v3}
    
    lib{mylib} : cxx{**} ... $range_v3
    

Then just build your project as usual (with b or bdep update), build2 will figure out the rest.

For build2 newcomers or to get more details and use cases, you can read this document and the build2 toolchain introduction.

Say Thanks!

I do this work because I love it and because I love C++ and want it to be as excellent as I know it can be. If you like my work and are looking for a way to say thank you, you can leave a supportive comment on my blog. Or you could leave me some kudos on my Open Hub range-v3 contribution page. Just click the Give Kudos button here.

Issues
  • `const`-ness of view operations

    `const`-ness of view operations

    Containers

    Containers in C++ may have both const and non-const overloads of begin. They differ only in their return types: non-const begin returns a mutable iterator, and const begin a constant iterator. Neither overload changes the bits of the container representation or modifies the semantic value of the container object. Two overloads exist so that it is necessary to establish a non-const access path to the container object in order to obtain a mutable iterator. end is the same. size is always const because it provides no way to modify the container's content.

    Views

    Views in range-v3 may have both const and non-const overloads of begin/end/size (herein termed "operations"). Views have pointer semantics - a view is essentially a pointer to a sequence of elements - so mutability of the elements viewed is orthogonal to mutability of the view object itself. The const distinction here has no relation to that of containers. Non-const operations do not modify the semantic objects being viewed, nor do they "swing the pointer" so that the same view designates different semantic objects. Non-const operations mutate internal state that does not contribute to the semantic value of the view; the const-ness here is purely bitwise.

    The const-ness model used by views makes view composition painful. You can always provide the non-const overloads, but const overloads are preferred when achievable. So a composer, e.g.:

    template<typename View>
    class wrap_view : view_facade<wrap_view<View>>
    {
        View base_;
    public:
        wrap_view() = default;
        wrap_view(View v)
        : base_(std::move(v))
        {}
        // ...
    };
    

    ends up providing two definitions of each operation: one const that's constrained to require const operations over the underlying view(s):

        // We need the dependent type V so that range_iterator_t<V const> doesn't hard
        // error when View has no const begin operation (or: use C++14 deduced return type).
        template <typename V = View, CONCEPT_REQUIRES_(Range<View const>())>
        range_iterator_t<V const> begin() const
        { return ranges::begin(base_); }
    

    and one mutable that's constrained to only be available when the const version isn't:

        CONCEPT_REQUIRES(!Range<View const>())
        range_iterator_t<View> begin()
        { return ranges::begin(base_); }
    

    Ranges

    I'm concerned that the differing const distinctions for containers and views don't mesh well into a consistent notion of what const means for operations on general ranges. I see a potential for latent bugs where a programmer accustomed to the fact that calling begin/end on mutable containers is threadsafe calls begin/end on mutable ranges without realizing there are sharp corners here.

    The only mutating operation on pointers is assignment. If views are supposed to be range-pointers, perhaps assignment should be the only mutating operation? We (I) need to investigate an alternative model where view operations are always const and perform internal synchronization if needed.

    opened by CaseyCarter 81
  • [cmake/travis] refactor/improve CMake; add MSan/LSan builds in travis

    [cmake/travis] refactor/improve CMake; add MSan/LSan builds in travis

    • Adds MemorySanitizer and LeakSanitizer (under ASan) in travis:

      • Builds libc++ with MemorySanitizer and AddressSanitizer as required.
      • Enables the leak sanitizer on AddressSanitizer builds under Linux.
      • Enables the unsigned-integer overflow check in the UndefinedBehaviorSanitizer:
        • Avoids overflow in view.unique tests (not a bug).
        • Add RANGES_INTENDED_MODULO_ARITHMETIC macro to explicitly annotate when modulo arithmetic is intended.
        • Explicitly annotates those parts of range-v3 in which modulo arithmetic is intended (mostly in utility/random.hpp).
    • Refactor the root CMakeLists.txt into:

      • cmake/readme.md: brief explanation of what goes where.
      • cmake/ranges_options.cmake: library configuration options.
      • cmake/ranges_env.cmake: detects environment (os, compiler, build type...).
      • cmake/ranges_flags.cmake: sets up supported compiler flags.
    • AppVeyor and Clang/C2 (by @CaseyCarter):

      • Add cmake to PATH in appveyor.yml.
      • Disable -fstruct-vtable-pointers on Clang/C2.
    • Add RANGES_NATIVE option (defaults to On) to allow disabling -march/mtune=native independently of the build-type.

    • Disables std::auto_ptr in boost (not available in C++1z).

    • Add travis build bots for clang-4.0 in C++11 and C++14.

    • Tests clang versions with the corresponding libc++ version (they were always tested with libc++ trunk).

    Closes #333: the ASAN errors reported there cannot be reproduced anymore. Closes #451: -Wnoexcept should be part of -Weverything. Closes #640: clang versions are tested with appropriate libc++ version.

    Thanks @CaseyCarter for the comments, help, and all the Clang/C2 and AppVeyor fixes.

    opened by gnzlbg 42
  • view::cycle

    view::cycle

    Turns a finite ForwardRange into an infinite range that cycles on itself.

    Example

    auto il = {0, 1, 2};
    RANGES_FOR(auto i, il | view::cycle) { std::cout << i << " "; }
    

    prints "0 1 2 0 1 2 0 1 2 0 1 2...".

    Notes on the design

    This designs chooses to make two iterators compare equal only if they point to the same element of the sequence within the same cycle. Example: in the sequence above both iterators begin and begin + 3 point to the same element (0); since they are "in different cycles" they are not equal.

    The rationale is that this allows iterating from [begin, begin + M) where M is larger than the number of elements in the sequence.

    TODO

    • The implementation of cycled_view<Rng>::cursor<IsConst>::advance is pretty ugly.
    • The implementation of cycled_view<Rng>::cursor can be optimized for RandomAccessRanges where the iterator can be obtained from the position in O(1).
    opened by gnzlbg 42
  • implements unique algorithm

    implements unique algorithm

    opened by gnzlbg 33
  • Why is filter deprecated?

    Why is filter deprecated?

    I find both filter and remove_if useful. Replacing filter(pred) with remove_if(not(pred)) makes IMO the code less readable. The intent is just harder to understand due to the double negation: do something on the elements that are not the elements for which the predicate is not true (my brain melts).

    opened by gnzlbg 30
  • Proposal: enumerated range

    Proposal: enumerated range

    I find myself doing the following quite often:

    for (const auto& [i, e]: rsv::zip(rsv::iota(0, es.size()), es)) { /* use i, e */ }
    

    This to my mind is more explicit, and leaves less room for mistakes, than:

    for (auto i = 0; i < es.size(); ++i) { /* use i, es[i] */ }
    

    If this idiom is a bad idea, I would appreciate being told why. If not, I think this would be a good candidate for addition to the library, because it is frequently the case that one wants to know the index of the item one is iterating over.

    In my code, I call this enumerated(es), but I'm not particularly attached to this name.

    enhancement 
    opened by seertaak 29
  • Compilation failure because GCC _Safe_iterator meets SizedIteratorRange concept

    Compilation failure because GCC _Safe_iterator meets SizedIteratorRange concept

    I'm getting a compilation failure that I think stems from a (GCC _GLIBCXX_DEBUG) bidirectional iterator meeting the SizedIteratorRange concept and then failing when range-v3 actually uses an expression like itr_a - itr_b.

    I'm guessing the troublesome subtlety may be: the iterator is actually a GCC _Safe_iterator, which does provide an operator-() but which just implements this by passing through to the wrapped std::list iterator that doesn't provide an operator-(). Hence I'm guessing the concepts::same_type(s - i, i - s) line in the SizedIteratorRange concept is checking that the iterator's operator-() exists and has a valid return type but isn't checking that a call to that expression is actually valid. Hence SizedIteratorRange isn't spotting that itr_a - itr_b isn't a valid expression and so doesn't get itself SFINAE-rejected as it should.

    Some illustrative code:

    #define _GLIBCXX_DEBUG
    #define RANGES_NO_STD_FORWARD_DECLARATIONS
    
    #include <iostream>
    #include <list>
    #include <type_traits>
    
    #include <range/v3/all.hpp>
    
    int main() {
        // Background context:
        // Under _GLIBCXX_DEBUG, list returns a list iterator wrapped in a _Safe_iterator
        // whose iterator_category is bidirectional_iterator_tag
        using my_range_type  = std::list< int >;
        using my_iter_type   = decltype( std::begin( std::declval< my_range_type >() ) );
        static_assert(
            std::is_same<
                std::iterator_traits<my_iter_type>::iterator_category,
                std::bidirectional_iterator_tag
            >::value,
            ""
        );
    
        // Background context:
        // range-v3 identifies the _Safe_iterator<...> as SizedIteratorRange
        using rv3_iterator_t = ranges::range_iterator_t< my_range_type >;
        using rv3_sentinel_t = ranges::range_sentinel_t< my_range_type >;
        using rv3_sirc_t     = ranges::sized_iterator_range_concept<rv3_iterator_t,
                                                                    rv3_sentinel_t>;
        ranges::concepts::SizedIteratorRange * my_ptr = rv3_sirc_t();
    
        //  **** PROBLEM HERE *****
        // Fails to compile the '...::take( 3 );' line.
        // I think that's because range-v3 treats _Safe_iterator<...> as a
        // SizedIteratorRange iterator but then cannot subtract one from another
        // (because that's not supported by the underlying list iterator)
        const my_range_type my_values = { 1, 2, 3, 4 };
        const auto my_first_values = my_values | ranges::v3::view::take( 3 );
        std::cerr << *ranges::max_element( my_first_values ) << "\n";
    
        return 0;
    }
    

    Compile command:

    g++ -std=c++11 -isystem range-v3/include -ftemplate-backtrace-limit=0 rv3_safe_iter_prob.cpp
    

    (also works with -std=c++14; -ftemplate-backtrace-limit=0 avoids clipped messages)

    opened by tonyelewis 28
  • Find a better name for iterator_range

    Find a better name for iterator_range

    Especially when dealing with old/current interfaces you sometimes have a pair of begin/end iterators you have to deal with. It would be great if I could e.g. view::all_between(it, it_end) | view::join | ...

    Does something like this exist and I just overlooked it? If not, do you agree, it would be nice to have? I could look into it and maybe create a PR...

    opened by h-2 26
  • Uniform namespace conventions between Meta and Range/utility/Meta

    Uniform namespace conventions between Meta and Range/utility/Meta

    I'm trying to make Range work bootstrapping Meta into it first, instead of having (maintaining) both copies of the same library. My idea is to make this change least intrusive possible. Given the current meta.hpp file in range, what I'm doing is:

    #if defined(BIICODE)
    #include <meta/meta.hpp>
    #else
    #include <type_traits>
    #include <initializer_list>
    #include <range/v3/utility/nullptr_v.hpp>
    #include <range/v3/utility/static_const.hpp>
    ...
    

    The dependency works perfectly, but I'm not able to compile since Meta and Range are using different namespaces to declare/define Meta features. Relying on sorcery like #include inside a nested namespace is not a solution for me, neither for you I guess (Ignoring that trick would potentially generate name issues with STL things etc).

    Maybe we can study the effort neccesary to unify both naming conventions.

    opened by Manu343726 24
  • Add view::shared

    Add view::shared

    Description: view::shared was designed to allow the construction of temporary containers in the middle of the range pipeline (such as inside view::for_each or view::transform). Such temporary containers can be afterwards used in the remaining part of the pipeline, without the danger of dangling references. view::shared allows elegant constructions, which would be otherwise very difficult to express and the code readability would be significantly degraded (see examples at the end of this description).

    Internally, view::shared stores only std::shared_ptr to the underlying range, and therefore construction, destruction, copying and moving of view::shared are still O(1)-time operations, except for the last destruction, which can take up to O(N) time. The linear complexity of the last destruction, however, can be amortized with the time needed to construct the underlying container.

    It can be constructed:

    • from an rvalue reference of a range
    • from std::shared_ptr of a range
    • as a function
    • as a range pipeline element

    Example 1: Apply a transformation function returning a vector, to a range of integers, and flatten the result.

    std::vector<int> foo(int a);
    auto rng =
        view::iota(1)
      | view::transform(foo)
      | view::transform(view::shared)
      | view::join;
    

    Example 2: Build a range which repeats the numbers from a pre-specified vector, but in each epoch, the numbers are randomly shuffled (as is usual e.g., for the training data in machine learning).

    std::vector<int> base{5, 1, 8};
    auto rng =
        view::repeat(base)
      | view::for_each([](std::vector<int> tmp) {
            return std::move(tmp)
                 | action::shuffle(gen)
                 | view::shared;
        });
    

    Stand-alone views: Naturally, view::shared can be used to encapsulate the initial data structure inside a view without bothering with the structure's scope. Therefore, it allows the creation of stand-alone views inside of functions:

    auto build_view()
    {
        std::vector<int> base{5, 1, 8};
        return std::move(base) | view::shared | ...
    }
    
    opened by FloopCZ 23
  • linear_distribute improvement

    linear_distribute improvement

    linear_distribute has an unexpected behavior for integral values when number of values to be calculated is greater than distance between from and to. My expectation was similar to numpy behavior where calculated values are "evenly" distributed with integral precision.

    Expectation:

    linear_distribute(0, 10, 20) == linear_distribute(0.0, 10.0, 20) | transform(convert_to<int>{})
    

    Current implementation:

    linear_distribute(0, 3, 7)     = [0, 0,   0, 0,   1, 2,   3]
    linear_distribute(0.0, 3.0, 7) = [0, 0.5, 1, 1.5, 2, 2.5, 3]
    

    Improved implementation:

    linear_distribute(0, 3, 7)     = [0, 0,   1, 1,   2, 2,   3]
    linear_distribute(0.0, 3.0, 7) = [0, 0.5, 1, 1.5, 2, 2.5, 3]
    
    opened by MaciejPatro 0
  • overly constrained `joinable_with_range`

    overly constrained `joinable_with_range`

    The concept joinable_with_range requires the element of the ranges to be semiregular. I can't find any reason why it has to be seriregular. https://github.com/ericniebler/range-v3/blob/83783f578e0e6666d68a3bf17b0038a80e62530e/include/range/v3/view/join.hpp#L523

    One possible reason is one of the join overloads that takes an element and the implementation will create a single_view, and long time ago single_view required semiregular.

    opened by huixie90 0
  • Why Is Custom contiguous_iterator_tag Is Used?

    Why Is Custom contiguous_iterator_tag Is Used?

        using input_iterator_tag = std::input_iterator_tag;
        using forward_iterator_tag  = std::forward_iterator_tag;
        using bidirectional_iterator_tag = std::bidirectional_iterator_tag;
        using random_access_iterator_tag = std::random_access_iterator_tag;
    
        struct contiguous_iterator_tag : std::random_access_iterator_tag
        {};
    
    

    The code above is from iterator/traits.hpp. Is custom tag used to support C++17 standard? The custom tag breaks STL interop (for example std::string_view) so, may be better drop C++17 support and steal contiguous_iterator_tag from STL? @ericniebler what do you think?

    opened by sergegers 1
  • [FIX] circular swap concept

    [FIX] circular swap concept

    Fixes https://github.com/ericniebler/range-v3/issues/1672

    I'm not too sure about whether the replacement is correct (CI seems OK).

    Type is ranges::any, and we check for swappable. In the end, we want to use the any constructor with copyable restriction.

    copyable requires movable, and movable requires swappable

    opened by eseiler 0
  • adds `ranges::contains_subrange`

    adds `ranges::contains_subrange`

    P2302 proposes an find-based contains (called contains) and a search-based contains (called contains_subrange). The former is used to determine if an element exists in a range, while the latter is used to determine whether or not a needle range is a subrange of a haystack range.

    opened by cjdb 0
  • concat of views over move-only type doesn’t compile

    concat of views over move-only type doesn’t compile

    Please consider the following example where I’m trying to concatenate two views over a move-only type:

    auto v = views::ints(0, 4) |
             views::transform([](int i) { return std::make_unique<int>(i); });
    auto w = views::ints(4, 8) |
             views::transform([](int i) { return std::make_unique<int>(i); });
    auto x = views::concat(v, w) | to<std::vector>();
    

    Unfortunately, this doesn’t compile for me and I can’t make much sense of the error message (see https://godbolt.org/z/TcoP8djnz).

    If I change make_unique to make_shared, i.e. use a copyable type, the code compiles. Evaluating the views before concat also works:

    auto v = views::ints(0, 4) |
             views::transform([](int i) { return std::make_unique<int>(i); }) |
             to<std::vector>();
    auto w = views::ints(4, 8) |
             views::transform([](int i) { return std::make_unique<int>(i); }) |
             to<std::vector>();
    auto x = views::concat(v | views::move, w | views::move) | to<std::vector>();
    

    I’ve raised this before as a question on StackOverflow where a user suggested that this might be a bug in range-v3.

    Is this a bug? Or am I doing something wrong here?

    opened by MichaelWJung 0
  • concepts.hpp:455:5: error: satisfaction of atomic constraint ‘requires(T& t, T& u) {(concepts::<unnamed>::swap)(t, u);} [with T = T]’ depends on itself

    concepts.hpp:455:5: error: satisfaction of atomic constraint ‘requires(T& t, T& u) {(concepts::::swap)(t, u);} [with T = T]’ depends on itself

    Fail to build autotests of the latest release v0.11.0 with GCC 11.2.0. Could you please take a look? A thousand thanks in advance.

    [  0%] Building CXX object CMakeFiles/test.range.v3.headers.dir/headers/range/v3/utility.cpp.o
    In file included from /build/range-v3/include/range/v3/utility/any.hpp:23,
                     from /build/range-v3/include/range/v3/utility.hpp:17,
                     from /build/range-v3/obj-x86_64-linux-gnu/headers/range/v3/utility.cpp:1:
    /build/range-v3/include/concepts/swap.hpp: In substitution of ‘template<class TRef, class T>  requires (copyable<T>) && !(same_as<T, ranges::any>) ranges::any::any(TRef&&) [with TRef = std::default_delete<ranges::any::interface>&; T = std::default_delete<ranges::any::interface>]’:
    /build/range-v3/include/concepts/swap.hpp:179:22:   required by substitution of ‘template<class T, class U> decltype (concepts::adl_swap_detail::swap(declval<T>(), declval<U>())) concepts::adl_swap_detail::try_adl_swap_(int) [with T = std::default_delete<ranges::any::interface>&; U = std::default_delete<ranges::any::interface>&]’
    /build/range-v3/include/concepts/swap.hpp:186:14:   required from ‘constexpr const bool concepts::adl_swap_detail::is_adl_swappable_v<std::default_delete<ranges::any::interface>&>’
    /build/range-v3/include/concepts/swap.hpp:205:18:   required by substitution of ‘template<class T> constexpr meta::if_c<((! is_adl_swappable_v<T&>) && is_movable_v<T>)> concepts::adl_swap_detail::swap_fn::operator()(T&, T&) const [with T = std::default_delete<ranges::any::interface>]’
    /build/range-v3/include/concepts/concepts.hpp:937:9:   required by substitution of ‘template<class TRef, class T>  requires (copyable<T>) && !(same_as<T, ranges::any>) ranges::any::any(TRef&&) [with TRef = std::default_delete<ranges::any::interface>&; T = std::default_delete<ranges::any::interface>]’
    /usr/include/c++/11/type_traits:2700:31:   required by substitution of ‘template<class _Tp, class> static std::true_type std::__swappable_details::__do_is_swappable_impl::__test(int) [with _Tp = std::default_delete<ranges::any::interface>; <template-parameter-1-2> = <missing>]’
    /usr/include/c++/11/type_traits:2724:35:   required from ‘struct std::__is_swappable_impl<std::default_delete<ranges::any::interface> >’
    /usr/include/c++/11/type_traits:2735:12:   required from ‘struct std::__is_swappable<std::default_delete<ranges::any::interface> >’
    /usr/include/c++/11/bits/unique_ptr.h:463:37:   required from ‘void std::unique_ptr<_Tp, _Dp>::swap(std::unique_ptr<_Tp, _Dp>&) [with _Tp = ranges::any::interface; _Dp = std::default_delete<ranges::any::interface>]’
    /build/range-v3/include/range/v3/utility/any.hpp:163:22:   required from here
    /build/range-v3/include/concepts/concepts.hpp:937:9:   required for the satisfaction of ‘swappable__requires_<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:943:21:   required for the satisfaction of ‘swappable<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:1099:21:   required for the satisfaction of ‘movable<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:1110:21:   required for the satisfaction of ‘copyable<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:937:9:   in requirements with ‘T& t’, ‘T& u’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:455:5: error: satisfaction of atomic constraint ‘requires(T& t, T& u) {(concepts::<unnamed>::swap)(t, u);} [with T = S]’ depends on itself
      455 |     requires(__VA_ARGS__) CPP_REQUIRES_AUX_
          |     ^
    /build/range-v3/include/concepts/concepts.hpp:66:30: note: in expansion of macro ‘CPP_REQUIRES_requires’
       66 | #define CPP_PP_CAT_(X, ...)  X ## __VA_ARGS__
          |                              ^
    /build/range-v3/include/concepts/concepts.hpp:67:30: note: in expansion of macro ‘CPP_PP_CAT_’
       67 | #define CPP_PP_CAT(X, ...)   CPP_PP_CAT_(X, __VA_ARGS__)
          |                              ^~~~~~~~~~~
    /build/range-v3/include/concepts/concepts.hpp:448:5: note: in expansion of macro ‘CPP_PP_CAT’
      448 |     CPP_PP_CAT(CPP_REQUIRES_, REQS)
          |     ^~~~~~~~~~
    /build/range-v3/include/concepts/concepts.hpp:937:9: note: in expansion of macro ‘CPP_requires’
      937 |         CPP_requires(swappable_,
          |         ^~~~~~~~~~~~
    make[2]: *** [CMakeFiles/test.range.v3.headers.dir/build.make:2543: CMakeFiles/test.range.v3.headers.dir/headers/range/v3/utility.cpp.o] Ошибка 1
    [  0%] Building CXX object CMakeFiles/test.range.v3.headers.dir/headers/range/v3/utility/any.cpp.o
    In file included from /build/range-v3/include/range/v3/utility/any.hpp:23,
                     from /build/range-v3/obj-x86_64-linux-gnu/headers/range/v3/utility/any.cpp:1:
    /build/range-v3/include/concepts/swap.hpp: In substitution of ‘template<class TRef, class T>  requires (copyable<T>) && !(same_as<T, ranges::any>) ranges::any::any(TRef&&) [with TRef = std::default_delete<ranges::any::interface>&; T = std::default_delete<ranges::any::interface>]’:
    /build/range-v3/include/concepts/swap.hpp:179:22:   required by substitution of ‘template<class T, class U> decltype (concepts::adl_swap_detail::swap(declval<T>(), declval<U>())) concepts::adl_swap_detail::try_adl_swap_(int) [with T = std::default_delete<ranges::any::interface>&; U = std::default_delete<ranges::any::interface>&]’
    /build/range-v3/include/concepts/swap.hpp:186:14:   required from ‘constexpr const bool concepts::adl_swap_detail::is_adl_swappable_v<std::default_delete<ranges::any::interface>&>’
    /build/range-v3/include/concepts/swap.hpp:205:18:   required by substitution of ‘template<class T> constexpr meta::if_c<((! is_adl_swappable_v<T&>) && is_movable_v<T>)> concepts::adl_swap_detail::swap_fn::operator()(T&, T&) const [with T = std::default_delete<ranges::any::interface>]’
    /build/range-v3/include/concepts/concepts.hpp:937:9:   required by substitution of ‘template<class TRef, class T>  requires (copyable<T>) && !(same_as<T, ranges::any>) ranges::any::any(TRef&&) [with TRef = std::default_delete<ranges::any::interface>&; T = std::default_delete<ranges::any::interface>]’
    /usr/include/c++/11/type_traits:2700:31:   required by substitution of ‘template<class _Tp, class> static std::true_type std::__swappable_details::__do_is_swappable_impl::__test(int) [with _Tp = std::default_delete<ranges::any::interface>; <template-parameter-1-2> = <missing>]’
    /usr/include/c++/11/type_traits:2724:35:   required from ‘struct std::__is_swappable_impl<std::default_delete<ranges::any::interface> >’
    /usr/include/c++/11/type_traits:2735:12:   required from ‘struct std::__is_swappable<std::default_delete<ranges::any::interface> >’
    /usr/include/c++/11/bits/unique_ptr.h:463:37:   required from ‘void std::unique_ptr<_Tp, _Dp>::swap(std::unique_ptr<_Tp, _Dp>&) [with _Tp = ranges::any::interface; _Dp = std::default_delete<ranges::any::interface>]’
    /build/range-v3/include/range/v3/utility/any.hpp:163:22:   required from here
    /build/range-v3/include/concepts/concepts.hpp:937:9:   required for the satisfaction of ‘swappable__requires_<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:943:21:   required for the satisfaction of ‘swappable<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:1099:21:   required for the satisfaction of ‘movable<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:1110:21:   required for the satisfaction of ‘copyable<T>’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:937:9:   in requirements with ‘T& t’, ‘T& u’ [with T = std::default_delete<ranges::any::interface>]
    /build/range-v3/include/concepts/concepts.hpp:455:5: error: satisfaction of atomic constraint ‘requires(T& t, T& u) {(concepts::<unnamed>::swap)(t, u);} [with T = T]’ depends on itself
      455 |     requires(__VA_ARGS__) CPP_REQUIRES_AUX_
          |     ^
    /build/range-v3/include/concepts/concepts.hpp:66:30: note: in expansion of macro ‘CPP_REQUIRES_requires’
       66 | #define CPP_PP_CAT_(X, ...)  X ## __VA_ARGS__
          |                              ^
    /build/range-v3/include/concepts/concepts.hpp:67:30: note: in expansion of macro ‘CPP_PP_CAT_’
       67 | #define CPP_PP_CAT(X, ...)   CPP_PP_CAT_(X, __VA_ARGS__)
          |                              ^~~~~~~~~~~
    /build/range-v3/include/concepts/concepts.hpp:448:5: note: in expansion of macro ‘CPP_PP_CAT’
      448 |     CPP_PP_CAT(CPP_REQUIRES_, REQS)
          |     ^~~~~~~~~~
    /build/range-v3/include/concepts/concepts.hpp:937:9: note: in expansion of macro ‘CPP_requires’
      937 |         CPP_requires(swappable_,
          |         ^~~~~~~~~~~~
    make[2]: *** [CMakeFiles/test.range.v3.headers.dir/build.make:2571: CMakeFiles/test.range.v3.headers.dir/headers/range/v3/utility/any.cpp.o] Ошибка 1
    

    You will find full build log at https://salsa.debian.org/debian/range-v3/-/jobs/2065679

    opened by mymedia2 0
  • Fixing reverse_iterator's value_type.

    Fixing reverse_iterator's value_type.

    reverse_iterator doesn't properly forward value_type, so in cases where the underlying range's value_type is not simply uncvref_t<reference>, views::reverse will end up destroying that information - which is especially problematic if you're reverseing a zip and then do some work that relies on the value_type not having reference semantics.

    opened by BRevzin 0
  • Integrate gsl::span for usage with MSVC and C++17

    Integrate gsl::span for usage with MSVC and C++17

    opened by bratwurstroll 0
  • Updated fold to P2322R5 (no projections, rename)

    Updated fold to P2322R5 (no projections, rename)

    Per LEWG telecon, renaming foldl/foldr to fold_left/fold_right and the *1 suffix to _first for the left fold and _last for the right fold. Names not finalized yet, but seem more likely to be the final names than foldl/foldl1/foldr/foldr1.

    Also removing the projections. First, they were implemented incorrectly anyway. Second, for the variants with no initial value, the projection doesn't really work. This is explained in P2322R5 (see here until that one is published).

    opened by BRevzin 0
Releases(0.11.0)
  • 0.11.0(Aug 6, 2020)

    Released: August 6, 2020

    IMPORTANT: This release removes the heuristic that tries to guess whether a range type is a "view" (lightweight, non-owning range), in accordance with the C++20. This is a potentially source-breaking change. Code that previously used an rvalue range as the start of a pipeline could stop compiling if the range library is not explicitly told that that range type is a view. To override the new default, please specialize the ranges::enable_view<R> Boolean variable template.

    IMPORTANT: This release removes the implicit conversion from views to containers. To construct a container from an arbitrary range, you must now explicitly use ranges::to. For example, the following code no longer works:

    std::vector<int> is = ranges::views::ints(0, 10); // ERROR: no conversion
    

    Instead, please write this as:

    auto is = ranges::views::ints(0, 10) | ranges::to<std::vector>; // OK
    

    ranges::to lives in header <range/v3/range/conversion.hpp>

    IMPORTANT: This release drops support for llvm-3.9.

    Changes:

    • NEW: A new concepts portability layer that short-circuits atomic constraints in requires clauses for better compile times when emulating concepts.
    • NEW: Restored support for MSVC in /std:c++17 mode, and for MSVC's default preprocessor.
    • Remove the implicit conversion from views to containers.
    • Rename the following entities to be consistent with C++20's std::ranges support:
      • safe_range<R> -> borrowed_range<R>
      • enable_safe_range<R> -> enable_borrowed_range<R>
      • safe_iterator_t<R> -> borrowed_iterator_t<R>
      • safe_subrange_t<R> -> borrowed_subrange_t<R>
      • readable_traits<I> -> indirectly_readable_traits<I>
      • readable<I> -> indirectly_readable<I>
      • writable<I> -> indirectly_writable<I>
    • Added the following to the ranges::cpp20 namespace:
      • Algorithm for_each_n
      • Algorithm sample
      • Class view_base
      • Alias views::all_t
    • Type __int128 is recognized as "integer-like".
    • Adds concepts three_way_comparable[_with] when <=> is supported.
    • Adds concepts partially_ordered[_with].
    • Better conformance with C++20's use of the boolean-testable concept.
    • Support C++20 coroutines.
    • Honor CMake's CMAKE_CXX_STANDARD variable.
    • A fix for the cardinality of views::zip[_with] (#1486).
    • Add view_interface::data() member function.
    • Add necessary specializations for std::basic_common_reference and std::common_type.
    • Numerous workarounds for MSVC.
    • Various CMake fixes and improvements.
    • drop_while_view is not a sized_range.
    • Added support for Wind River Systems.
    • Bug fixes to views::group_by (#1393).
    • common_[reference|type] of common_[tuple|pair] now yields a common_[tuple|pair] instead of a std::[tuple|pair] (#1422).
    • Avoid UB when currying an lvalue in some views and actions (#1320).

    Credits: I would like to thank the following people who contributed to this release (in no particular order): Christopher Di Bella, @marehr, Casey Carter, Dvir Yitzchaki, Justin Riddell, Johel Ernesto Guerrero Peña, Barry Revzin, Kamlesh Kumar, and Vincas Dargis.

    Source code(tar.gz)
    Source code(zip)
  • 0.10.0(Dec 7, 2019)

    Released: Dec 6, 2019.

    IMPORTANT: Before upgrading, please note that several older compiler versions and build configurations are no longer supported! In particular, MSVC now needs /std:c++latest.

    ALSO: When taking a dependency on the range-v3, meta, or concepts libraries via CMake, please now use the namespace qualified target names:

    • range-v3::range-v3
    • range-v3::meta
    • range-v3::concepts

    Changes:

    • NEW: Rewritten concepts portability layer with simpler macros for better diagnostics.
    • NEW: The views::cache1 view caches the most recent value in the range. This can help avoid reevaluation of transformations in complex view pipelines.
    • NEW: ranges::contains algorithm.
    • NEW: enable_safe_range trait for opting in to the forwarding-range concept. These are ranges whose iterators remain valid even after the range itself has been destroyed; e.g., std::string_view and ranges::subrange.
    • The readable concept has changed such that types that are not indirectly readable with operator* (_e.g., std::optional) no longer satisfy that concept.
    • Using views::join to join a range of xvalue ranges works again.
    • The following range access primitives no longer accept temporary containers (i.e., they refuse to return references known to be dangling):
      • range::front
      • range::back
      • range::at
      • range::index
    • views::concat with a single argument now simply returns its argument.
    • ranges::ostream_iterator<T> now coerces arguments to T before inserting them into the wrapped ostream.
    • Smaller iterators for views::transform and views::take_while.
    • actions::split and actions::split_when now support partial application and pipelining (#1085).
    • views::group_by and its iterator both get a .base() member to access the underlying range and iterator, respectively.
    • Improved diagnostics with clang.
    • Assorted bug fixes and compiler work-arounds: #284, #491, #499, #871, #1022, #1043, #1081, #1085, #1101, #1116, #1296, #1305, and #1335.

    Many thanks to GitHub users @CaseyCarter, @morinmorin, @h-2, @MichaelWJung, @johelegp, @marehr, @alkino, @xuning97, @BRevzin, and @mpusz for their contributions.

    Source code(tar.gz)
    Source code(zip)
  • 0.9.0(Aug 25, 2019)

    Released: Aug 26, 2019.

    Bring many interfaces into sync with the C++20 draft.

    • NEW: An improved concepts portability layer with macros that use C++20 concepts when the compiler supports them.

    • NEW: An improved directory structure that keeps disjoint parts of the library -- iterators, ranges, algorithms, actions, views, functional programming support, and general utilities -- physically separate.

    • NEW: A RANGES_DEEP_STL_INTEGRATION configuration option that makes your STL implementation default to structural conformance to infer iterator category, as in C++20. Applies to libc++, libstdc++, and MSVC's Standard Library.

    • NEW: A ranges::cpp20 namespace that contains all the functionality of C++20's std::ranges namespace.

    • All concept names have been given standard_case (renamed from PascalCase) and have been harmonized with the C++20 draft.

    • The following range access customization points no longer accept rvalue ranges by default:

      • ranges::begin
      • ranges::end
      • ranges::rbegin
      • ranges::rend
      • ranges::cbegin
      • ranges::cend
      • ranges::crbegin
      • ranges::crend
      • ranges::data
      • ranges::cdata
    • Iterators may specify an iterator_concept type alias in addition to iterator_category -- either as a nested type or as a member of a std::iterator_traits specialization -- to denote conformance to the C++20 iterator concepts as distinct from the C++98 iterator requirements. (See P1037 "Deep Integration of the Ranges TS" for more information.)

    • The ranges::value_type trait has been renamed to readable_traits.

    • The ranges::difference_type trait has been renamed to incrementable_traits.

    • The ranges::iterator_category trait has been deprecated. Specialize std::iterator_traits to non-intrusively specify an iterator's category and (optionally) concept.

    • Rename the ranges::view namespace to ranges::views and ranges::action to ranges::actions (with deprecated namespace aliases for migration).

    • Rename view::bounded to views::common.

    • Rename unreachable to unreachable_sentinel_t.

    • Change dangling from a class template that wraps an iterator to a class that acts as a placeholder for an iterator that would otherwise dangle.

    • Implement C++20's subrange as a view that wraps an iterator/sentinel pair; deprecate iterator_range.

    • Deprecate implicit conversion from view types to containers; rename ranges::to_ to ranges::to and extend it to support converting a range-of-ranges to a container-of-containers.

    • Deprecate the ranges::v3 inline versioning namespace.

    • The following views have had minor changes to bring them into conformance with the C++20 working draft:

      • join_view
      • single_view
      • empty_view
      • split_view
      • reverse_view
      • all_view
      • take_view
      • iota_view

      `iota_view`, in particular, is given a user-defined `difference_type` that avoids integer overflow.

    • New names for the iterator and range type aliases:

      | Old Name | New Name | |-------------------------------|-----------------------------| | value_type_t | iter_value_t | | reference_t | iter_reference_t | | difference_type_t | iter_difference_t | | size_type_t | deprecated | | rvalue_reference_t | iter_rvalue_reference_t | | range_value_type_t | range_value_t | | range_difference_type_t | range_difference_t | | range_size_type_t | range_size_t |

    Source code(tar.gz)
    Source code(zip)
  • 0.5.0(Apr 30, 2019)

    • NEW: MSVC support, from @CaseyCarter :tada: (See the docs for the list of supported compilers.)
    • NEW: view::enumerate, from @MikeGitb
    • NEW: view::addressof, from @tower120
    • NEW: unstable_remove_if algorithm and action, from @tower120
    • NEW: adjacent_remove_if algorithm and action, from @tower120
    • NEW: ostream_joiner, from @sv1990
    • view::drop_while and view::take_while get projection support, from @mrpi
    • view::filter and view::remove_if get projection support, from @mrpi
    • view::unique accepts optional comparison operator, from @tete17
    • action::slice supports sliding from the end, from @tete17
    • Support coroutines on MSVC, from @CaseyCarter
    • Faster view::generate_n, from GitHub user @tower120
    • Improved aligned new detection for libc++ on iOS, from @mtak-
    • Various CMake improvements, from @johelegp
    • view_adaptor supports basic_iterator-style mixins, from @tower120
    • Fix ranges::advance for random-access iterators for n==0, from @tower120
    • Bugs fixed: #755, #759, #942, #946, #952, #975, #978, #986, #996, #1041, #1047, #1088, #1094, #1107, #1129
    Source code(tar.gz)
    Source code(zip)
  • 0.4.0(Oct 18, 2018)

    0.4.0 Oct 18, 2018

    • Minor interface-breaking changes:
      • single_view returns by const & (see #817).
      • reverse_view of a non-Sized, non-Bounded RandomAccess range (eg., a null-terminated string) no longer satisfies SizedRange.
      • The generate and generate_n views now return the generated values by xvalue reference (T &&) to the value cached within the view (see #905).
      • Views no longer prefer returning constant iterators when they can; some views have different constant and mutable iterators.
    • Enhancements:
      • Views can successfully adapt other views that have different constant and mutable iterators.
      • The single, empty, and reverse views are much closer to the versions as specified in P0896.
    • Bug fixes:
      • "single_view should not copy the value" #817.
      • "Calling back() on strided range does not return the correct last value in range" #901.
      • "generate(foo) | take(n) calls foo n+1 times" #819.
      • "generate seems broken with move-only return types" #905.
      • "Unexpected behavior in generate with return by reference" #807.
      • "Inconsistent behaviour of ranges::distance with ranges::view::zip using infinite views." #783.
      • "Infinite loop when using ranges::view::cycle with an infinite range" #780.
      • "Composing ranges::view::cycle with ranges::view::slice" #778.
      • "cartesian_product view, now with moar bugs." #919.
    Source code(tar.gz)
    Source code(zip)
  • 0.3.7(Sep 20, 2018)

    0.3.7 Sept 19, 2018

    • Improved support for clang-cl (thanks to @CaseyCarter).
    • Fix for any_view<T, category::sized | category::input> (see #869).
    • Fix iter_move of a ranges::reverse_iterator (see #888).
    • Fix move_sentinel comparisons (see #889).
    • Avoid ambiguity created by boost::advance and std::advance (see #893).
    Source code(tar.gz)
    Source code(zip)
  • 0.3.6(May 15, 2018)

    • 0.3.6 May 15, 2018
      • NEW: view::exclusive_scan (thanks to GitHub user @mitsutaka-takeda).
      • All views get non-const overloads of .empty() and .size() (see ericniebler/stl2#793).
      • Upgrade Conan support for conan 1.0.
      • subspan interface tweaks.
      • Fix bug in view::split (see this stackoverflow question).
      • Fix bug in view::stride (see ericniebler/stl2#805).
      • Fix const-correctness problem in view::chunk (see this stackoverflow question).
      • Replace uses of ranges::result_of with ranges::invoke_result.
      • Fix potential buffer overrun of view::drop over RandomAccessRanges.
      • Lots of view::cartesian_product fixes (see ericniebler/stl2#820, ericniebler/stl2#823).
      • Work around gcc-8 regression regarding volatile std::initializer_lists (see ericniebler/stl2#826).
      • Fix const-correctness problem of view::take.
    Source code(tar.gz)
    Source code(zip)
  • 0.3.5(Feb 17, 2018)

    0.3.5 February 17, 2018

    • Rvalues may satisfy Writable (see ericniebler/stl2#387).
    • view_interface gets a bounds-checking at method.
    • chunk_view works on Input ranges.
    • Fix bug in group_by_view.
    • Improved concept checks for partial_sum numeric algorithm.
    • Define ContiguousIterator concept and contiguous_iterator_tag iterator category tag.
    • Sundry span fixes.
    • action::insert avoids interfering with vector's exponentional growth strategy.
    • Add an experimental shared view for views that need container-like scratch space to do their work.
    • Faster, simpler reverse_view.
    • Rework ranges::reference_wrapper to avoid LWG#2993.
    • Reworked any_view, the type-erased view wrapper.
    • equal algorithm is constexpr in C++14.
    • stride_view no longer needs an atomic data member.
    • const-correct drop_view.
    • adjacent_filter_view supports bidirectional iteration.
    • Massive view_adaptor cleanup to remove the need for a mutable data member holding the adapted view.
    • Fix counting_iterator post-increment bug.
    • tail_view of an empty range is an empty range, not undefined behavior.
    • Various portability fixes for gcc and clang trunk.
    Source code(tar.gz)
    Source code(zip)
  • 0.3.0(Jun 30, 2017)

    0.3.0 June 30, 2017

    • Input views may now be move-only (from @CaseyCarter)
    • Input any_views are now much more efficient (from @CaseyCarter)
    • Better support for systems lacking a working <thread> header (from @CaseyCarter)
    Source code(tar.gz)
    Source code(zip)
  • 0.2.6(Jun 21, 2017)

    0.2.6 2017-06-21

    • Experimental coroutines with ranges::experimental::generator (from @CaseyCarter)
    • ranges::optional now behaves like std::optional (from @CaseyCarter)
    • Extensive bug fixes with Input ranges (from @CaseyCarter)
    Source code(tar.gz)
    Source code(zip)
  • 0.2.5(May 16, 2017)

    • view::chunk works on Input ranges (from @CaseyCarter)
    • for_each_n algorithm (from @khlebnikov)
    • Portability fixes for MinGW, clang-3.6 and -3.7, and gcc-7; and cmake 3.0
    Source code(tar.gz)
    Source code(zip)
  • 0.2.4(Apr 13, 2017)

    0.2.4 April 12, 2017 Fix the following bug:

    • action::stable_sort of vector broken on Clang 3.8.1 since ~last Xmas (ericniebler/range-v3#632).
    Source code(tar.gz)
    Source code(zip)
  • 0.2.3(Apr 4, 2017)

  • 0.2.2(Mar 30, 2017)

    New in this release:

    • view::linear_distribute(from,to,n) - A view of n elements between from and to, distributed evenly.
    • view::indices(n) - A view of the indices [0,1,2...n-1].
    • view::closed_indices(n) - A view of the indices [0,1,2...n].

    This release also deprecates view::ints(n) as confusing to new users.

    Source code(tar.gz)
    Source code(zip)
  • 0.2.1(Mar 22, 2017)

  • 0.2.0(Mar 13, 2017)

    Bring many interfaces into sync with the Ranges TS.

    • Many interfaces are simply renamed. The following table shows the old names and the new. (All names are in the ranges::v3 namespace.)

      | Old Name | New Name | |-------------------------------|---------------------------| | indirect_swap | iter_swap | | indirect_move | iter_move | | iterator_value_t | value_type_t | | iterator_reference_t | reference_t | | iterator_difference_t | difference_type_t | | iterator_size_t | size_type_t | | iterator_rvalue_reference_t | rvalue_reference_t | | iterator_common_reference_t | iter_common_reference_t | | range_value_t | range_value_type_t | | range_difference_t | range_difference_type_t | | range_size_t | range_size_type_t | | range_iterator_t | iterator_t | | range_sentinel_t | sentinel_t |

    • common_iterator now requires that its two types (Iterator and Sentinel) are different. Use common_iterator_t<I, S> to get the old behavior (i.e., if the two types are the same, it is an alias for I; otherwise, it is common_iterator<I, S>).

    • The following iterator adaptors now work with iterators that return proxies from their postfix increment operator (i.e., operator++(int)):

      • common_iterator
      • counted_iterator
    • The following customization points are now implemented per the Ranges TS spec and will no longer find the associated unconstrained overload in namespace std:::

      • ranges::begin
      • ranges::end
      • ranges::size
      • ranges::swap
      • ranges::iter_swap

      (In practice, this has very little effect but it may effect overloading in rare situations.)

    • ranges::is_swappable now only takes one template parameter. The new ranges::is_swappable_with<T, U> tests whether T and U are swappable. ranges::is_swappable<T> is equivalent to ranges::is_swappable_with<T &, T &>.

    • The following object concepts have changed to conform with the Ranges TS specification, and approved changes (see P0547):

      • Destructible
      • Constructible
      • DefaultConstructible
      • MoveConstructible
      • CopyConstructible
      • Movable
      • Assignable
    • The View concept is no longer satisfied by reference types.

    • is_view is now called enable_view

    • The syntax for defining a concept has changed slightly. See utility/iterator_concepts.hpp for examples.

    This release drops support for gcc 4.8.

    Source code(tar.gz)
    Source code(zip)
  • 0.1.1(Mar 13, 2017)

  • 0.1.0(Mar 8, 2017)

Owner
Eric Niebler
Member of the ISO C++ Standardization Committee and principal author of the Ranges TS.
Eric Niebler
Single-header, ranges-compatible generator type built on C++20 coroutines

generator Single-header, ranges-compatible generator type built with C++20 coroutines. A generator allows implementing sequence producers which are te

Sy Brand 19 Nov 22, 2021
Ranges that didn't make C++20

ranges Implementations of ranges that didn't make C++20. Coded live on Twitch. Types tl::enumerate_view/tl::views::enumerate A view which lets you ite

Sy Brand 38 Nov 9, 2021
Companion source code for "Programming with C++20 - Concepts, Coroutines, Ranges, and more"

Companion Source Code for "Programming with C++20 - Concepts, Coroutines, Ranges, and more" 1. Edition Code examples This repository contains runnable

Andreas Fertig 28 Nov 30, 2021
An Arduino library which allows you to communicate seamlessly with the full range of u-blox GNSS modules

u-blox makes some incredible GNSS receivers covering everything from low-cost, highly configurable modules such as the SAM-M8Q all the way up to the surveyor grade ZED-F9P with precision of the diameter of a dime.

SparkFun Electronics 67 Nov 24, 2021
RemixDB: A read- and write-optimized concurrent KV store. Fast point and range queries. Extremely low write-amplification.

REMIX and RemixDB The REMIX data structure was introduced in paper "REMIX: Efficient Range Query for LSM-trees", FAST'21. This repository maintains a

Xingbo Wu 50 Nov 18, 2021
An efficient, composable design pattern for range processing

Transrangers An efficient, composable design pattern for range processing. Intro Pull-based approach Push-based approach Transrangers Performance Tran

null 90 Nov 18, 2021
ZTE Nubia Z17 (codenamed "nx563j") is a high-range smartphone from Nubia.

ZTE Nubia Z17 (codenamed "nx563j") is a high-range smartphone from Nubia. It was released in June 2017.

null 2 Oct 25, 2021
Dynamic array supporting Range Minimum Queries

dynamic-RMQ Dynamic array supporting Range Minimum Queries. Data structure that represent a dynamic array supporting Range Minimum Queries. The data s

Massimiliano Rossi 3 Oct 31, 2021
Packages for simulating the Tethys-class Long-Range AUV (LRAUV) from the Monterey Bay Aquarium Research Institute (MBARI).

LRAUV Simulation This repository contains packages for simulating the Tethys-class Long-Range AUV (LRAUV) from the Monterey Bay Aquarium Research Inst

Open Robotics 5 Nov 24, 2021
Playbit System interface defines an OS-like computing platform which can be implemented on a wide range of hosts

PlaySys The Playbit System interface PlaySys defines an OS-like computing platform which can be implemented on a wide range of hosts like Linux, BSD,

Playbit 174 Nov 28, 2021
high performance C++20 implementation of std::variant

A minimal compile-time overhead, C++20 implementation of std::variant. Fully standard conforming with a couple of documented differences.

null 22 Dec 2, 2021
A cleaner and more intuitive std::variant alternative

[WIP] ExtendedVariant This single header library is part of my C++ extended standard stdex libraries. Check our my profile for more. Working with C++

pinsrq 3 Jun 13, 2021
std::find simd version

std::find simd version std::find doesn't use simd intrinsics. ( check https://gms.tf/stdfind-and-memchr-optimizations.html ) So i thought simd can mak

SungJinKang 15 Nov 29, 2021
Implementation of the (not yet written) std::experimental::rational proposal.

Rational Implementation of the (not yet written) std::experimental::rational proposal. Getting started Copy include/std/experimental/rational.hpp to y

Ali Can Demiralp 7 Dec 2, 2021
SSD1306 library and simple graphics core library based on Adafruit GFX Library.

Raspberry Pico SSD1306 + GFX Library Based on Adafruit GFX Library https://github.com/adafruit/Adafruit-GFX-Library Usage Hardware Connect your SSD130

Marcin Bober 19 Nov 30, 2021
Libft is an individual project at 42 that requires us to re-create some standard C library functions including some additional ones that can be used later to build a library of useful functions for the rest of the program.

Libft is an individual project at 42 that requires us to re-create some standard C library functions including some additional ones that can be used later to build a library of useful functions for the rest of the program.

Paulo Rafael Ramalho 5 Nov 28, 2021
Samir Teymurov 1 Oct 6, 2021
F Graphics Library (FGL) is a small graphics C++ portable library for LCD displays on embedded systems

F Graphics Library (FGL) Full documentation: fgl.docsforge.com (By Filipe Chagas) F Graphics Library is a C++ library that I created for use in embedd

Filipe Chagas 9 Nov 7, 2021
QtVerbalExpressions - This Qt lib is based off of the C++ VerbalExpressions library. [MIT]

QtVerbalExpressions Qt Regular Expressions made easy This Qt lib is based off of the C++ VerbalExpressions library by whackashoe. Testing if we have a

null 49 Nov 9, 2021