Re: Partial libstdc++ Support

[Klaus]

Hi,


> Naturally, much of the C++ standard library isn't remotely suitable for
> AVRs, and should not be supported. However, there are a fair amount of
> features that I believe would work very nicely, and would be worthwhile
> to support. For example, std::array, std::optional, <concepts>, and the
> C++ counterparts to the C standard headers (e.g. <cstdint>).

For me, most of the <traits> is important to make programming easier.
And all compile time constant containers as well. A long time ago, for
gcc 4.x.x I was able to fake the gcc libc++ for avr and was able to use
a lot of things from scratch. But I saw that it is a moving target to
keep my adaptions working and stopped my work. I simply faked some of
the ./bits/* files and was able to compile a lot of stl code. What I saw
was a lot of dependencies to thread support and such. A lot of headers
are including each other and it was more or less a big bunch of code not
very well structured. But all this is decades away :-)


> It seems that the usual solution for those seeking this functionality is
> to make their own implementation. While it works, I think it would be
> nice to have it provided by avr-gcc, if possible. I'd prefer to keep the
> boilerplate in the compiler rather than my projects.
>
> Is there a reason beyond a lack of interest that these features are not
> supported? I would be happy to work on this if so. Would selectively
> picking out parts of libstdc++ be a reasonable approach?


As said, it was possible with some hours of afford to fake parts of STL
delivered with gcc to work on avr. But if there is no interest from
others and stl will not be maintained for avr, it makes no sense to run
behind the main platforms.

And there is still the problem, that gcc has some very old design
"bugs". One is vtable in ram and other code which directly goes to ram
and makes it often impossible to use c++ for some "bigger" projects. I
see me often writing hand crafted vtable replacements and "deoptimizing"
switch/case and such stuff, because gcc wastes a lot of ram. Quite clear
that it is fast, but ram is the most critical resource on avr. I moved
to arm for a lot of projects, even if avr hardware would be nicer, but
gcc was not able to generate the needed code for avr for given reasons.
Missing parts of STL and the ram problem let me move to other controllers!

Klaus