Open matthijskooijman opened 2 years ago
Agreed - the lack of the compile time components (E.g. type traits) of libstdc++ has been a blocker for me a number of times. And given the number of github attempts at this, it seems worthwhile.
Add this to the links: https://github.com/modm-io/avr-libstdcpp
Historically the AVR builds of the toolchain have had their libstdc++ disabled. This meant that the AVR arduino core has had to fill in some gaps (e.g.
new
anddelete
), and other libraries (such as https://github.com/arduino-libraries/Arduino_AVRSTL) have been created to use uclibc++ to fill in the gaps. This gives sketchy results, including duplicate definitions between the core and these libraries, missing C++11 and newer parts (again fixable in a fragile way using libraries like https://github.com/hideakitai/ArxTypeTraits).On the ARM builds, however, libstdc++ is enabled normally (just compiled without exceptions), offering STL containers, but also a lot of (compiletime) utilities and algorithms. Even though ARM typically has a bit more power to spare, a large part of libstdc++ would also be usable just fine on AVR.
So, I would suggest we consider trying to enable libstdc++ on AVR as well, just like on ARM. This is probably not going to work out of the box (since AFAIK, pretty much all official builds are based on Atmel's patches and builds and have had it disabled, so I suspect some parts will have seen some bitrotting), but it also seems that some people have been succesful in compiling it in the past years, and there have even been some patches to upstream gcc to fix things related to libstdc++ on AVR.
This has been on my mind for quite a while now, but I cannot seem to find the time to actually try it myself. Still, I think it's something useful to consider and discuss, so I thought to create this issue the share my thoughts.
Also, here's a couple of related links I collected two years ago, that might have some interesting starting points: