[SOLVE]enum on UNO versus DUE: why DUE need static_cast ?

Hi.

here a little example of a problem I got, I know how to fox it but I do not understand why it work on UNO and not on a due...

if you take an enum and try to assign it an int, it work on UNO but did not compile on a DUE. here a quick example:

enum foo { bar, foobar, barfoo };

void setup() {

 int valueToEvaluate = 2;
 foo myFoo = valueToEvaluate; //this compile only on UNO
 //foo myFoo = static_cast<foo>(valueToEvaluate); //this is a DUE version that compile
 //do some switch... 

///  ===>>error: invalid conversion from 'int' to 'foo' [-fpermissive]

  foo myFoo = valueToEvaluate; 
}

I want to better understand what append, and is there a way to avoid it in the enum declaration.

There are two different compilers being used. Uno uses avrgcc while Due uses arm-none-eabi-gcc. Different compilers, different tolerances towards implicit casting?

What underlying type is used to store the enum? Why do you assume int on both the Due and the Uno, when they use different size ints?

What underlying type is used to store the enum? Why do you assume int on both the Due and the Uno, when they use different size ints?

those kind of thing are not quite totally clear to me..
For example you can do:

enum foo { bar, foobar, barfoo };
int val = 0;
switch (val) {
case foo:
dosomething();
break;
}

it will compile and consider foo as numerical value... but it is not working on assignement..

ps.: just fix the typo on the initial post... wasn't num but enum...

Once again it's that >:( >:( >:( -fpermissive >:( >:( >:( that is enabled in the AVR core.
It was added there after a number libraries failed to compile with GCC 4.9.

use
enum {}
or
enum struct foo {}
not
enum foo {}

The language is just trying to be more safe-typing. Some stuffs you cannot do anymore.

Think I got it.
For the difference between UNO and DUE, @DKWatson response was helpful.

Thanks every one.

found this link:

mentioning this... and a good explication about enum and strong-typing. good reading.

C++0x, scoped enums

There is one more issue with our enums: size and signedness. Is it coherent across different compilers? No, it's not. According to the C++ standard, the underlying type of an enum is semi-defined, because the compiler can choose what integral type to use to represent the enums, so that the type is less then an int if all enum values can be represented with int. Otherwise, it can be any other, bigger type.