Missing std::to_string C++ support (libstdc++) (IDFGH-133)

[paulreimer]

I notice that std::to_string support is missing from the libstdc++, not sure what it takes to get that added, but it is useful especially when porting other C++11 code.

Specifically, the following app_main should work. The example usage is directly from cppreference:
http://www.cplusplus.com/reference/string/to_string/
(it currently fails to compile)

// to_string example
#include <iostream>   // std::cout
#include <string>     // std::string, std::to_string

#ifdef __cplusplus
extern "C"
#endif // __cplusplus
void app_main()
{
  std::string pi = "pi is " + std::to_string(3.1415926);
  std::string perfect = std::to_string(1+2+4+7+14) + " is a perfect number";
  std::cout << pi << '\n';
  std::cout << perfect << '\n';
}

The error I see when running make:

./hello_world_main.cpp: In function 'void app_main()':
./hello_world_main.cpp:10:31: error: 'to_string' is not a member of 'std'
   std::string pi = "pi is " + std::to_string(3.1415926);
                               ^
./hello_world_main.cpp:11:25: error: 'to_string' is not a member of 'std'
   std::string perfect = std::to_string(1+2+4+7+14) + " is a perfect number";
                         ^
make[1]: *** [hello_world_main.o] Error 1
make: *** [component-main-build] Error 2

[igrr]

Some libstdc++ features which depend on C99 support in C library are currently unavailable, because GCC 5.2.0 incorrectly checks for these C99 features during configuration step. We plan to switch to a more recent version of GCC in the future, which will also fix this configuration issue.

[paulreimer]

Fair enough, is there a workaround or patch currently? I am already building my own toolchain using ct-ng (I assume you mean GCC 5.2.0 gets it wrong for the configuration step during toolchain build).

Is this PR in the direction you are going? Seems... too easy? And not sure how to fully test it. However if a fully tested toolchain release will be coming within a month or two, I can probably get along fine with this patch:
espressif/crosstool-NG#2

[PerMalmberg]

I've been wanting to use std::to_string() too. Today I took the time to dig into the source and found that adding this to your component.mk allows usage of std::to_string(),

CPPFLAGS += -D_GLIBCXX_USE_C99

I don't know if there are any side effects, seems to work fine though.

[paulreimer]

@PerMalmberg I can confirm that seems to work for me. I'm applying it selectively to the files that need it (i.e. are using std::to_string).

I'm also curious about any potential downsides? And/or if we will be getting a significantly new toolchain version any time soon?

[PerMalmberg]

Half a year later - how is the time schedule looking for switching to a new gcc @igrr ?

[igrr]

@PerMalmberg There is a preview version of toolchain based on GCC 8.2 available now, please see https://esp32.com/viewtopic.php?f=10&t=7400.

Will keep this issue open while the new version is in preview.

[PerMalmberg]

Nice, @igrr . I just finished a new design based on the ESP32 so I'm going to start working with this again. Currently setting up a new dev system and will also have to convert my Smooth framework to use CMake also when built for ESP-IDF (it already uses CMake when compiling for Linux so that should be fairly easy).

[igrr]

Just a heads up, there is currently an issue when using GCC8 based toolchain with CMake build system, due to a linking issue the application is non-functional. Other combinations: GCC5 + CMake, GCC8 + Make, GCC8 + (linker from GCC5 based toolchain) + CMake — all work fine. Fix is currently in review.

[PerMalmberg]

Thanks for the heads up. I saw the forum post re. that. It'll probably take another week before I can try out gcc8.

[PerMalmberg]

@igrr Hows the linker fix coming along?

[igrr]

Fixed in 9240bbb, sorry that I forgot to tag this issue.

[lucascoxBAF]

@igrr Before we switch to it, do you think the GCC 8.2 toolchain is relatively stable? We've have to do some extensive refactors on some of our source code because it uses std::any, std::optional, and lots of non-trivial return constexprs in c++. Just curious if you think it's potentially stable enough to switch to.

Oh, and we're using the CMake build system.

[huaminghuangtw]

component.m

Hi, how can I find this file: component.m?

[bhcuong2008]

I've been wanting to use std::to_string() too. Today I took the time to dig into the source and found that adding this to your component.mk allows usage of std::to_string(),

CPPFLAGS += -D_GLIBCXX_USE_C99

I don't know if there are any side effects, seems to work fine though.

For me, it's ok, but whether any side effects?
I couldn't use the new toolchain 8.4 for IDF v3.3.5. Is there any other methods to fix this besides CPPFLAGS += -D_GLIBCXX_USE_C99?

[podaen]

I confront this many times, it not presented. I solve it like this. Don't think I am facing issues with this, but I rather want to use
const char*.

  String str = String(MyInt);
  esp_mqtt_client_publish(client, "test/bye", str.c_str(), str.length(), 0, false);