What's the latest on using C++17?

I would like to gain access to certain C++17 features for my projects which primarily use ESP32 and AT MEGA 2560 processors. I set my c++Standard to c++17 but that does not seem to help me. The discussion on this that I find in the forum is over 18 months old so I imagine a lot has changed since then. Below is a typical platformio.ini file for my projects which would be built to run on either of these two processors. Is there a setting in the platformio.ini that I need to add? Also, any adverse impact to libraries if I try to make this change?

Thanks!

[common]

build_flags = -fmax-errors=5

    -I./src/

    -I./src/utils/

lib_ldf_mode = deep

lib_extra_dirs = ~/Documents/Arduino/libraries

lib_deps =

    mikalhart/IridiumSBD@^2.0

    sparkfun/SparkFun Swarm Satellite Arduino Library@^1.1.8

    sensirion/Sensirion I2C SEN5X@^0.2.0

    paulstoffregen/OneWire@^2.3.7

[platformio]

default_envs = um_feathers3

[env:megaatmega2560]

platform = atmelavr

board = megaatmega2560

board_build.variants_dir = variants

board_build.variant = mcupro

framework = arduino

build_flags = ${common.build_flags}

lib_ldf_mode = ${common.lib_ldf_mode}

lib_extra_dirs = $common{common.lib_extra_dirs}

lib_deps =  ${common.lib_deps}

upload_port = COM6

monitor_speed = 115200

[env:um_feathers3]

platform = espressif32

board = um_feathers3

framework = arduino

build_flags = ${common.build_flags}

lib_ldf_mode = ${common.lib_ldf_mode}

lib_extra_dirs = $common{common.lib_extra_dirs}

lib_deps =  ${common.lib_deps}

upload_port = COM6

monitor_port = COM6

monitor_speed = 115200

Should be no problem with the current toolchain, just make sure to build_unflags = -std=gnu++11 (to get rid of the default) and add build_flags = -std=gnu++17.

The C++ STL support in avr-g++ was always terrible, even in the latest-greates AVR-GCC/G++ 12 compilers. However, as you can see in

if you choose a board definition that uses the alternative MegaCore (which suppoerts ATMega2560 too), it gives you GNU++17 already. So just ues board = ATmega2560 and the language features should work out of the box.

Hi Max,
Thanks for that rapid reply. Unfortunately, I did not experience success with those changes. I made a smaller test case and I got a few namespace errors indicating to me that it was still not using c+17

namespace “std” has no member “variant”
namespace “std” has no member “visit”

just a bit of the code… for that first namespace error:

#include <iostream>

#include <typeinfo>

#include <variant>

using AT = double;

using PT = unsigned long long;

using R = std::variant<AT, PT>;

and my platformio.ini (in case I did not understand you correctly…

; PlatformIO Project Configuration File

;

;   Build options: build flags, source filter

;   Upload options: custom upload port, speed and extra flags

;   Library options: dependencies, extra library storages

;   Advanced options: extra scripting

;

; Please visit documentation for the other options and examples

; https://docs.platformio.org/page/projectconf.html

[env:um_feathers3]

platform = espressif32

board = um_feathers3

upload_port = COM6

monitor_speed = 115200

build_unflags = -std=gnu++11

build_flags = -std=gnu++17

    -fmax-errors=5

    -I./src/

    ;-I./src/utils/

lib_ldf_mode = deep

lib_extra_dirs = ~/Documents/Arduino/libraries

framework = arduino

lib_deps =

    # mikalhart/IridiumSBD@^2.0


    # sparkfun/SparkFun Swarm Satellite Arduino Library@^1.1.8

    # nvirodiy/SDI-12@^2.1.4

Works.

Use PIO Home → Platforms → Espressif 32 → Update if needed.

Hi Max. As always, you are correct… I left out the Arduino.h include… BUT, I am still having issues with C/C++ intellisense highlighting namespace errors for std::variant and std::visit. I am running C/C++ Extension Pack v1.2.0 and have set C/Cpp > Default:Cpp Standard to c++17. Is there a setting I am missing to get the intellisense to not show these “errors”?

Hi Max, I am having the same issue.

Above is my platformio.ini, main.cpp and the error. Setting the c++ standard to c++17 did not help.

Why #include <variant.h> instead of #include <variant>?

Thank you, I have no idea why i did variant.h. It is working now.