Num=max(Num,3); throws compiler error if Num declared int8_t. Really?

[JacktheRipper]

Of course, it works just fine on any AVR board. But with the compiler used for ESP32s one must code
Num=max(Num,(unt8_t)3); Seems like a bit of C++ rigor overreach to me.

[tommeyers]

I looked up the max function and it says the two values need to be the same type.

A constant 8 has a dats type of short. I imagine the data type of num is not.

The data type of an integer data type is determined by its value.

Tom

[JacktheRipper]

I saw that, and I'm wondering what the value of such rigor would be. Curiously, Num=max(Num-1,4) compiles just fine. I suppose the arithmetic forces the data types to be sorted out automatically.
I've never heard of a "dats" type, and the C++ reference doesn't mention it anywhere that I could find.
The Arduino reference is a little more generous:
"Parameters
x: the first number. Allowed data types: any data type.
y: the second number. Allowed data types: any data type."
And, yes, I know that Arduino C is not a "real" C++ language, but it certainly has its utility for the purpose. Thanks for your insights...Jack

[tommeyers]

I am traveling and without my dev software. Or, I would check this: what is the data type of Num - 1
When num is small and when large. I suspect they are different.

So Max has a to be defined data type and a defined data type to compare.

Max(num - 1, num - 3) should fail too.

In the original it has both data types (different) and refuses to convert for comparison.

This will give us a glimpse into the compiler logic for code generation or more.

Tom
(It is bad form to ridicule someone, giving free help, for a typo.)

[JacktheRipper]

First of all, please be aware that I thought the word "dats" was actually a legitimate word somewhere in the C++ language, one that I did not know anything about. I did, indeed, try to find a reference to it. My statement wasn't meant to be a criticism at all. Sorry for the confusion, and sorry to be clueless on seeing that it was a simple typo.

As for what works and doesn't work when compiling, I wrote the following code:

Code: Select all

template <typename T>
inline T const& Max (T const& a, T const& b) {
  return a < b ? b : a;
}

void setup() {
  Serial.begin(115200);
  delay(1000);
  int NumAs_int = 5;
  long int NumAs_long_int = 5;
  int8_t NumAs_int8_t = 5;
  int16_t NumAs_int16_t = 5;
  int32_t NumAs_int32_t = 5;

  NumAs_int = max(NumAs_int, 6);
  //  NumAs_long_int = max(NumAs_long_int, 6);
  //  NumAs_int8_t = max(NumAs_int8_t, 6);
  //  NumAs_int16_t = max(NumAs_int16_t, 6);
  //  NumAs_int32_t = max(NumAs_int32_t, 6);

  NumAs_int = Max(NumAs_int, 6);
  //  NumAs_long_int = Max(NumAs_long_int, 6);
  //  NumAs_int8_t = Max(NumAs_int8_t, 6);
  //  NumAs_int16_t = Max(NumAs_int16_t, 6);
  NumAs_int32_t = Max(NumAs_int32_t, 6);
  
  Serial.print("NumAs_int:      "); Serial.println(NumAs_int);
  Serial.print("NumAs_long_int: "); Serial.println(NumAs_long_int);
  Serial.print("NumAs_int8_t:   "); Serial.println(NumAs_int8_t);
  Serial.print("NumAs_int16_t:  "); Serial.println(NumAs_int16_t);
  Serial.print("NumAs_int32_t:  "); Serial.println(NumAs_int32_t);
}
void loop() {
}

All of the lines commented out throw a compiler error when compiling for an ESP32, for the reasons you described above, and all work fine for an AVR. Interesting that the template process allows int32_t to sneak in and work OK for an ESP32.

I went down this bunny hole after reading another post in this forum about arithmetic that uses int variables taking longer to execute than arithmetic using int16_t or int32_t variables. I had a piece of code where efficiency was important, and I converted some int declarations to int16_t, and the fun began.

And I fully recognize that the AVR compiler operates at a level of abstraction targeted to makers wanting to blink LEDs, read sensors and move servos, and that a professional software engineer writing critical firmware for an ESP32 has different needs and expectations about C++ rigor.