ArduinoCore-avr
ArduinoCore-avr copied to clipboard
arduino
Please support C++17 by default
My code contains variable templates that C++11 does not support. So each time I set up Arduino IDE for a new PC/user, I'll have to go to "%AppData%\Local\Arduino15\packages\arduino\hardware\avr\1.8.3\platform.txt" and set the "-std=gnu++17" compiler argument. Isn't C++17 fully compatible with C++11 code? Why is the old C++11 still the default?
I guess because the avr-gcc 7.3.0 does not support C++17 to the full extent. But C++14 would make sense. Or Arduino.cc changes to avr-gcc 9.4.0 with C++17 per default.
Even better would be avr-gcc 11.2.0, but then corrections would have to be made in even more places in the framework. Because much of the syntax was set to deprecated.
By the way, you can also create a platform.local.txt.
There will be nothing more from Arduino.cc. They work on the IDE 2.0. You can write in the platform.txt in line 28 instead of -std=gnu++11 simply -std=gnu++17. Then all defaults are C++17 with the restrictions that avr-gcc 7.3.0 brings with it. The majority is usable. Or you use a current toolchain.
Sure everyone can do this, but it's not the same as having c++17 as a default for the core, as well as all the libraries. Of course it was just a question to know if there were plans to add it in the near future, I don't expect it.
No one is going to rewrite all libraries. Who is going to do that? You are asking too much. You must look only once how old the usual libraries are. Nobody cares anymore as long as it works. But you can write and maintain your own libraries according to C++17 or even C++20.
No one is going to rewrite all libraries. Who is going to do that?
Why should one need to rewrite all libraries? I thought that the problem here was with gcc-avr as you guessed some time ago.
You are asking too much. You must look only once how old the usual libraries are.
I think there was a misunderstanding. I'm just asking if there are plans to switch to c++17 by default. To be clear, are you speaking on behalf of arduino.cc?
Is there a misunderstanding or do you have a misconception? If you don't want all libraries to be rewritten or you think they shouldn't be rewritten to language standard C++17, then why do you want default C++17? Just because the toolchain may compile with C++17 setting does not automatically make it C++17 code. The possibilities of a higher language standard must already use the programmer. I think you are imagining it wrong.
And no I have nothing to do with Arduino.cc. I just use it very often.
@grobx Unfortunately, according to @mikrocoder 's logic, there will hardly ever be any plan to switch, as long as modern PCs still support gcc-7.3.0. That is, only Windows, Linux or MacOS can force the author to upgrade gcc by deprecating its old versions, since no one is going to rewrite all libraries as long as they can still work.🙂 After all, developers of free projects are always busy with their own livelihoods.
Is there a misunderstanding or do you have a misconception?
I was talking about me asking for any plan to go with c++17 by default and you continuing to reply on behalf of someone else that its not going to happen.
Anyway, I think this discussion can't go any further, so I'll leave it to others.
@grobx So that's enough of your nonsense. Here everyone may write what he thinks. I have never claimed that I am from Arduino.cc. I wanted to help you to correct your wrong thinking. You don't even know why C++17 should be default if nothing else should be changed, according to his logic.
@Silver-Fang This is also completely wrong. You can use any version of the toolchain you want. Whether it's 1.0 or the current 12.2, it's completely independent of the operating system. You as a programmer have to use the language features. If you want to, you can use a current version. If you don't want to, it doesn't matter which version you use. As long as it currently supports C++11. So you could even use 5.4.0.
It feels like there might be some misunderstanding here, maybe I can help clarify. I cannot speak on behalf of Arduino, but I do have been involved with various of their development in the past.
This repo contains the Arduino AVR core, which decides which compiler version is installed along with it and what options it is called with. Those options define the C++ version used for all C++ code. There is nothing a library or sketch (or even the user, apart from modifying the core) can do to change the options for the C++11 version. So this means if any code (i.e. your sketch) wants to use e.g. C++17 things, the core must enable C++17. Which is why different people in this issue have asked about this.
In general, C++ versions are reasonably backward compatible (i.e. code written for C++11 is going to work with C++17), though I think there are some parts that do not work. This means that if the AVR core bumps the C++ version to C++17, most code will continue to work. Since maybe not everything would work, upgrading C++ version is something to be done with care (and testing).
There will be nothing more from Arduino.cc. They work on the IDE 2.0.
I'm not sure I follow this. Arduino.cc developers are busy working on all kinds of things, but AFAICS there is just a lot of things on their list, so I expect this is a thing that they are just not getting around to this. Also, the IDE 2.0 still uses this core for AVR boards, so (except because time is limited), work on IDE 2.0 does not conflict with work on this core.
However, as already mentioned, supporting C++17 might need a newer gcc version, which makes this a bit more complicated than just adding a compiler option (which makes it more likely to be postponed until later).
Much too complicated. The only thing that happens with the new toolchain is that more warnings are displayed. You have to live with that or fix them. Only the warnings should help the programmer to write clean code. -Wno-volatile is a stopgap, otherwise you would have to rework the whole Arduino core. And adding a new toolchain is not complicated.
If you don't compile it yourself you can use the one from Zak Kemple. https://blog.zakkemble.net/avr-gcc-builds/
Whether 32 bit or 64 bit is completely irrelevant. If in doubt, use 32 bit. Unpack. And in the Arduino folder, with me portable IDE C:\Arduino IDE Portable\Mega2560\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.5 The part of the path everyone has. ... packages\arduino\hardware\avr\1.8.5
create a local.platform.txt. There is already a platform.txt in the folder, we do not change it. The local.platform.txt gets the following content.
### Adjust path! ###
compiler.path=C:\avrToolchain\avr-gcc-12.1.0/bin/
### C++17 ###
compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++17 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto
### C++20 ###
#compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++20 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -Wno-volatile
### Conservative ###
compiler.cpp.extra_flags=-fno-sized-deallocation -Wall -Wextra
### for the really tough ###
#compiler.cpp.extra_flags=-fno-sized-deallocation -Wall -Wextra -Werror
For all this to make sense, all compiler warnings etc. must be turned on in the IDE's preferences. Restart the IDE and off you go. But as I said. The toolchain with C++17 or even C++20 setting only provides you with the possibility to use the new language features. Old code remains old code. You can continue to use C++11. Then nothing changes. If you have added additional core packages to the IDE, you have to create the local.platform.txt in all package paths.
I know this could be (some? a lot of?) work. But it has to be done anyway?! Someday?! Soon?
Unless you want to stay 10+ years behind the modern C++ forever [?].
So… how about just make an upgrade, fix all the issues and life goes on?
I'm not an expert, but I'm willing to (try to) help.
https://github.com/esp8266/Arduino/issues/8916
So, it is 2023, I recently (days ago) installed platformio for a arduino (teensy) project. Works fine using CLion (apart from me having virtually no C++ experience, yes Python guy here).
However, I was trying to use std::optional. Found this guy #if __cplusplus > 201703L in the <optional> header. So juggled a bit trying maybe stupid things like
build_flags = -I include-Os -g0 -std=c++17 -std=gnu++17
debug_build_flags = -I include -O2 -std=c++17 x -std=gnu++17
build_unflags =
-std=gnu++11
debug_build_unflags =
-std=gnu++11
Guess what: it is not working. Should it? Will it? What would I need to do?
So, it is 2023, I recently (days ago) installed platformio for a arduino (teensy) project. Works fine using CLion (apart from me having virtually no C++ experience, yes Python guy here).
However, I was trying to use
std::optional. Found this guy#if __cplusplus > 201703Lin the<optional>header. So juggled a bit trying maybe stupid things likebuild_flags = -I include-Os -g0 -std=c++17 -std=gnu++17 debug_build_flags = -I include -O2 -std=c++17 x -std=gnu++17 build_unflags = -std=gnu++11 debug_build_unflags = -std=gnu++11Guess what: it is not working. Should it? Will it? What would I need to do?
It doesn't work, because the stl isn't fully "ported" .... but you can implement yourself what's missing. See project ArduinoJSon... all the "conditional" stuff has been manually added, for sure, the same can be done for optional.
So, it is 2023, I recently (days ago) installed platformio for a arduino (teensy) project. Works fine using CLion (apart from me having virtually no C++ experience, yes Python guy here). However, I was trying to use
std::optional. Found this guy#if __cplusplus > 201703Lin the<optional>header. So juggled a bit trying maybe stupid things likebuild_flags = -I include-Os -g0 -std=c++17 -std=gnu++17 debug_build_flags = -I include -O2 -std=c++17 x -std=gnu++17 build_unflags = -std=gnu++11 debug_build_unflags = -std=gnu++11Guess what: it is not working. Should it? Will it? What would I need to do?
It doesn't work, because the stl isn't fully "ported" .... but you can implement yourself what's missing. See project ArduinoJSon... all the "conditional" stuff has been manually added, for sure, the same can be done for optional.
I will absolutely have a look.
The more funny thing is: spent my day yesterday tyring to make any JSON library work for the project. Tried like 3 or 4 different libs (some listed in platformio registry). Most crashed or did not import correctly. The sole reason I came here was because of me writing a wrapper around https://github.com/zserge/jsmn (the one I could bring to live but is quite bare minimum; will try https://github.com/bblanchon/ArduinoJson maybe I can get rid of the wrapper altogether).
https://github.com/bblanchon/ArduinoJson maybe I can get rid of the wrapper altogether).
This one is definitely the #1 for JSon... well implemented, well tested !
Although it is very interesting, I would appreciate it if we can keep this discussion tightly focused on the original subject matter.
You are welcome to continue the other conversations on the Arduino Forum:
https://forum.arduino.cc/
Although it is very interesting, I would appreciate it if we can keep this discussion tightly focused on the original subject matter.
You are welcome to continue the other conversations on the Arduino Forum:
https://forum.arduino.cc/
I mean while the last two messages were off-topic, the initial messages were exactly on-topic (even with some info on how to work around).