Current version of g++ in Arduino IDE

Projects Programming
1

Today I found out that Arduino IDE supports designated initializer syntax, which was introduced as a part of C++20 (and C99, but that's a different story).

Does it mean g++ in Arduino IDE 1.x was updated to C++20 standard?

I mean code like this:

struct Foo {
    int a,
    int b
};

Foo bar = {.a = 5, .b = 7};

Documentation: Aggregate initialization - cppreference.com

Update: I use MiniCore for AVR MCU. Perhaps it may affect g++ version.

2

Compiler doesn't like the comma.
This seems to work:

struct Foo {
    int a;
    int b;
};

Foo bar = {.a = 5, .b = 7};

At least the compiler doesn't complain.

1 Like
3

Yes, thank you for the correction.

4

That would be nice, however, I suspect that the compiler simply allows it and issues a warning you may not see. When I compile something similar I see the following.

warning: ISO C++ does not allow C99 designated initializers [-Wpedantic]
1 Like
5

My understanding is that a compiler version which does not support designated initializers wouldn't simply throw a warning, it would rather report an error due to use of unknown syntax. Am I wrong?

Which core do you use? Mine is MiniCore, and I get no warnings. Also I tried cores for ESP32 (required additional definition of LED_BUILTIN, but worked), ESP8266 (complained about void function not being explicitly terminated by return statement, but worked) and STM32F103C8T6 (worked without any warnings).

6

Or was it the missing semicolon or was it the extra int?


struct Foo {
    int a, b;
};

Foo bar = {.a = 5, .b = 7};

a7

7

Why not try:

void setup() {
  Serial.begin(115200);
  delay(1000);
  Serial.println(__cplusplus);
}

void loop() {
}
8

Now I did. 201703, which stands for C++17. More to my confusion.

9

The compiler itself probably supports C++20 and beyond, however, it is instructed to adhere to the C++11 standard, including some GNU extensions, by the compiler options given by the Arduino toolchain (-std=gnu++11).

At the same time, the compiler is instructed to be lenient when it comes to using constructs that are not supported by the selected standard and those that are "wrong" but admissible for other reasons (-fpermissive). Furthermore, warnings are suppressed by default, so many of these admissible violations go unnoticed.

If you want to be informed about these violations, you could enable the -Wall, -Wextra and -pedantic compiler options, perhaps in combination with the -std=c++11 option to make sure no GNU extensions are used.

I looked at the compiler options for the AVR core by the way, it could be that other cores use different options.

1 Like
10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.