Range-based goodness for C++17

Overview

Standard License Build Status Build status download Try it on godbolt online

NanoRange

NanoRange is a C++17 implementation of the C++20 Ranges proposals (formerly the Ranges TS). It provides SFINAE-based implementations of all the proposed Concepts, and constrained and range-based versions the algorithms in the <algorithm> standard library header.

It is intended for users who want range-based goodness in their C++, but don't want to (or can't) use the full-blown Range-V3. It also aims to provide an easy upgrade path to standard ranges when they arrive.

NanoRange is compatible with all three major C++ compilers, including the latest version of Microsoft Visual C++.

Usage

The easiest way to use NanoRange is to simply download the latest, automatically-generated single-header version and include it in your own sources like any other header. This is currently the recommended way to use the library.

Alternatively, you can clone this repository and use the individual headers in the include/nanorange directory. This may give a slight boost to compile times, although there doesn't seem to be too much difference at present. (In any case, the single-header version is similar to what you'll get when you #include <algorithm> in C++20).

If you use Conan you can find the latest testing package at bintray or just use the nanorange/20191001 package in conan-center.

Finally, if you use vcpkg, you can install the latest version of NanoRange from master using

vcpkg install nanorange --head

Compatibility

NanoRange requires a conforming C++17 compiler, and is tested with GCC 7 and Clang 4.0 and newer. Older versions may work in some cases, but this is not guaranteed.

In addition, NanoRange works with MSVC 2017 version 15.9. Note that the /permissive- switch is required for correct two-phase lookup.

Documentation

There is currently no reference documentation for NanoRange itself, but the Ranges TS on which it is based is partially documented on cppreference.

What it provides

Concepts

NanoRange provides all of the concepts from the ranges papers in the form of constexpr bool variable templates. You can use these to constrain your own templates via std::enable_if, or in if constexpr statements in C++17. For example

template <typename Rng>
void foo(Rng&& rng) {
    if constexpr (nano::RandomAccessRange<Rng>) {
         // do something
    } else if constexpr (nano::BidirectionalRange<Rng>>) {
        // do something else
    } else if constexpr (nano::ForwardRange<Rng>) {
        // do a third thing
    }
}

Iterator adaptors

The One Ranges proposal P0896 adds two new iterator adaptors to the standard library, namely common_iterator and counted_iterator, which are both implemented in NanoRange.

Additionally, P0896 modifies the existing iterator adaptors for compatibility with the new concepts. NanoRange therefore provides drop-in replacements for these, specifically:

  • reverse_iterator
  • front_insert_iterator
  • back_insert_iterator
  • insert_iterator
  • istream_iterator
  • ostream_iterator
  • istreambuf_iterator
  • ostreambuf_iterator

Lastly, NanoRange provides an implementation of subrange from P0896. This can be used to turn an iterator/sentinel pair into in range, or as a span-like view of a subset of another range.

Algorithms

Range-based overloads

NanoRange provides range-based overloads of all the algorithms in <algorithm>. This means that you can finally say

std::vector<int> vec{5, 4, 3, 2, 1};
nano::sort(vec);

and it will Just Work.

Constraint checking

In the existing STL, the algorithm calls are unconstrained. This means that if you pass an argument which doesn't meet the requirements of the function, the compiler will go ahead and try to instantiate the template anyway, usually resulting in pages of error messages with template backtraces for which C++ is infamous.

For example, the following program has an error: a std::list iterator is not random-access, and so doesn't meet the requirements of std::sort():

int main()
{
    std::list<int> list{5, 4, 3, 2, 1};
    std::sort(list.begin(), list.end());
}

Compiling this two-line example with Clang 6.0 results in over 350 lines of error messages!

Calling nano::sort() instead of std::sort() on the other hand means that constraints are checked before the template is instantated. This time, the entire error output is:

example.cpp:9:5: error: no matching function for call to object of type 'const nano::ranges::detail::sort_fn'
    nano::sort(list.begin(), list.end());
    ^~~~~~~~~~
include/nanorange/algorithm/stl/sort.hpp:26:5: note: candidate template ignored: requirement 'RandomAccessIterator<std::__1::__list_iterator<int, void *> >' was not satisfied [with I = std::__1::__list_iterator<int, void *>, Comp = nano::ranges::less<void>]
    operator()(I first, I last, Comp comp = Comp{}) const
    ^
