Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support C++17 by default #435

Open
Silver-Fang opened this issue Nov 14, 2021 · 21 comments
Open

Please support C++17 by default #435

Silver-Fang opened this issue Nov 14, 2021 · 21 comments

Comments

@Silver-Fang
Copy link

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?

@FredM67
Copy link

FredM67 commented Nov 14, 2021

Yes, please change to C++17...

@mikrocoder
Copy link

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.

@grobx
Copy link

grobx commented Aug 23, 2022

Any plan to switch to C++17 by default?

@mikrocoder
Copy link

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.

@grobx
Copy link

grobx commented Aug 24, 2022

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.

@mikrocoder
Copy link

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.

@grobx
Copy link

grobx commented Aug 25, 2022

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?

@mikrocoder
Copy link

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.

@Silver-Fang
Copy link
Author

@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.

@grobx
Copy link

grobx commented Aug 26, 2022

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.

@mikrocoder
Copy link

@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.

@matthijskooijman
Copy link
Collaborator

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).

@mikrocoder
Copy link

mikrocoder commented Aug 27, 2022

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.

@s-light
Copy link

s-light commented Jan 26, 2023

similar old request:
Bump AVR c++ standard to 2014 from 2011 #7090

@MacDada
Copy link

MacDada commented Apr 26, 2023

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.

esp8266/Arduino#8916

keke1008 added a commit to keke1008/heterogeneous-network that referenced this issue May 13, 2023
c++20移行にしたければ,以下が参考になる.

arduino/ArduinoCore-avr#435 (comment)
keke1008 added a commit to keke1008/heterogeneous-network that referenced this issue May 13, 2023
c++20以降にしたいなら,以下が参考になる.

arduino/ArduinoCore-avr#435 (comment)
@Mereep

This comment was marked as off-topic.

@FredM67

This comment was marked as off-topic.

@Mereep

This comment was marked as off-topic.

@FredM67

This comment was marked as off-topic.

@per1234
Copy link
Contributor

per1234 commented Jul 18, 2023

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/

@Mereep

This comment was marked as off-topic.

@arduino arduino locked as too heated and limited conversation to collaborators Jul 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants