Consider contributing to upstream libstdc++ instead

[jwakely]

There is an ongoing project to increase the parts of the C++ Standard Library that are available for freestanding implementations, i.e. those with no OS, so no I/O and no malloc. C++23 already enables all of <tuple>, most of <atomic>, <functional>, std::unique_ptr, and more. For C++26 that will increase to include <algorithm> and more.

This means that upstream libstdc++ will be enabling all those features for freestanding in the near future. Rather than duplicating work, it seems to me that it would benefit everybody if you contributed to that effort to enable those features in upstream libstdc++.

[jwakely]

I forgot to link to the changes already approved for C++23:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1642r11.html

[salkinium]

We're aware of Ben's work on freestanding since 2018 or so.
But we needed a solution for C++17, so we adapted our own version for AVR to have some feature parity with Newlibs stdlibc++ for ARM Cortex-M devices.

This repo is not meant to replace the stdlibc++, just remove the need to have a stdlibc++ polyfill implementation in modm only for AVR devices.
So I'm not sure if we want to upstream this work at all, considering that we have different goals than freestanding.
I'm personally also already busy with other modm-related work.

Maybe @chris-durand can tell you more, since he adapted the code.

[jwakely]

OK, thanks for the reply.

FWIW when we implement Ben's proposals in libstdc++ I don't plan to make it conditional on using C++23 mode. A freestanding implementation is allowed to provide more than the minimum set of features. So I think we should enable tuple, pair etc. for older standards too, not just C++23.

[ckormanyos]

There is an ongoing project to increase the parts of the C++ Standard Library that are available for freestanding implementations

Thank you Jonathon (@jwakely). I've been very briefly in previous contact with Ben regarding new efforts specifying and expanding freestanding in the standard. Although I have not contributed recently, I would like to get more involved in the work.

In general, we find that the GCC port(s) to AVR can be an interesting place to investigate such matters. Since the GCC port does not ship with an STL, it is possible to simply place or put an existing STL implementatoin in the include path of the compiler and test standalone. This can be quite rewarding since the AVR port is modern and maintained, but the lack of an STL makes it possible to test a given STL or standard library implementation completely in the raw.

[ckormanyos]

This means that upstream libstdc++ will be enabling all those features for freestanding in the near future. Rather than duplicating work, it seems to me that it would benefit everybody if you contributed to that effort to enable those features in upstream libstdc++.

Hi Jonathon (@jwakely).

Where is this work? How can I/we get started if interest/time allow? I would like to see progress on <algorithm> and I hope there will be a variation of <array> for 23/26.

[jwakely]

It's happening in frequently rebased git branches for now, but might be finished in the next few days and will get committed upstream. You can find me on GCC's developer IRC channel if you want the details.

When I first commented here the work hadn't started yet (just ideas on paper) but now we have most of the code changes done, and we're getting the tests green. For now we've skipped <algorithm> as it's not freestanding in C++23, but we've already done some of the work to disable the parts that require libc or OS support, so it's almost there. <array> should be very easy.

[ckormanyos]

Thank you @jwakely.

[jwakely]

It's happening in frequently rebased git branches for now, but might be finished in the next few days and will get committed upstream.

That work is now upstream 🎉

[ckormanyos]

Thank you Jonathan (@jwakely)!

[ckormanyos]

See also #39