include/nanorange/algorithm/stl/sort.hpp:37:5: note: candidate template ignored: substitution failure [with Rng = std::__1::__list_iterator<int, void *>, Comp = std::__1::__list_iterator<int, void *>]: no matching function for call to object of type 'const nano::ranges::detail::begin_::fn'
    operator()(Rng&& rng, Comp comp = Comp{}) const
    ^
1 error generated.

which makes it clear that the first overload was rejected because list::iterator doesn't meet the requirements of RandomAccessIterator, and the second overload was rejected because list::iterator is not a range (you can't call nano::begin() on it). Much better.

Function objects

The algorithms in NanoRange are implemented as non-template function objects with templated function call operators. This means that you can pass them around without needing to specify template arguments or wrap them in lambdas. For example:

std::vector<std::vector<int>> vec_of_vecs = ...

nano::for_each(vec_of_vecs, nano::sort); // sorts each inner vector

Projections

The fully reimplemented algorithms (see below) offer support for projections. A projection is a unary callable which modifies ("projects") the view of the data that the algorithm sees. Because projections are routed through (an implementation of) std::invoke(), it's possible to use pointers to member functions and pointers to member data as projections. For example:

struct S {
    int i;
    float f;
};

std::vector<S> vec = ...

auto iter = nano::find(vec, 10, &S::i);
// iter points to the first member of vec for which i == 10

constexpr support

In P0896, almost all the algorithms are marked as constexpr (the exceptions being those which can potentially allocate temporary storage). NanoRange fully supports this, meaning the vast majority of algorithms can be called at compile-time. For example

auto sort_copy = [](auto rng) {
    nano::sort(rng);
    return rng;
};

int main()
{
    constexpr std::array a{5, 4, 3, 2, 1};
    constexpr auto b = sort_copy(a);

    static_assert(nano::is_sorted(b));
}

Ranges papers

The Ranges proposals have been consolidated into two main papers:

NanoRange fully implements the first, and implements most of the second (except for Views).

Stability

NanoRange aims to track the various C++20 ranges proposals, and will be updated as new papers are published. As such, there are no API stability guarantees at this time.

Licence

NanoRange is provided under the Boost licence. See LICENSE_1_0.txt for details.

Acknowledgements

Many thanks to the following:

  • Eric Niebler and Casey Carter for the Ranges TS, Range-V3 and CMCSTL2. You guys are awesome.

  • Orson Peters for pdqsort

  • Phil Nash for the fantastic Catch testing framework

  • The editors of cppreference.com for painstakingly detailing the existing requirements of standard library algorithms, and more generally for maintaining the C++ programmer's bible.

