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 C++11/14 support utility file #10868
As we start trying to use new facilities, we're likely to need some more helpers.
In particular, ARM C 5 has no C++11 support in its library at all, so to avoid totally breaking it we need some backup.
For the other toolchains, we can add a few C++17/C++20/TS extensions into
Pull request type
The majority of content in this file is a crutch to fill in the limited C++11 support in ARM C 5, so there is at least some chance of someone being able to build master with ARM C 5 once later PRs start using C++11/14.
I could leave it out and greatly simplify it, but it would mean ARM C 5 builds will soon just not work at all.
Last commit looks great! And maybe it would deserve its own PR.
Few things that can be added:
I've actually dropped it from this PR for now, and agree that it would. I believe there are some glitches with backporting it to C++14 - in particular stricter enum initialization rules, so it might not quite fly.
(I'm not 100% sold on
Indeed, thanks for pointing that out!
Just spotted that myself an hour ago. (Not by reading the documentation - by doing
Sorry, no. ARM C 5 does not support alignof/alignas.
Will look at those.
Okay, added most of your suggestions.
It seems there is enough to get all the alignment things apparently working, except
I've baulked at
pan- left a comment
Note: I haven't reviewed array and what's bellow yet.
Thanks for scanning though this.
The CI isn't currently going to catch anything from the bulk of this anyway, as ARM C 5 is not tested. (!)
Nevertheless, some tests would be appreciated. It would be worth you doing them as a second pair of eyes - it's always better if people don't write their own tests, and as this is implementing a clear external spec, we get to cross-check interpretation of that spec.
Actual static asserts should be straightforward to pass - more problematic is SFINAE traits use in
I'm somewhat torn on how much effort to expend on ARM C 5. We're liable to end up doing 90% of the work in this area for a non-supported toolchain...
Thanks @kjbracey-arm I will add tests for the traits you added then. On one of the project I'm working on; we're working with ARM C 5 and C++11 enabled. I've already re-implemented some of the traits we needed but a more complete shim is more than welcome.
It feels like a complete move to ARMC 5 was a bit premature as ARMC 6 hasn't caught up yet on density of the code it generates. Size really matters for customers.
Updated incorporating comments.
I feel bad adding 1000 lines of templates to a header (no doubt more for non ARM C 5 pulling in a real
So I'm going to offset by taking 4000 lines out of Callback.h in another PR in a moment.
The detection idiom is driving me slightly nuts. As far as I can see,
Then any idiom I construct manually with
But trying to do the same test via the detection idiom, eg
As we start trying to use new facilities, we're likely to need some more helpers. In particular, ARM C 5 has no C++11 support in its library at all, so to avoid totally breaking it we need some backup. For the other toolchains, we can add a few C++17/C++20/TS extensions into namespace mbed to make life a little easier. * For ARM C 5: C++14 type_traits subset, std::move, std::forward, std::array, std::initializer_list, std::begin, std::end, std::align, std::maxalign_t, std::aligned_storage, alignof + alignas macro replacements. * For ARM C 5: MBED_CONSTEXPR_FN_14 and MBED_CONSTEXPR_OBJ_14 to mark things that can only be constexpr in C++14 or later. * For other compilers: mbed::void_t, mbed::type_identity, mbed::conjunction, mbed::disjunction, mbed::negation, mbed::experimental::nonesuch, mbed::experimental::is_detected family, mbed::remove_cvref, mbed::as_const.