Datatype 'int' - Overloaded functions - 16bit / 32bit


Just have a query about how 'int' is handled in libraries with overloaded functions, which are to be used on Arduino boards where some handle the 'int' as 16bit and some handle the int as 32bit.
What is the normal method for handling this?

We have a library we are writing which we have a function which is overloaded, each taking a parameter of int16_t, int32_t and float, and the compiler (in this case for the Pi Pico) doesn't know where to assign the int that is going into the function, to which overloaded function etc.

Typecasting the input to int32_t works, but I am just curious about what is the normal practice for handling this type of thing for libraries which support many Arduino boards which handle the type 'int' differently.

I hope that makes sense


i'm curious.

so the problem is you have functions that accept "int" arguments, but aren't sure how to treat them.

what if you copied them to an int_16 and process them their values using the int16_t value. so that the library is at least consistent?

would you need to reject (return error) an "int" argument value that exceeds the max values of int16_t

Sort of..

We have say 3 overloaded functions which take 2 parameters each, as an example.

bool Controller::DigitsValue(uint8_t index, int16_t value) {

bool Controller::DigitsValue(uint8_t index, int32_t value) {

bool Controller::DigitsValue(uint8_t index, float value) {

but if someone uses say a constant value, then we get an error when compiling of it being ambiguous etc.

I think its possible an issue we need to handle in the demo, not in the library as such, I am not sure, just trying to get my head around how to get the compiler (likely different compilers) how to handle 'int' if really its int16_t for one and int32_t for the other.

Sorry if its not clear what I am trying to ask

On an 8-bit AVR, an 'int' is 16 bits (int16_t). On an ARM or ESP processor, it's 32 bits (int32_t). The compiler should be able to figure it out. For further advice, post your actual code and the actual error messages - not your paraphrased version of them.

isn't that a good thing, forces the developer to cast it to something that matches your function. i'm always struggling with const chars

This can be closed.

So what was the solution?

From some experimenting it looks like you get an "ambiguous" error when there is no exact match and more than one conversion possible. Either add functions for the inexact matches or cast the values to an exact match.