Comments
  • Support better CMake install for to use with modern CMake.

    Support better CMake install for to use with modern CMake.

    I just tried this library. It fits my purpose over range-v3 because Eric refuses to support the Intel compiler and I need to support it. I decided to install it using conan. The trouble, minor in the grand scheme of things, but nagging nonetheless, is that one cannot simply use:

    find_package(nanorange REQUIRED)
    target_link_libraries(executable nanorange)
    

    Instead I had to use

    include_directories(${nanorange_INCLUDE_DIRS})
    

    This approach, though it works for my immediate purpose, is not appropriate for libraries that will be used by other targets in other projects.

    I have not fully mastered the latest version of conan, but I have made some install scripts that rely on CMake install configurations that also installs the config version of '.cmake' files. When that is done properly then using

    find_package(nanorange REQUIRED NO_MODULES)
    target_link_libraries(executable nanorange)
    

    with or without conan will do the job. One good thing is that the conan python file of nanorange relies on the cmake install, so the only modifications required should be in the install configuration inside of CMakeLists.txt If I can help, I think it shouldn't take me too long to create a PR for this, based on some of my own libraries.

    opened by FunMiles 12
  • NanoRange failed to build due to errors C2677 C3536 C2893 C2062 C2607 C2672 C2676 with MSVC on windows

    NanoRange failed to build due to errors C2677 C3536 C2893 C2062 C2607 C2672 C2676 with MSVC on windows

    Environment: Windows Server 2016 + VS2017 + NanoRange master branch latest srouce code.

    NanoRange failed to build due to errors C2677 C3536 C2893 C2062 C2607 C2672 C2676 with MSVC on windows. It can be reproduced on master revision 391cc95 . Could you help have a look about this issue? Thanks in advance!

    Steps to reproduce the behavior: 1.Open VS2017 x86 Native tools command tool 2.git clone https://github.com/tcbrindle/nanorange d:\NanoRange\src 3.cd D:\NanoRange 4.mkdir build_x86 && pushd build_x86 5.cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DCMAKE_CXX_STANDARD=17 ..\src
    6.msbuild /m /p:Configuration=Release;Platform=Win32 nanorange.sln /t:Rebuild

    log_x86_build.log

    Actual result: D:\NanoRange\src\test\view\filter_view.cpp(45): error C2677: binary '|': no global operator found which takes type D:\NanoRange\src\test\view\filter_view.cpp(48): error C3536: 'rng': cannot be used before it is initialized [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] D:\NanoRange\src\test\view\filter_view.cpp(48): error C2893: Failed to specialize function template 'unknown-type nano::ranges::detail::begin_::fn::operator ()(T &&) noexcept() const' [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] D:\NanoRange\src\test\view\filter_view.cpp(48): error C2062: type 'unknown-type' unexpected [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] D:\NanoRange\src\test\view\filter_view.cpp(49): error C2607: static assertion failed [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] D:\NanoRange\src\test\view\filter_view.cpp(141): error C2672: 'operator __surrogate_func': no matching overloaded function found [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] D:\NanoRange\src\test\view\filter_view.cpp(135): error C2676: binary '|': 'nano::ranges::iota_view<_Ty,nano::ranges::unreachable_sentinel_t>' does not define this operator or a conversion to a type acceptable to the predefined operator [D:\NanoRange\build_x86\test\test_nanorange.vcxproj]

    opened by spacelg 12
  • rotate() could be faster

    rotate() could be faster

    From #37, it seems that NanoRange's implementation of rotate() is generally faster than libc++ (with a couple of exceptions which they have special-cased) but very much slower than libstdc++.

    Unfortunately the GPL'd code of libstdc++ means we can't just go and "borrow" their implementation, but there is clearly room for improvement.

    enhancement 
    opened by tcbrindle 11
  • Benchmarks. Implement initial benchmark support and write one for rotate.

    Benchmarks. Implement initial benchmark support and write one for rotate.

    Hi, Tristan.

    I sketched out the initial ground for working on rotate, don't know how much effort I will put in, but I believe it's useful as is at this stage.

    Building for benchmarks is hard:

    • first of you need a benchmarking library as a dependency. I tried a few and the only one that really works for me is google benchmark. I just have it installed locally, maybe some of package managers could help, but this is the area where I know absolutely nothing. Same goes for build systems - I just use a script.
    • Ideally you want a binary per benchmark that you run: there is an issue of code alignment - code that doesn't run can affect the performance of your benchmark. (Example of an issue like that: https://github.com/google/benchmark/issues/461). For now I just wrote a script that compiles one binary with clang - see for yourself if you want anything smarter than that.

    NOTE: libc++ and some other projects compile multiple benchmarks in one binary. As far as I understand - performance is not the top priority for you so maybe it's OK. Consider that maybe all together attempt to benchmark is too much of a hassle for your project, if you just want the proof of concept.

    Initial benchmarking results:

    The sad part of this whole experiment so far is that you beat libc++ every-time they don't have a special case. I don't know if this is due to gcd rotate being bad all together or just libc++ one's being bad or even me messing up the benchmarks (though I doubt it) but seems it's like that.

    Here are my measurements: (note - grain of salt - I ran them little less careful then I probably should have - didn't turn off other programs and the laptop was off power, but the results are pretty consistent).

    Special cases are: 1 element and middle.

    --------------------------------------------------------------------------------------------
    Benchmark                                                     Time           CPU Iterations
    --------------------------------------------------------------------------------------------
    rotate_random_access<nano_rotate, int>/1/999               1720 ns       1718 ns     405901
    rotate_random_access<nano_rotate, int>/100/900              743 ns        742 ns     929257
    rotate_random_access<nano_rotate, int>/400/600              785 ns        784 ns     886031
    rotate_random_access<nano_rotate, int>/500/500              419 ns        418 ns    1682919
    rotate_random_access<nano_rotate, int>/700/300             1104 ns       1102 ns     631495
    rotate_random_access<nano_rotate, int>/999/1               1404 ns       1402 ns     495523
    rotate_random_access<nano_rotate, int>/700000/350000     822820 ns     820340 ns        814
    rotate_random_access<nano_rotate, int>/30000/16127        55079 ns      54948 ns      12591
    
    -------------------------------------------------------------------------------------------
    Benchmark                                                    Time           CPU Iterations
    -------------------------------------------------------------------------------------------
    rotate_random_access<std_rotate, int>/1/999                 51 ns         51 ns   13643097
    rotate_random_access<std_rotate, int>/100/900             1269 ns       1258 ns     535598
    rotate_random_access<std_rotate, int>/400/600             1096 ns       1094 ns     573047
    rotate_random_access<std_rotate, int>/500/500               93 ns         93 ns    7549367
    rotate_random_access<std_rotate, int>/700/300             1237 ns       1234 ns     565191
    rotate_random_access<std_rotate, int>/999/1                 52 ns         52 ns   13220518
    rotate_random_access<std_rotate, int>/700000/350000    1072748 ns    1068835 ns        653
    rotate_random_access<std_rotate, int>/30000/16127       104161 ns     103922 ns       6702
    
    opened by DenisYaroshevskiy 6
  • NanoRange failed with error C2903, C2760, C2187 when build with MSVC

    NanoRange failed with error C2903, C2760, C2187 when build with MSVC

    Hi All, I tried to build NanoRange with VS2017 Update 7 on Windows. It failed to build due to the error C2903, C2760, C2187. This issue can be reproduced from master revision 07be3bf. Could you please help take a look at this? Thanks!

    Expected behavior: build successfully

    Actual behavior: The whole log file please see attachment. NanoRange_x86_build.log
    d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,59): error C2903: using type = std::add_cv_t<typename xref::template type>; [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,59): error C2903: ^ [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,41): error C2760: syntax error: unexpected token '::', expected 'id-expression' [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,41): error C2760: using type = std::add_cv_t<typename xref::template type>; [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,41): error C2760: ^ [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,64): error C2187: syntax error: 'identifier' was unexpected here [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,64): error C2187: using type = std::add_cv_t<typename xref::template type>; [D:\NanoRange\build_x86\test\test_nanorange.vcxproj] d:\nanorange\src\include\nanorange\detail\common_reference.hpp(144,64): error C2187: ^ [D:\NanoRange\build_x86\test\test_nanorange.vcxproj]

    Steps to reproduce the behavior:

    1. Open VS2017 x86 Native tools command tool
    2. git clone https://github.com/tcbrindle/nanorange d:\NanoRange\src
    3. cd D:\NanoRange
    4. mkdir build_x86 && pushd build_x86
    5. cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DCMAKE_CXX_STANDARD=17 ..\src\
    6. msbuild /m /p:Configuration=Release;Platform=Win32 nanorange.sln /t:Rebuild

    Thanks, Shanshan

    opened by shanshan0309 6
  • Switch to new return types

    Switch to new return types

    This commit changes the return types of some algorithms, according to the <algorithm> header synopsis on cppreference.

    For the following algorithms I am actually not sure if what I'm returning is correct:

    • partial_sort_copy now returns (an alias to) copy_result<I, O>.
    • partition, stable_partition and unique now return subrange<I>.

    In all cases I'm not 100% sure I'm returning the right value. Also, I've done the bare minimum with the tests to get them to compile and run. That means that I'm only testing the O from the partial_sort_copy_result and only end() of subrange<I>, which is what used to be tested before my pull request.

    opened by bstaletic 4
  • nano::to_vector ?

    nano::to_vector ?

    Sorry if it is obvious, but I did not find a way to convert a range to a vector. Simple example: std::vector<int> = nano::views::iota(0, 1000); // | nano::to_vector ?

    //In Range-v3 return ranges::views::iota(0, starterSize) | ranges::to_vector;

    So, is it possible? Thanks

    opened by Guekka 4
  • Patching two minors problems

    Patching two minors problems

    fixing -> -Wmissing-variable-declarations

    even with inline namespace:

    https://stackoverflow.com/questions/33877510/do-inline-namespace-variables-have-internal-linkage-if-not-why-does-the-code-b

    opened by Milerius 4
  • nano::equal complains about comparing two ranges

    nano::equal complains about comparing two ranges

    I get some very strange behaviour when trying to use nano::equal, as shown below. array_expression is EqualityComparable, and this example works when I use both range-v3 and cmcstl2.

    void check_invariants(gsl::span<std::pair<array_expression, std::string_view>> const expressions,
       std::array<std::string_view, 3> const& names)
    {
       Expects(nano::distance(expressions) == nano::distance(names));
       check_basic_invariants(expressions);
       CHECK(nano::equal(expressions, names, std::equal_to<>{}, &std::pair<array_expression, std::string_view>::second));
    }
    

    Offending expression: nano::equal(expressions, names, std::equal_to<>{}, &std::pair<array_expression, std::string_view>::second).

    Diagnostic: error.txt

    opened by cjdb 4
  • "Conversion from difference_type to int loses data" in partial_insertion_sort

    template <typename I, typename Comp, typename Proj>
    constexpr bool partial_insertion_sort(I begin, I end, Comp& comp, Proj& proj)
    {
        using T = value_type_t<I>;
    
        if (begin == end) {
            return true;
        }
    
        int limit = 0; // ------- NOTE : declaration here ---------
        for (I cur = begin + 1; cur != end; ++cur) {
            if (limit > pqdsort_partial_insertion_sort_limit) {
                return false;
            }
    
            I sift = cur;
            I sift_1 = cur - 1;
    
            // Compare first so we can avoid 2 moves for an element already
            // positioned correctly.
            if (nano::invoke(comp, nano::invoke(proj, *sift),
                             nano::invoke(proj, *sift_1))) {
                T tmp = nano::iter_move(sift);
    
                do {
                    *sift-- = nano::iter_move(sift_1);
                } while (sift != begin &&
                         nano::invoke(comp, nano::invoke(proj, tmp),
                                      nano::invoke(proj, *--sift_1)));
    
                *sift = std::move(tmp);
                limit += cur - sift;
            }
        }
    
        return true;
    }
    

    limit should probably be a difference_type_t<I>

    opened by strega-nil 4
  • Implement clamp, for_each_n and sample algorithms

    Implement clamp, for_each_n and sample algorithms

    sample has a constraint that says (forward_iterator<I> || random_access_iterator<O>). I was looking at the C++17 sample implementation in libc++ and only implemented the forward_iterator version. Should I do what libc++ is doing all the way?

     

    The tests for clamp were derived from the libc++ tests. Should that be reflected in the copyright header of the clamp.cpp?

    opened by bstaletic 3
  • Nanorange failed with error C2607 on MSVC

    Nanorange failed with error C2607 on MSVC

    Hi all,

    NanoRange assert failed on upcoming version of MSVC: F:\gitP\tcbrindle\nanorange\test\test_concepts.cpp(183): error C2607: static assertion failed

    The failing line is:

    static_assert(rng::default_initializable);

    which eventually reaches:

    template inline constexpr bool is_default_initializable<T, std::void_t<decltype(::new T)>> = true;

    '::new const int' is not valid as you cannot default initialize a 'const int'.

    opened by QuellaZhang 3
  • Prevent min / max macro expansion on Windows

    Prevent min / max macro expansion on Windows

    On Windows some modules might includes the windows.h header, which then defines macros for min and max, among other macros. The uniform_random_bit_generator_concept is susceptible to this problem and fails to compile.

    The proper way of handling this issue is to prevent the macro expansion by enclosing the macro names in parenthesis.

    The other known workaround is to define the NOMINMAX macro (but this is user-configurable and not suitable for libraries).

    opened by vcarreira 0
  • Typos in insert_iterator?

    Typos in insert_iterator?

    Spotted a few things when trying to use range algorithms with a std::map. I'm guessing they're just copy/paste errors from being based off back_insert_iterator? ;)

    This should be using insert and not push_back: https://github.com/tcbrindle/NanoRange/blob/bf32251d65673fe170d602777c087786c529ead8/include/nanorange/iterator/insert_iterator.hpp#L34-L39

    Missing the iterator argument and constructing the wrong type: https://github.com/tcbrindle/NanoRange/blob/bf32251d65673fe170d602777c087786c529ead8/include/nanorange/iterator/insert_iterator.hpp#L51-L54

    opened by eigenwhat 1
  • Use memmove optimisations when appropriate

    Use memmove optimisations when appropriate

    When using contiguous iterators with trivially copyable/movable value types, we should be able to optimise copy/move and their backwards versions to use std::memmove. This would have knock-on benefits for several other algorithms which end up copying or moving elements in their implementations.

    Unfortunately memmove is not constexpr, so we'd need to use C++20 std::is_constant_evaluated to detect whether we're being called at compile-time (and should therefore just use the normal implementation) or at run-time. The preprocessor define __cpp_lib_is_constant_evaluated is supported in GCC and Clang to find out whether is_constant_evaluated is available, but I'm not sure about MSVC.

    enhancement 
    opened by tcbrindle 6
  • Add [[nodiscard]] to algorithms and views

    Add [[nodiscard]] to algorithms and views

    All views are now marked with [[nodiscard]], although some things may have been missed. For algorithms, [[nodiscard]] wasn't added to:

    1. In-place, modifying algorithms - the caller often knows what to expect and the return value isn't that useful.
    2. Algorithms that take an output iterator - that output iterator might be ostream_iterator<T>(cout).
    3. next_permutation and prev_permutation - the in_found_result::found seems useful, but I wasn't sure if it is useful enough.
    opened by bstaletic 0
