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.

• 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.

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).

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).

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.

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)

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...

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.

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 | ...
}

Taking the distance() of a const-lvalue-reference to a view::remove_if fails to compile under both GCC and Clang because it attempts to calculate a type using ranges::range_difference_t<T>, which fails as illustrated in this example:

#include <range/v3/all.hpp>

int main() {
    int rg[] = { 1, 2, 3, 4, 5 };

    // This     const view::tail      is fine
    const auto const_tail_view        = rg | ranges::view::tail;
    using      const_tail_view_diff_t = ranges::range_difference_t< decltype( const_tail_view ) >;

    // This non-const view::remove_if is fine
          auto even_view              = rg | ranges::view::remove_if( [] (const int &i) { return ( i % 2 == 0 ); } );
    using      even_view_diff_t       = ranges::range_difference_t< decltype( even_view ) >;

    // This     const view::remove_if fails to compile
    const auto const_even_view        = rg | ranges::view::remove_if( [] (const int &i) { return ( i % 2 == 0 ); } );
    using      const_even_view_diff_t = ranges::range_difference_t< decltype( const_even_view ) >;

    return 0;
}

My understanding is that this attempts to compute the type of begin(std::declval<T&>()), which leads to a failed instantiation of the begin_fn::operator()() template, which then fails because neither private impl() function can be used.

I've found that this problem occurs with both view::remove_if and view::drop_while but not with:

• view::adjacent_remove_if
• view::chunk
• view::delimit
• view::drop
• view::replace
• view::reverse
• view::slice
• view::stride
• view::tail
• view::take
• view::take
• view::take_exactly
• view::take_while

All kudos go to Louis Dione for writing the CMake scripts of Boost.Hana.

This just adapts his scripts for range-v3; all mistakes introduced are only mine.

• fix missing includes caught by the tests.
• replace # warning with #pragma message because -Werror, -Wpedantic complains that # warning is a language extension (this prevents some new tests from compiling).

Closes #182 .

We have roughly 50% of our GitHub Actions jobs failing the range-v3 tests (using current range-v3 master)

Test project /home/runner/work/SIRF-SuperBuild/SIRF-SuperBuild/build/builds/range-v3/build
        Start   1: range.v3.test.config
  1/257 Test   #1: range.v3.test.config ..............................   Passed    0.00 sec
        Start   2: range.v3.test.constexpr_core
  2/257 Test   #2: range.v3.test.constexpr_core ......................   Passed    0.00 sec
        Start   3: range.v3.test.multiple
  3/257 Test   #3: range.v3.test.multiple ............................   Passed    0.00 sec
        Start   4: range.v3.test.bug474
  4/257 Test   #4: range.v3.test.bug474 ..............................   Passed    0.00 sec
        Start   5: range.v3.test.bug566
  5/257 Test   #5: range.v3.test.bug566 ..............................   Passed    0.00 sec
        Start   6: range.v3.test.bug1322
  6/257 Test   #6: range.v3.test.bug1322 .............................   Passed    0.00 sec
        Start   7: range.v3.test.bug1335
  7/257 Test   #7: range.v3.test.bug1335 .............................   Passed    0.00 sec
        Start   8: range.v3.test.bug1633
  8/257 Test   #8: range.v3.test.bug1633 .............................   Passed    0.00 sec
        Start   9: range.v3.test.bug1729
  9/257 Test   #9: range.v3.test.bug1729 .............................   Passed    0.00 sec
        Start  10: range.v3.test.act.concepts
 10/257 Test  #10: range.v3.test.act.concepts ........................   Passed    0.00 sec
        Start  11: range.v3.test.act.adjacent_remove_if
 11/257 Test  #11: range.v3.test.act.adjacent_remove_if ..............***Exception: Illegal  0.17 sec

        Start  12: range.v3.test.act.drop
 12/257 Test  #12: range.v3.test.act.drop ............................***Exception: Illegal  0.12 sec

        Start  13: range.v3.test.act.drop_while
 13/257 Test  #13: range.v3.test.act.drop_while ......................***Exception: Illegal  0.12 sec

        Start  14: range.v3.test.act.insert
 14/257 Test  #14: range.v3.test.act.insert ..........................***Exception: Illegal  0.13 sec

        Start  15: range.v3.test.act.join
 15/257 Test  #15: range.v3.test.act.join ............................***Exception: Illegal  0.13 sec

        Start  16: range.v3.test.act.push_front
 16/257 Test  #16: range.v3.test.act.push_front ......................***Exception: Illegal  0.12 sec
  etc

Example job: https://github.com/SyneRBI/SIRF-SuperBuild/actions/runs/3684701551/jobs/6234749247#step:10:882. (The previous run all tests passed). There is unfortunately going on much more in that job, so I've tried to cut it down in another branch, but this is hard to do with intermittent failures. In essence though, I cannot see how the "other stuff" affects the range-v3 tests, but what could matter is the following:

