---

Backport is an ongoing effort to bring modern C++ utilities to be compatible with C++11.

It is a header-only library that implements much of the functionality from C++14, C++17, and C++20 to be compatible with C++11. constexpr support is conditionally enabled based on the language setting of the compiler (e.g. if using C++14, more constexpr is available to the user than with C++11)

Table of Contents

• Rationale
  A brief rational for while this library was created
• Features
  A summary of all existing features in Backport
• FAQ
  Frequently asked questions about this library
• API Reference
  For doxygen-generated API information
• Legal
  Information about how to attribute this project
• How to install
  For a quick guide on how to install/use this in other projects
• Contributing Guidelines
  Guidelines that must be followed in order to contribute to Backport

Rationale

C++11 was release 9 years ago, and yet many organizations still have yet to move onto more modern releases. In some cases this is due to security reasons, in others it may be that the toolchains don't yet exist for more modern C++ support. In any case, much of the newer C++ library types don't actually require newer C++ language features -- but provide significant value to the developer by creating a new vocabulary that doesn't exist in prior versions.

Much of the newer utilities may also have parallels in Boost libraries, however many organizations are unable to adopt this -- either due to the domain being too constrained, or due to Boost being a large dependency to introduce.

As a result, this library exists as a standalone, header-only, dependency-free drop-in for newer standard library features from C++11, C++14, C++17, and C++20.

Features

C++20

Status	Feature	Paper(s)
✅	bpstd::span	P0122R7 P1024R3 P1976R2 P0317R1
✅	bpstd::to_address	P0653R2
✅ (1)	bpstd::make_unique_for_overwrite	P1020R1 P1973R1
✅	bpstd::is_nothrow_convertible	P0758R1

1. The papers also include make_shared_for_overwrite and allocate_shared_for_overwrite, but these are intentionally not implemented -- since it is impossible to implement efficiently without also authoring shared_ptr (since to join the node allocations requires internal support)

C++17

Status	Feature	Paper(s)
❌ (1)	File System	P0218R1 P0219R1 P0392R0 P0317R1
✅	bpstd::optional	N3793
✅	bpstd::any	N3804
✅	bpstd::string_view	N3921
✅	uniform container access (non-member size(), data(), etc	N4280
✅	bpstd::apply	N3915
✅	bpstd::make_from_tuple	P0209R2
✅	bpstd::as_const	P0007R1
✅	bpstd::variant	P0088R3 P0032R3 P0393R3
✅	bpstd::uncaught_exceptions	N4152 N4259
✅	bpstd::byte	P0298R3
✅	bpstd::not_fn	P0005R4
✅	bpstd::invoke	N4169
✅	bpstd::void_t	N3911
✅	bpstd::bool_constant	N4389
✅	Traits for swappability	P0185R1
🚧	Polymorphic allocators and memory resources	N3916

1. See this answer in FAQ

C++14

Status	Feature	Paper(s)
✅	Type alias versions of standard transformation traits	N3655
✅	Transparent operator functors (bpstd::greater<>, etc)	N3421
✅	bpstd::tuple_element_t	N3887
❌ (1)	SFINAE-friendly bpstd::result_of	N3670
✅	Addressing tuples by type	N3462
➖ (2)	bpstd::is_final	LWG 2112
✅	bpstd::is_null_pointer	LWG 2247
✅	bpstd::make_reverse_iterator	LWG 2285
✅	bpstd::exchange	N3668
✅	bpstd::make_unique	N3656
✅	Compile-time integer sequences (bpstd::integer_sequence)	N3658
✅	User-defined literals for standard library types (bpstd::chrono_literals, bpstd::string_literals)	N3642
✅	User-defined literals for bpstd::complex (bpstd::complex_literals)	N3779

1. Obsolete. Replaced by bpstd::invoke_result
2. Not implementable without compiler support. Pre-C++14, requires specializations and will default to false_type

FAQ

Where is std::filesystem?

This library aims to deliver a header-only solution to the many missing types that have been introduced in newer standard libraries. std::filesystem is a bit complicated to handle, since it introduces a dependency on the operating system being compiled against. Implementing std::filesystem will generally require conditional compilation, and -- for best practices -- separate source files in order to insulate use of system headers (lest this library introduce the perils of the <windows.h> macros). This would change the library fundamentally so that it is no longer a header-only solution -- and this is not desirable.

Third-party implementations of std::filesystem should exist, which can be independently used.

Tested Compilers

This library has been tested against the following compilers / systems

Compiler	Operating System
gcc-4.9	Ubuntu 18.04
gcc-5.0	Ubuntu 18.04
gcc-6	Ubuntu 18.04
gcc-7	Ubuntu 18.04
gcc-8	Ubuntu 18.04
gcc-9	Ubuntu 18.04
clang-3.5	ubuntu 18.04
clang-3.6	ubuntu 18.04
clang-3.7	ubuntu 18.04
clang-3.8	ubuntu 18.04
clang-3.9	ubuntu 18.04
clang-4.0	ubuntu 18.04
clang-5.0	ubuntu 18.04
clang-6.0	ubuntu 18.04
clang-7	ubuntu 18.04
clang-8	ubuntu 18.04
clang-9	ubuntu 18.04
xcode-11.0	macOS 10 (latest)
xcode-11.3	macOS 10 (latest)
MSVC-2015 (14.0)	Windows Server (latest)
MSVC-2017 (14.16)	Windows Server (latest)
MSVC-2019 (14.24)	Windows Server (latest)
clang-cl-9	Windows Server (latest)
clang-9	Windows Server (latest)
gcc-8.1	Windows Server (latest)

License

Backport is licensed under the MIT License:

Copyright © 2020 Matthew Rodusek

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.