Guidelines Support Library

GSL: Guidelines Support Library

Build Status

The Guidelines Support Library (GSL) contains functions and types that are suggested for use by the C++ Core Guidelines maintained by the Standard C++ Foundation. This repo contains Microsoft's implementation of GSL.

The entire implementation is provided inline in the headers under the gsl directory. The implementation generally assumes a platform that implements C++14 support.

While some types have been broken out into their own headers (e.g. gsl/span), it is simplest to just include gsl/gsl and gain access to the entire library.

NOTE: We encourage contributions that improve or refine any of the types in this library as well as ports to other platforms. Please see CONTRIBUTING.md for more information about contributing.

Project Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Usage of Third Party Libraries

This project makes use of the Google Test testing library. Please see the ThirdPartyNotices.txt file for details regarding the licensing of Google Test.

Supported features

Microsoft GSL implements the following from the C++ Core Guidelines:

Feature Supported? Description
1. Views
owner an alias for a raw pointer
not_null restricts a pointer / smart pointer to hold non-null values
span a view over a contiguous sequence of memory. Based on the standardized verison of std::span, however gsl::span enforces bounds checking. See the wiki for additional information.
span_p spans a range starting from a pointer to the first place for which the predicate is true
basic_zstring A pointer to a C-string (zero-terminated array) with a templated char type
zstring An alias to basic_zstring with a char type of char
czstring An alias to basic_zstring with a char type of const char
wzstring An alias to basic_zstring with a char type of wchar_t
cwzstring An alias to basic_zstring with a char type of const wchar_t
u16zstring An alias to basic_zstring with a char type of char16_t
cu16zstring An alias to basic_zstring with a char type of const char16_t
u32zstring An alias to basic_zstring with a char type of char32_t
cu32zstring An alias to basic_zstring with a char type of const char32_t
2. Owners
unique_ptr an alias to std::unique_ptr
shared_ptr an alias to std::shared_ptr
stack_array a stack-allocated array
dyn_array a heap-allocated array
3. Assertions
Expects a precondition assertion; on failure it terminates
Ensures a postcondition assertion; on failure it terminates
4. Utilities
move_owner a helper function that moves one owner to the other
byte either an alias to std::byte or a byte type
final_action a RAII style class that invokes a functor on its destruction
finally a helper function instantiating final_action
GSL_SUPPRESS a macro that takes an argument and turns it into [[gsl::suppress(x)]] or [[gsl::suppress("x")]]
[[implicit]] a "marker" to put on single-argument constructors to explicitly make them non-explicit
index a type to use for all container and array indexing (currently an alias for std::ptrdiff_t)
joining_thread a RAII style version of std::thread that joins
narrow a checked version of narrow_cast; it can throw narrowing_error
narrow_cast a narrowing cast for values and a synonym for static_cast
narrowing_error a custom exception type thrown by narrow()
5. Concepts

The following features do not exist in or have been removed from the C++ Core Guidelines:

Feature Supported? Description
strict_not_null A stricter version of not_null with explicit constructors
multi_span Deprecated. Multi-dimensional span.
strided_span Deprecated. Support for this type has been discontinued.
basic_string_span Deprecated. Like span but for strings with a templated char type
string_span Deprecated. An alias to basic_string_span with a char type of char
cstring_span Deprecated. An alias to basic_string_span with a char type of const char
wstring_span Deprecated. An alias to basic_string_span with a char type of wchar_t
cwstring_span Deprecated. An alias to basic_string_span with a char type of const wchar_t
u16string_span Deprecated. An alias to basic_string_span with a char type of char16_t
cu16string_span Deprecated. An alias to basic_string_span with a char type of const char16_t
u32string_span Deprecated. An alias to basic_string_span with a char type of char32_t
cu32string_span Deprecated. An alias to basic_string_span with a char type of const char32_t

This is based on CppCoreGuidelines semi-specification.

Quick Start

Supported Compilers

The GSL officially supports the current and previous major release of MSVC, GCC, Clang, and XCode's Apple-Clang. See our latest test results for the most up-to-date list of supported configurations.

Compiler Toolset Versions Currently Tested
XCode 11.4 & 10.3
GCC 9 & 8
Clang 11 & 10
Visual Studio with MSVC VS2017 (15.9) & VS2019 (16.4)
Visual Studio with LLVM VS2017 (Clang 9) & VS2019 (Clang 10)