Owner
Tristan Brindle
Tristan Brindle
A flutter plugin that runs a wayland compositor to stream textures onto flutter, allows creation of wayland based shells using flutter

flcompositor A new flutter plugin project. Getting Started This project is a starting point for a Flutter plug-in package, a specialized package that

Davide Bianco 3 Jan 10, 2022
《Graph Optimization Approach to Range-based Localization》; UWB localization

This is modified from localization . Thanks for his work for uwb localizaiton. 代码1:https://github.com/qxiaofan/awesome-uwb-localization 代码2:https://gi

3D视觉工坊 35 Dec 2, 2022
A C++ concepts and range based character encoding and code point enumeration library

Travis CI (Linux:gcc) Text_view A C++ Concepts based character encoding and code point enumeration library. This project is the reference implementati

Tom Honermann 121 Sep 9, 2022
🏅State-of-the-art learned data structure that enables fast lookup, predecessor, range searches and updates in arrays of billions of items using orders of magnitude less space than traditional indexes

The Piecewise Geometric Model index (PGM-index) is a data structure that enables fast lookup, predecessor, range searches and updates in arrays of bil

Giorgio Vinciguerra 651 Dec 29, 2022
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 134 Dec 29, 2022
Range library for C++14/17/20, basis for C++20's std::ranges

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 e

