rx-ranges-devel-2.0.0-6.fc45.noarch.rpm

This is a ranges-like library for C++17 that provides zero-overhead list comprehensions with a pipe-like syntax. Standard containers can be filtered, transformed, passed through various algorithms, optimizing to loops that would not be more efficient if written by hand. The goal is to provide the tools to write more readable loops, where the intent of the programmer is clearly communicated to the reader. Mentally simulating loops is a common but error-prone part of reading other people's code, and indeed your own code from 3 months ago. The library makes heavy use of modern C++17 features, so a compliant C++17 compiler is required. Features: - Arbitrary composability. - Constexpr-friendly. - No unnecessary temporary heap allocations (`foo | sort() | to_vector()` only allocates into the resulting container). - Heap allocation minimization: `reserve()` is used on resulting containers, when possible. - Open-ended generators (non-terminating, infinite ranges). - Re-entrancy: A non-rvalue range can be used multiple times in a function. - Compatible with standard containers (anything that supports `std::begin()` and `std::end()`). - Compatible with standard algorithms (implicit conversion to iterator-like objects). - Simple extensibility with custom range adapters. Just implement the `InputRange` faux-concept. - Non-intrusive `operator|`. The ranges `foo | bar | baz` can be expressed as `baz(bar(foo))`, if using `operator|` would introduce ambiguous overloads. - No dependencies beyond the standard library. - Integration with foreign codebases (override hooks for `std::optional`, `std::remove_cvref_t`, assertions, etc.). Can easily be used as a submodule. - Compiler support for all major compilers (GCC, Clang, MSVC). - Zero-overhead, compared to manually written loops in optimized builds. - Header-only, and single-header. Other than usability concerns, these are the main differences from C++20 ranges: - Bidirectional ranges. Ranges can only be consumed linearly in the forward direction. - Random-access ranges. Ranges can only be consumed linearly in the forward direction. - Internally using iterators. The internal iteration objects are modeled with an "enumerator" concept instead (objects that provide `next()`, `get()`, `at_end()`, etc.), which simplifies custom extensions. Implicit, zero-overhead conversion to iterators is provided for compatibility with standard algorithms and the range-based for loop syntax. - Direct access to the data of underlying contiguous ranges (`data()` etc.).