If you successfully port GSL to another platform, we would love to hear from you!

  • Submit an issue specifying the platform and target.
  • Consider contributing your changes by filing a pull request with any necessary changes.
  • If at all possible, add a CI/CD step and add the button to the table below!
Target CI/CD Status
iOS CI_iOS
Android CI_Android

Note: These CI/CD steps are run with each pull request, however failures in them are non-blocking.

Building the tests

To build the tests, you will require the following:

  • CMake, version 3.1.3 (3.2.3 for AppleClang) or later to be installed and in your PATH.

These steps assume the source code of this repository has been cloned into a directory named c:\GSL.

  1. Create a directory to contain the build outputs for a particular architecture (we name it c:\GSL\build-x86 in this example).

     cd GSL
     md build-x86
     cd build-x86
    
  2. Configure CMake to use the compiler of your choice (you can see a list by running cmake --help).

     cmake -G "Visual Studio 15 2017" c:\GSL
    
  3. Build the test suite (in this case, in the Debug configuration, Release is another good choice).

     cmake --build . --config Debug
    
  4. Run the test suite.

     ctest -C Debug
    

All tests should pass - indicating your platform is fully supported and you are ready to use the GSL types!

Building GSL - Using vcpkg

You can download and install GSL using the vcpkg dependency manager:

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

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

Using the libraries

As the types are entirely implemented inline in headers, there are no linking requirements.

You can copy the gsl directory into your source tree so it is available to your compiler, then include the appropriate headers in your program.

Alternatively set your compiler's include path flag to point to the GSL development folder (c:\GSL\include in the example above) or installation folder (after running the install). Eg.

MSVC++

/I c:\GSL\include

GCC/clang

-I$HOME/dev/GSL/include

Include the library using:

#include <gsl/gsl>

Usage in CMake

The library provides a Config file for CMake, once installed it can be found via

find_package(Microsoft.GSL CONFIG)

Which, when successful, will add library target called Microsoft.GSL::GSL which you can use via the usual target_link_libraries mechanism.

FetchContent

If you are using cmake version 3.11+ you can use the offical FetchContent module. This allows you to easily incorporate GSL into your project.

# NOTE: This example uses cmake version 3.14 (FetchContent_MakeAvailable).
# Since it streamlines the FetchContent process
cmake_minimum_required(VERSION 3.14)

include(FetchContent)

# In this example we are picking a specific tag.
# You can also pick a specific commit, if you need to.
FetchContent_Declare(GSL
    GIT_REPOSITORY "https://github.com/microsoft/GSL"
    GIT_TAG "v3.1.0"
)

FetchContent_MakeAvailable(GSL)

# Now you can link against the GSL interface library
add_executable(foobar)

# Link against the interface library (IE header only library)
target_link_libraries(foobar PRIVATE GSL)

Debugging visualization support

For Visual Studio users, the file GSL.natvis in the root directory of the repository can be added to your project if you would like more helpful visualization of GSL types in the Visual Studio debugger than would be offered by default.

If you are using cmake this will be done automatically for you. See 'GSL_VS_ADD_NATIVE_VISUALIZERS'