Eric Niebler 3.6k Jan 4, 2023
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 81 Dec 3, 2022
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 100 Nov 10, 2022
HDRView is a simple research-oriented image viewer with an emphasis on examining and comparing high-dynamic range (HDR) images

HDRView is a simple research-oriented high-dynamic range image viewer with an emphasis on examining and comparing images, and including minimalistic tonemapping capabilities. HDRView currently supports reading EXR, PNG, TGA, BMP, HDR, JPG, GIF, PNM, PFM, and PSD images and writing EXR, HDR, PNG, TGA, PPM, PFM, and BMP images.

Wojciech Jarosz 177 Jan 5, 2023
Range library for C++14/17/20, basis for C++20's std::ranges

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 e

Eric Niebler 3.6k Dec 29, 2022
🏅State-of-the-art learned data structure that enables fast lookup, predecessor, range searches and updates in arrays of billions of items using orders of magnitude less space than traditional indexes

The Piecewise Geometric Model index (PGM-index) is a data structure that enables fast lookup, predecessor, range searches and updates in arrays of bil

Giorgio Vinciguerra 650 Dec 31, 2022
Guess a random number between your selected range within the chances you select to win the game!

Number-Guessing-Game Guess a random number between your selected range within the chances you select to win the game! This project was developed by Sa

