Open Sod-Almighty opened 6 years ago
''' getTextBounds(char string, int16_t x, int16_t y, int16_t x1, int16_t y1, uint16_t w, uint16_t h), getTextBounds(const __FlashStringHelper s, int16_t x, int16_t y, int16_t x1, int16_t y1, uint16_t w, uint16_t h); ''' It's only defined for char and flash strings. If you define a const char, it's probably best to define it as flash string anyway, that way it'll reside in progmem which is larger on most platforms.
pj
Perhaps I should be more specific. I already knew the function signatures; what I meant was "why didn't you make the function accept a const char*
instead, given that it doesn't modify the string?"
Limiting it to mutable strings serves no purpose, and necessitates an explicit const-removing cast, in clear violation of good programming practice.
I'm using an ESP8266. Not only does it have plenty of RAM, it also doesn't seem to properly support the Flash
library or the F()
macro.
Is this due to the issues with const on small microcontrollers with separate data and code memory spaces. I know PICs do this, 8051 and AVR as well I believe. On some implementations "const" was used to indicate the destination is in ROM, so a const pointer can only point to program memory and not RAM.
Oddly enough microchip XC8 does not appear to have this limitation.
I have never heard of such a limitation. But in any event, nothing stops there being two versions of the function, one const and one non-const. Having to explicitly cast away constness is bad programming practice.
@Sod-Almighty I'm sure you are aware of the fact that this is open source software being developed in a collaborative way. You are of course free to fork it, write the suitable overloads for your needs, test them and create a PR. As it sais in the code:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
I've done this PR #130 quite some time ago, it also allows to pass String() to getTextBounds()
I cannot pass a
const char*
togetTextBounds()
. Why not?