Owner
Microsoft
Open source projects and samples from Microsoft
Microsoft
Comments
  • array_view not possible with incomplete Classes

    array_view not possible with incomplete Classes

    Hello,

    I use a small simple class that takes a pointer and a size for wrapping normal arrays, quite the same what array_view is designed to solve in a much more generic fashion. I found a drawback compared to using a simple class, and that is that array_view does not work with incomplete classes. I dont know if its possible to fix this via templates specialization and sfinae voodoo, but would be really nice if this use-case is covered aswell

    #include <array_view.h>
    class CIncomplete;
    
    void foo(gsl::array_view<CIncomplete> s); // OK
    gsl::array_view<CIncomplete> s; // Not OK (says clang 3.6 and gcc 5.1 )
    
  • array_view should have a constructor that takes an initializer_list

    array_view should have a constructor that takes an initializer_list

    I started trying to convert some code that provides safety / convenience wrappers around D3D API calls over to use gsl::array_view and ran into a problem that means I can't support the interface I want. I have calling code that looks like this:

    // defined somewhere 
    Microsoft::WRL::ComPtr<ID3D11DeviceContext> context;
    Micrsofot::WRL::ComPtr<ID3D11Buffer> vertices;
    UINT stride;
    
    // calling code somewhere else
    IASetVertexBuffers(context, 0, {vertices.Get()}, {stride});
    

    And a wrapper around ID3D11DeviceContext::IASetVertexBuffers() with signature:

    void IASetVertexBuffers(
      [in]                 UINT                StartSlot,
      [in]                 UINT                NumBuffers,
      [in, optional]       ID3D11Buffer *const *ppVertexBuffers,
      [in, optional] const UINT                *pStrides,
      [in, optional] const UINT                *pOffsets
    );
    

    That currently looks like this:

    template <typename Context, typename Buffers = std::initializer_list<ID3D11Buffer*>,
              typename Strides = std::initializer_list<UINT>>
    void IASetVertexBuffers(const Context& context, unsigned startSlot, const Buffers& buffers,
                            const Strides& strides) {
        UINT offsets[D3D11_IA_VERTEX_INPUT_RESOURCE_SLOT_COUNT] = {};
        context->IASetVertexBuffers(UINT(startSlot), UINT(std::size(buffers)), std::begin(buffers),
                                    std::begin(strides), std::begin(offsets));
    };
    

    This wrapper lets me directly pass a braced init list as an argument for buffers and strides (the default std::initializer_list template arguments allow the compiler to deduce the type correctly in this case) or any other Container type that supports begin() and end().

    I'd like to convert the buffers and strides parameters to gsl::array_views over the appropriate types. Currently however gsl::array_view has no constructor taking an std::initializer_list which means I can't get my desired call-site syntax of directly passing a braced init list and having a gsl::array_view implicitly constructed from it. I could write my own as_array_view helper but I hate unnecessary typing at the call site :-)

    I think a gsl::array_view constructor taking an std::initializer_list would give me the call syntax I'd like but I may be missing some subtlety that means that wouldn't work. Still, one way or another I'd like to be able to directly pass braced init lists to functions taking a gsl::array_view of the corresponding type.

  • 2fc94db made gsl::not_null constructor explicit, why?

    2fc94db made gsl::not_null constructor explicit, why?

    Since 2fc94db3ebfb1b066edeafac1837f34d6111bff4, this program does not work anymore without explicit cast to not_null (here tested with clang 5.0.2 on linux with -std=c++14):

    #include <gsl/pointers>
    #include <iostream>
    
    void f(gsl::not_null<const int *> i) {
      std::cout << *i << '\n';
    }
    
    int main() {
      int i = 42;
      f(&i); // no matching function for call to 'f'
             // note: candidate function not viable: no known conversion from 'int *' to 'gsl::not_null<const int *>' for 1st argument
      return 0;
    }
    

    If this is really wanted, could you explain why?

    Kind regards

  • not_null has converting constructors?

    not_null has converting constructors?

    It seems to me that offering a conversion from T to not_null<T> looses the potential to detect certain bugs at compile-time.

    if I have a function that returns a raw (potentially null) pointer, and I carelessly pass it to a function taking not_null it will compile fine, and will try report a bug at run-time when it is likely too late.

    Instead, if the constructor from T were explicit, an inadvertent assignment:

    use_ptr(make_ptr());
    

    would be impossible, and I would be forced to explicitly require a potentially unsafe conversion:

    use_ptr(not_null<T>{make_ptr()});
    

    This would be a kind of the signature: by writing this cast, I am taking the responsibility for guaranteeing that the raw pointer will not be null. If it is not the case, you will know that I did it consciously.

    See also CppCoreGuidelines issue: https://github.com/isocpp/CppCoreGuidelines/issues/767

  • Name collision with GNU Scientific Library

    Name collision with GNU Scientific Library

    Guidelines Support Library shorthand "GSL" if will get widespread could be ambiguous in projects that use GNU Scientific Library (shorthand is GSL). Namespace gsl:: is used for some C++ wrappers for GNU Scientific Library. Same goes for macro prefixed with GSL_. Related to #9 #38

  • Broken test for constexpr support

    Broken test for constexpr support

    You have this -

    #if _MSC_VER < 1910 #pragma push_macro("constexpr") #define constexpr /constexpr/ #define GSL_USE_STATIC_CONSTEXPR_WORKAROUND #endif // _MSC_VER < 1910 #else // _MSC_VER // See if we have enough C++17 power to use a static constexpr data member // without needing an out-of-line definition #if !(defined(__cplusplus) && (__cplusplus >= 201703L)) #define GSL_USE_STATIC_CONSTEXPR_WORKAROUND #endif // !(defined(__cplusplus) && (__cplusplus >= 201703L)) #endif // _MSC_VER

    Which will fail, because Visual Studio doesn't correctly set __cplusplus value.

    A correct, cross-platform way to do this can be found in https://github.com/dcleblanc/SafeInt/commits/master/SafeInt.hpp from lines 19-128

    I don't assert that my approach in SafeInt is ideal, but it definitely works, I've tested it.

  • array_view as_bytes() and as_writeable_bytes() appear to invoke undefined behaviour in current implementation

    array_view as_bytes() and as_writeable_bytes() appear to invoke undefined behaviour in current implementation

    The current implementations of array_view's as_bytes() and as_writeable_bytes() do this:

    // as_bytes()
    return { reinterpret_cast<const byte*>(this->data()), this->bytes() };
    // as_writeable_bytes()
    return { reinterpret_cast<byte*>(this->data()), this->bytes() };
    

    Where byte is defined as:

    enum class byte : std::uint8_t {};
    

    This appears to invoke undefined behaviour if the array_view is used to access memory as per 3.10.10:

    If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

    • the dynamic type of the object,
    • a cv-qualified version of the dynamic type of the object,
    • a type similar (as defined in 4.4) to the dynamic type of the object,
    • a type that is the signed or unsigned type corresponding to the dynamic type of the object,
    • a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
    • an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union),
    • a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
    • a char or unsigned char type.

    The usual get-out for this type of operation is the bolded clause (you are allowed to access any memory via a pointer to char or unsigned char) however I don't believe this applies because a) uint8_t is not guaranteed to be a typedef for either char or unsigned char (18.4.1):

    typedef unsigned integer type uint8_t; // optional

    and b) an enum is a distinct type even if its storage is specified as a char type (7.2.1):

    An enumeration is a distinct type (3.9.2) with named constants.

    It's possible there is language elsewhere in the standard that makes this code not undefined behaviour but I can't find anything that would seem to make this well defined.

  • Compile without exception support

    Compile without exception support

    I am trying to use this in an other project which compiles without exception support.
    I would not mind substituting the exceptions with asserts, and let it fire only in debug.

    currently I use only the <gsl/span> header, my problem lies in <gsl/gsl_util>.
    Could we get something like:

    #if defined ( __cpp_exceptions) || \
            (defined (_MSC_VER) && defined (__CPPUNWIND)) || \
            (defined (__GNUC__) && defined (__EXCEPTIONS))
        #define ABORT_THROW (x) throw x
    #else
        #define ABORT_THROW (x) (x, std::abort())
    #endif
    

    and then use ABORT_THROW when needed?

  • Intel compiler compilation error

    Intel compiler compilation error

    I tried using gsl with Intel compiler 16 under SUSE Linux Enterprise Server 11 SP4 and got a

    icpc ../main.cpp -o test -std=c++14
    In file included from ../gsl/multi_span(23),
                 from ../gsl/gsl(24),
                 from ../main.cpp(1):
    ../gsl/gsl_byte(78): error #3377: constexpr function return is non-constant
        return l = byte(static_cast<unsigned char>(l) | static_cast<unsigned char>(r));
    

    (multiple times)

    icpc --version
    icpc (ICC) 16.0.3 20160415
    Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.
    
    cat ../main.cpp
    #include "gsl/gsl"
    int main(int argc, char* argv[]) {
    }
    
  • Name conflict with the GNU Scientific Library

    Name conflict with the GNU Scientific Library

    Microsoft/GSL conflicts with https://www.gnu.org/software/gsl/ (another completely different project) and not only with the name, but as far as I can see also in the installed files.

    Would it be possible to ponder a rename of this project, on the basis that GNU's GSL is much older than Microsoft's GSL?

  • Fix compiler warning

    Fix compiler warning

    When building with GCC 5.4, the compiler spits out a warning about the following:

    warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow]

    This patch fixes this issue.

    Signed-off-by: “Rian <“[email protected]”>

  • Resolve MSVC warning C5260

    Resolve MSVC warning C5260

    MSVC warning C5260 says namespace-scope constexpr variables should be marked inline or static for C++20 header units. ("warning C5260: the constant variable 'X' has internal linkage in an included header file context, but external linkage in imported header unit context; consider declaring it 'inline' as well if it will be shared across translation units, or 'static' to express intent to use it local to this translation unit").

  • `Expects` and `Ensures` should be `GSL_EXPECTS` and `GSL_ENSURES`

    `Expects` and `Ensures` should be `GSL_EXPECTS` and `GSL_ENSURES`

    GSL should obey the core guidelines. Expects and Ensures should be GSL_EXPECTS and GSL_ENSURES. As the person who has suffered for 30 years for defining widely used macros check and require I can attest to just how bad an idea those names are. (https://opensource.apple.com/source/xnu/xnu-7195.141.2/EXTERNAL_HEADERS/AssertMacros.h.auto.html)

  • size_bytes unnecessarily optimizes poorly

    size_bytes unnecessarily optimizes poorly

    The span function size_bytes is currently implemented as follows:

        constexpr size_type size_bytes() const noexcept
        {
            Expects(size() < dynamic_extent / sizeof(element_type));
            return size() * sizeof(element_type);
        }
    

    This check is attempting to ensure that the multiplication doesn't overflow. This check is not actually needed because it is not possible for "size" to become so large that the overflow occurs. The only way this could happen is if the span was somehow representing more than size_t bytes worth of data but there's no room in the virtual address space for this.

    It leads to code optimizing poorly. In my current project I am calling size_bytes and it is actually a function call (I imagine because this code is compiled for size and size_bytes is a lot of code).

    binary!gsl::span<unsigned char const ,-1>::size_bytes:
    00000001`40434650 4883ec28        sub     rsp,28h
    00000001`40434654 488b01          mov     rax,qword ptr [rcx]
    00000001`40434657 4883f8ff        cmp     rax,0FFFFFFFFFFFFFFFFh
    00000001`4043465b 7306            jae     binary!gsl::span<unsigned char const ,-1>::size_bytes+0x13 (00000001`40434663)
    00000001`4043465d 4883c428        add     rsp,28h
    00000001`40434661 c3              ret
    00000001`40434662 cc              int     3
    00000001`40434663 e864000000      call    binary!gsl::details::terminate (00000001`404346cc)
    

    Notice since this is a span of bytes, there is a comparison to check if rax (the size) is bigger than or equal to 0xFFFFFFFF'FFFFFFFF. There is no way a span could be this big, and this check is resulting in a ton of code generation for what should just be loading the size field and returning it.

  • not_null conversion operator for non-copy constructible types

    not_null conversion operator for non-copy constructible types

    gsl::not_null< T > has the following conversion operator:

    constexpr operator T() const
    {
        return get();
    }
    

    which is deleted for non-copy constructible types such as std::unique_ptr due to gsl::not_null< T >'s conditional return type mapping to const T&:

    constexpr std::conditional_t<std::is_copy_constructible<T>::value, T, const T&> get() const
    {
        Ensures(ptr_ != nullptr);
        return ptr_;
    }
    

    Therefore, it is not possible to extract (the potentially expensive) ptr_ anymore for non-copy constructible types once a gsl::not_null< T > is constructed around it. Wouldn't it make sense to use ref-qualified member methods for both methods (i.e. conversion operator and get)?

    // For non-copy constructible types:
    
    constexpr operator const T&() const &
    {
        return ptr_;
    }
    
    constexpr operator T() &&
    {
        return std::move(ptr_);
    }
    
  • is_different_signedness using std::is_signed< T > instead of std::numeric_limits< T >::is_signed

    is_different_signedness using std::is_signed< T > instead of std::numeric_limits< T >::is_signed

    gsl::narrow internally uses

    constexpr const bool is_different_signedness = (std::is_signed<T>::value != std::is_signed<U>::value);

    which uses std::is_signed< T >. The latter cannot be specialized for custom arithmetic types (e.g., 16 bit floating point type, 128 bit integral types, etc.):

    The behavior of a program that adds specializations for is_signed or is_signed_v (since C++17) is undefined.

    unlike std::numeric_limits< T >::is_signed. Wouldn't gsl::narrow become more extendible, if std::is_signed< T > is replaced with std::numeric_limits< T >::is_signed?

  • MSVC - gsl::make_span with iterators

    MSVC - gsl::make_span with iterators

    I have some code that uses gsl::make_span(cont.begin(), cont.end()) quite heavily. This compiles fine on macOS and Linux with GCC and Clang, but fails on MSVC. Instead, I have to use gsl::make_span(cont.data(), std::distance(cont.begin(), cont.end())) - which becomes pretty tedious and illegible.

    Here's a quick example. Is there another overload we can use?

    We can't pass the whole container to make_span, since we sometimes have varying end iterators returned from algorithms.

gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

Jun 16, 2022
Guidelines Support Library

GSL: Guidelines Support Library The Guidelines Support Library (GSL) contains functions and types that are suggested for use by the C++ Core Guideline

Jun 14, 2022
Bsl - Rust 2018 and C++20, "constexpr everything", AUTOSAR compliant header-only library intended to support the development of critical systems applications
Bsl - Rust 2018 and C++20,

Description The Bareflank Support Library (BSL) is a Rust 2018 and C++20, "constexpr everything", AUTOSAR compliant header-only library intended to su

Jun 18, 2022
GNU Scientific Library with CMake build support and AMPL bindings

GSL - GNU Scientific Library This is GSL, the GNU Scientific Library, a collection of numerical routines for scientific computing. GSL is free softwar

Jun 16, 2022
C++ STL in the Windows Kernel with C++ Exception Support

C++ STL in Windows Drivers This project uses MSVC C++ STL in a Windows Kernel Driver. In this solution jxystl.lib is implemented as a kernel-tuned, po

Jun 10, 2022
C++11/14/17 std::optional with functional-style extensions and reference support

optional Single header implementation of std::optional with functional-style extensions and support for references. Clang + GCC: MSVC: std::optional i

Jun 21, 2022
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.

?? Index What is Libft? List of Functions Technologies ✨ What is Libft? Libft is an individual project at 42 that requires us to re-create some standa

Jan 17, 2022
Library that simplify to find header for class from STL library.

Library that simplify to find header for class from STL library. Instead of searching header for some class you can just include header with the class name.

Jun 7, 2022
Thrust is a C++ parallel programming library which resembles the C++ Standard Library.

Thrust: Code at the speed of light Thrust is a C++ parallel programming library which resembles the C++ Standard Library. Thrust's high-level interfac

Jun 22, 2022
jkds is a modern header-only C++20 library that complements the standard library.

jkds is a modern header-only C++20 library that complements the standard library. It provides generic atypical data structures, ergonomic functional programming abstractions, and then some.

May 24, 2022
Bionic BSD-3-ClauseBionic - Google's standard library, developed for Android. BSD-3-Clause

bionic bionic is Android's C library, math library, and dynamic linker. Using bionic as an app developer See the user documentation. Working on bionic

Jun 13, 2022
CloudABI's standard C library

NOTE: This project is unmaintained CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustai

Jun 7, 2022
libcu++: The C++ Standard Library for Your Entire System

libcu++, the NVIDIA C++ Standard Library, is the C++ Standard Library for your entire system. It provides a heterogeneous implementation of the C++ Standard Library that can be used in and between CPU and GPU code.

Jun 16, 2022
D++ Extremely Lightweight C++ Discord Library

D++ An incredibly lightweight C++ Discord library This project is in alpha stages of development. Completed so far: Websocket connection with heartbea

Jun 18, 2022
EASTL stands for Electronic Arts Standard C++ Template Library

EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

Jun 17, 2022
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).

?? LIBFT-42 : Artistic view of LIBC: ?? HOW DOES IT FEEL HAVING YOUR OWN LIB: SUBJECT : ENGLISH PDF ℹ️ What is LIBFT : This project aims to code a C l

Mar 24, 2022
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.

Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags. Quick start #include <bitflags/bitf

May 4, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Jun 18, 2022
Your standard library for metaprogramming

Boost.Hana Your standard library for metaprogramming Overview #include <boost/hana.hpp> #include <cassert> #include <string> namespace hana = boost::h

Jun 12, 2022