Sampreet Roy 4 May 13, 2022
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 4 Aug 24, 2022
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 31 Dec 22, 2022
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 237 Dec 1, 2022
TurboRC - Turbo Range Coder / Arithmetic Coding

TurboRC: Turbo Range Coder Fastest Range Coder / Arithmetic Coder 100% C (C++ headers). OS/Arch: Linux amd/inte

powturbo 34 Dec 2, 2022
Algorithms for sound filters, like reverb, dynamic range compression, lowpass, highpass, notch, etc

sndfilter Algorithms for sound filters, like reverb, dynamic range compression, lowpass, highpass, notch, etc. It's easy to find countless math equati

Sean 362 Dec 22, 2022
High dynamic range (HDR) image comparison tool for graphics people. With an emphasis on OpenEXR images.

tev — The EXR Viewer A high dynamic range (HDR) image comparison tool for graphics people. tev allows viewing images through various tonemapping opera

Thomas Müller 740 Dec 31, 2022
Video game library manager with support for wide range of 3rd party libraries and game emulation support, providing one unified interface for your games.

An open source video game library manager and launcher with support for 3rd party libraries like Steam, GOG, Origin, Battle.net and Uplay. Includes game emulation support, providing one unified interface for your games.

Josef Nemec 4.8k Jan 3, 2023