Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add <mstd_xxx> C++ headers #11039
Some C++11 library extensions and fixes, notably
Using separate namespace and filename gives us the ability to work around toolchain differences. In portable code, the following model could be used, assuming the choice between mbed OS and a fully C++11-compliant system.
This is a breaking change with respect to #10868 and #10274 now on master (reworking Atomic.h and mbed_cxxsupport.h), but they're new since 5.13. I'd like this change to go in before 5.14, so there's no visible released API breakage.
Pull request type
For all compilers add post-C++14 stuff to namespace mbed: * invoke, invoke_result, is_invocable, is_invocable_r, is_nothrow_invocable, is_nothrow_invocable_r, unwrap_reference, unwrap_ref_decay For ARM C 5, add C++11 bits based on above to namespace std: * result_of, reference_wrapper, ref, cref, mem_fn
As something of a cheat, exclude platform/cxxsupport from astyle. astyle really can't process the sort of template metaprogramming going on in there; treat it as a "black box" like the toolchains' own libraries.
Regularise the C++ support glue, adding `<mstd_type_traits>` etc. These include the base toolchain file, backfill `namespace std` as much as possible for ARM C 5, and then arrange to create unified `namespace mstd`, which can incorporate toolchain bypasses (eg `mstd::swap` for ARM C 5, or `mstd::atomic`), and include local implementations of post-ARM C++14 stuff. All APIs in `namespace mstd` are intended to function as their `namespace std` equivalent, and their presence there indicates they are functional on all toolchains, and should be safe to use in an Mbed OS build (including not unreasonable memory footprint). See README.md for more info.
* Adjust definition to make the default constructor `constexpr`. This permits use in classes that want lazy initialization and their own `constexpr` constructor, such as `mstd::mutex`. * Add `get_no_init()` method to allow an explicit optimisation for paths that know they won be the first call (such as `mstd::mutex::unlock`). * Add `destroy()` method to permit destruction of the contained object. (`SingletonPtr`'s destructor does not call its destructor - a cheat to omit destructors of static objects). Needed if using in a class that needs proper destruction.
Add add-standard-as-possible version of C++11 <mutex>. A lot of the stuff in there is generic, but the actual mutex classes and call_once need to interface with the OS. For those, they're not available in ARMC5 or IAR; retargetting would be necessary for ARMC6 and GCC, and I've yet to investigate how whether that's possible. So for now I'm using local implementations. Although `Mutex` in principle could support `timed_mutex` and `recursive_timed_mutex`, we don't have `chrono` for the time parameters, so hold off for now. For the generic stuff like mstd::unique_lock, they are aliased to std::unique_lock where possible.
`mbed::Atomic<T>` becomes `mstd::atomic<T>`, alongside the other standard C++ library lookalikes.