Hello,
How do I get over this error without having to typecast the strings to (const int8_t*) every call?
It's quite a weird error since int8_t is just a typedef for char.
Darius
Let us see the code first. Why can't you just stick with const char*?
Here is the code but it's irrelevant i guess:
void LCD::prints(const int8_t * string)
{
const int8_t * ptr = string;
while( *ptr != '\0')
{
printc(*ptr);
ptr++;
}
}
lcd_driver.cpp:24:20: error: invalid conversion from ‘const char*’ to ‘const int8_t*’
lcd_driver.cpp:24:20: error: initializing argument 1 of ‘void LCD::prints(const int8_t*)’
Line 24 is the line with "const int8_t * ptr = string;".
Of course, I create a class (namely lcd) and call the function with lcd.prints("string");
I use <stdint.h> to better see the size of the variables. I never had a problem with this until avr-g++.
Here is the code but it's irrelevant i guess:
void LCD::prints(const int8_t * string)
It is most certainly not irrelevant. Using anything other than char * for functions that operate only on chars seems pretty dumb to be. Just create a function that takes the proper argument type, and call the function that takes the improper argument type from that function, with a cast.
I'm not interested in workarounds. There are more than one, certainly. You can do it with a function, you can do it with a macro, you can do whatever to solve the issue.
The thing is, it seems like it's a compiler problem. That's what interests me. Is it or it ain't a compiler problem?
cphus:
I'm not interested in workarounds. There are more than one, certainly. You can do it with a function, you can do it with a macro, you can do whatever to solve the issue.The thing is, it seems like it's a compiler problem. That's what interests me. Is it or it ain't a compiler problem?
It's a design flaw. I can't see from here whether the flaw is within your code, or a library you're using.
The API to the LCD looks reasonable - it's displaying printable characters provided as chars.
For some reason you're passing in printable strings held as arrays of integers. To me that looks like a poor design choice, but maybe you have a reason. You could fix it by addressing the original flaw and correct the storage of the string to reflect the fact that they are characters. Or, you could leave that unresolved and fix it at this point, by explicitly casting between the two types. PaulS' suggestion of providing an overloaded function which normalizes the argument types is a conventional and clean approach and is what I'd do, if it wasn't possible to eliminate the problem by choosing the appropriate storage type in the first place.
Is it or it ain't a compiler problem?
It is not. There is a method defined, that takes a number of arguments of specific types. There is a function call, presumably to that function. The compiler tries to match the function call to a specific function. If it succeeds, because all the arguments in a call match the arguments in a method, everything works.
If there are issues, because there is no proper match, the compiler will try to use the function that is the best match, as long as the argument conversions can be done with no loss of data.
If that is not the case, the compiler tells you that you need to make the function call match the function definition better. If you KNOW that no loss of data will occur by using a cast, then use a cast.
An interesting thing I noticed:
Given the definition of int8_t in <stdint.h>
typedef signed char int8_t
const int8_t * should be the same for the compiler as const signed char * and not const char * (which is the type of the strings when you just pas a string like prints("blahblah"))
I called the function like this:
- prints((const char *)"blahblah") and I get errors
- prints((const signed char *)"blahblah") and it passes the compilator/linker/whatever
- prints((const signed int8_t *)("blahblah")) and again it succeeds since it's the same code as above
Might this be the key?
If I'm recalling well, the difference between signed char and char is that signed guarantees that char is signed. That is, there can be variables declared as char that are unsigned or signed. There is a difference for the compilator ultimately!!
#typedef signed char int8_t
?
If I'm recalling well, the difference between signed char and char is that signed guarantees that char is signed.
Exactly. By default, char is not signed.
There is a difference for the compilator ultimately!!
Precisely.
no #, sorry
i wanted to write somethng about a #define at first. i'll modify it in the post.
thanks guys 
cphus:
lcd_driver.cpp:24:20: error: invalid conversion from ‘const char*’ to ‘const int8_t*’
lcd_driver.cpp:24:20: error: initializing argument 1 of ‘void LCD::prints(const int8_t*)’Line 24 is the line with "const int8_t * ptr = string;".
Of course, I create a class (namely lcd) and call the function with lcd.prints("string");
Are you sure you have your line numbers right? This is probably dying in the "lcd.prints("string")' line.
If you absolutely must do this, you can shut up the compiler thusly:
lcd.prints((const int8_t*)"string")
The better fix is to change the LCD class to not take int8_t*'s, which is somewhat absurd.