• runs on ubuntu-latest, i.e. 22.04
• gcc9
• self-built GTest 1.12.1
• range-v3 master

Anyone any ideas?

Setting a multi-config build generator using the CMake build results in a warning. For example using "Ninja Multi-Config"

See https://cmake.org/cmake/help/latest/variable/CMAKE_CONFIGURATION_TYPES.html

Most specifically the genrator-expressions should be used such as $<CONFIG:Debug>. See https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations

cmake/ranges_env.cmake:82 (message):
1> [CMake]   [range-v3 warning]: unknown build type, defaults to release!

I couldn't find any discussion from a quick search in the issues, but have you considered collecting a result from a range into a std::array?

I understand it's not currently supported since std::array is an aggregate and doesn't have user-defined constructors to accept the ranges/iterators (beyond the obvious reason that for many ranges we can't expect to know the size at compile-time).

That being said, and while I don't know the intricacies of the ranges::to<>, nor do I have extensive knowledge of C++ templates, I toyed around and made it do what I want in a simple case (see on Compiler Explorer).

But I figured it would be good to hear from someone more experienced with the library and its internals.

Hi,

the following concepts cause a cryptic error within the range-v3 v.0.12 library when used with GCC-11 or GCC-12 (linux):

template < typename MapLike >
concept mapping = requires(MapLike m) {
                     // has to be key-value-like to iterate over values and keys only repsectively
                     ranges::views::keys(m);
                     ranges::views::values(m);
                  };

template < typename MapLike, typename KeyType >
concept maps = mapping< MapLike >
               and std::is_convertible_v<    // value type has to be convertible to the Mapped Type
                  decltype(*(ranges::views::keys(std::declval< MapLike >()).begin())),
                  KeyType >;

the error message goes deep within the range-v3 concepts:

/opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/view/all.hpp: In instantiation of 'constexpr auto ranges::views::all_fn::operator()(T&&) const [with T = const Hashmap&]': /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/view/all.hpp:91:35: required by substitution of 'template requires (viewable_range) && (input_range) && (kv_pair_like_<decltype((declval<decltype(ranges::_::begin(static_cast<Rng& ()()noexcept (true)>(nullptr)()))&>)())>) ranges::keys_range_view<decltype (ranges::views::all(declval()))> ranges::views::keys_fn::operator()(Rng&&) const [with Rng = const Hashmap&]'

:15:41: required by substitution of 'template requires maps Hashmap::Hashmap(U&&) [with U = int]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1153:13: required from 'constexpr auto ranges::views::all_fn::operator()(T&&) const [with T = Hashmap&]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/view/all.hpp:91:35: required by substitution of 'template requires (viewable_range) && (input_range) && (kv_pair_like_(nullptr)()))&>)())>) ranges::values_view()))> ranges::views::values_fn::operator()(Rng&&) const [with Rng = Hashmap&]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/functional/invoke.hpp:140:34: required by substitution of 'template constexpr decltype ((F&&)(f)((Args&&(ranges::invoke_fn::operator()::args))...)) ranges::invoke_fn::operator()(F&&, Args&& ...) const [with F = ranges::views::values_fn; Args = {Hashmap&}]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/functional/concepts.hpp:40:5: required by substitution of 'template requires (viewable_range) && (invocable_view_closure) constexpr auto ranges::views::view_closure_base_ns::operator|(Rng&&, ranges::views::view_closure) [with Rng = Hashmap&; ViewFn = ranges::views::values_fn]' :60:36: required from here /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1151:21: required for the satisfaction of 'constructible_from' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1170:9: required for the satisfaction of 'copy_constructible_concept_' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1181:21: required for the satisfaction of 'copy_constructible' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1209:21: required for the satisfaction of 'copyable' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1217:21: required for the satisfaction of 'semiregular' [with T = Hashmap] cc1plus: error: satisfaction of atomic constraint '__is_constructible(T) [with Args = {const I}; T = I]' depends on itself /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1151:21: required for the satisfaction of 'constructible_from' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1170:9: required for the satisfaction of 'copy_constructible_concept_' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1181:21: required for the satisfaction of 'copy_constructible' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1209:21: required for the satisfaction of 'copyable' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1217:21: required for the satisfaction of 'semiregular' [with T = Hashmap] cc1plus: error: satisfaction of atomic constraint '__is_constructible(T) [with Args = {const I}; T = I]' depends on itself

I am using this concept in my code to filter out maps over certain key types (maybe this isn't the best way) and this error has been bugging me for a while now.

Here is a godbolt link to verify the problem on GCC 11/12. It does work e.g. under clang 15: https://godbolt.org/z/dqj1YY9e4

The problem does not exist with std::ranges and GCC, but it does for clang now: https://godbolt.org/z/a88WMe66b

Hi, Reading drop_while page I think it would be handy to be able to tell that we are iterating an already sorted range, when applicable.

Right now, it seems to iterate every elements, whereas it could use a binary search to go faster.