ESP32 Ints or Doubles to Strings

[Ziegler]

Does anyone have any luck in converting integers or doubles to strings in ESP32/esp-idf? Ideally, I'd like the function to work over an array of integers or doubles.

I've tried using std::to_string(0) as a proof of concept but I get a compilation error: 'to_string' is not a member of 'std'
std::to_string(0);

Thanks for your time.

[chegewara]

https://fresh2refresh.com/c-programming ... -function/

[PeterR]

No it is missing last time I looked (v4.0-dev).
ostringstream works though, so I use something like:

Code: Select all

std::string ToString(int n)
{
    std::ostringstream stm;
    stm << n;
    return stm.str();
}  

but you could do much better with a template!

'C' sprintf() works of course but actually the default compile usually spots a type error.

[Ziegler]

Thanks PeterR and chegewara. Your suggestions led me to the gcvt function: https://www.geeksforgeeks.org/gcvt-conv ... -string-c/

[PeterR]

Np.
The problem with sprintf() and gcvt() is that their success depends on the size of the char buffer you supply.
This can result in errors (and certainly needs more care) should you write past the end of the buffer.
gcvt() has no buffer size argument, at least snprintf() does.

IMHO your initial approach of using std::string is the better approach - you do not need to think about buffer sizes except (as with 'C' strings) large auto or very very large heap strings.
C++ added std::string for a reason ....

[alx_alx]

Thanks PeterR and chegewara. Your suggestions led me to the gcvt function: https://www.geeksforgeeks.org/gcvt-conv ... -string-c/

Hello, do you have an example of how you used gcvt ? I used #include <stdlib,h> but I still get an error :
error: 'gcvt' was not declared in this scope

Thank you

[PeterR]

Nope, long time back.
Not sure how true the following is, but:
https://www.thinkage.ca/gcos/expl/c/lib/gcvt.html
But gcvt is definitetly 'left field'.
Stick with sprintf or a stream.
Guess you are academic/hobby or you would have gone with the earlier working suggestions already?
Not sure why you want to use something that might not exist when you have alternatives?

EDIT: Actually it is quite clear that gcvt etc are not recommended and that (C) you should use snprintf(). Missed this piece of history as have only ever used snprintf()!
So don't worrry about gcvt being missing, you would be naughty to use it & really you should not spend time trying to be naughty.

[Scott.Bonomi]

A real (as in old school) embedded programmer would just do it manually, with truncating unsigned integer division and modulus arithmetic. One version for over 32 bits and one for 32 or less. Once the digit is identified, adding 30 to make it a character is trivial. Translating from signed to unsigned and remembering the initial sign value is recommended. The result should be a smaller memory footprint than an unknown number of standard library functions. Supporting Multiple concurrent threads is a stack management issue. Blocking interrupts would be a good idea if you let any ISR call the feature.
There needs to be a specific driving reason to take this route. Long term program maintenance is complex after the original developer leaves for greener pastures. The next developer is quite likely to bring in the stdio library for some other reason, making your work obsolete. This approach is fine for driving a LED display or similar technology. However, making completely formatted output is going to be a larger challenge.

[PeterR]

Lol
I would disagree in the sense 'now'. I am a real (as in old school) embedded programmer and firmly believe that hardware engineers (& other lower life forms looking to improve themself) find reasons to program . Good software engineers however look for ways not to program. We know what might go wrong! Now we have the RAM etc we can use third party library tested by exhausion by millions. Now also tested using CI.
Back in the day well yea, we would try to remove libraries but the replacement engineer would not be able to add sprintf() - all the memory would be gone!
Recently had a client ask if I would build a simple serial to TCP product. He suggested using ADA. Did it need to be functionally safe? Oh no. Suggested STM32 using C/C++ etc. EDIT: Did not get the gig. STM32 C/C++ was too radical. Got the gig on disaster recovery a couple of years latter though.
That was a real (as in old school) embedded manager!