Add std::basic_stringbuf::view() (IDFGH-14044)

[Mis1eader-dev]

Is your feature request related to a problem?

basic_stringbuf has the method str() that dumps the internal buffer into a newly allocated string.

However, it does not seem to have view(), which is a view into said internal buffer. It is part of the C++ standard.

Describe the solution you'd like.

Have a way to view the internal buffer.

Describe alternatives you've considered.

Tried to create classes inheriting from those super classes, however it's not possible as pptr, egptr, and pbase are protected member variables of basic_stringbuf.

Additional context.

No response

[igrr]

@Mis1eader-dev Could you please add, which IDF version are you using? Could you share the code snippet which fails to compile and the compilation log?

As far as I can see, recent toolchains already support this: https://godbolt.org/z/jocKq7YPj. So either you are using an older version of IDF where the toolchain didn't yet support C++20, or the specific translation unit is not compiled with C++20 or later standard.

[Mis1eader-dev]

@igrr I'm using platformio, and today updated the Espressif32 platform to version 6.9.0, which claims has an IDF version of 5.3.1.

I have the following compile flags and unflags:

build_flags =
	-std=gnu++2a
build_unflags =
	-std=gnu++11

[atanisoft]

@Mis1eader-dev v5.3.1 defaults to gnu++20 by default (from my testing) so your build_unflags will have zero effect. I'd expect this may turn out to be a version issue on the PIO side (it may not be using the declared compiler versions for v5.3.1) or you have something off in your platformio.ini file possibly (besides the build flags)

[igrr]

v5.3.1 defaults to gnu++20

Should be C++23, docs, code.

I am not very familiar with PIO build system, but I'd recommend making it print the whole compiler command line on failure and then seeing which flags are passed to the compiler. I am guessing that something sets the C++ version to a lower value than IDF's default. Maybe after looking at the compiler command line you can find where that happens.

[atanisoft]

Even better if it defaults to 23 now :)

EDIT: looks like the docs are claiming gnu++23 but the code uses gnu++2b, a minor difference but required from GCC side (for now) but LLVM supports both c++2b and c++23

[atanisoft]

@Mis1eader-dev Looking at the actual versions that PIO is pulling in a much older version of GCC than included by ESP-IDF v5.3.1: https://github.com/platformio/platform-espressif32/blob/268f561df4793d631d02e4ff5e67b6b11d1be4ec/platform.json#L36. This looks related to their using arduino-esp32 2.x versions still for most tools.

I'm not sure if there is a good way to upgrade other than move off of platformio and use esp-idf directly.

[Mis1eader-dev]

@atanisoft I looked into the project's build idedata.json and it has this entry in its "defines"

IDF_VER="v4.4.7-dirty"

With the following compiler flags

["-std=gnu++2a", "-Wno-frame-address", "-fexceptions", "-fno-rtti", "-Os", "-mlongcalls", "-ffunction-sections", "-fdata-sections", "-Wno-error=unused-function", "-Wno-error=unused-variable", "-Wno-error=deprecated-declarations", "-Wno-unused-parameter", "-Wno-sign-compare", "-ggdb", "-freorder-blocks", "-Wwrite-strings", "-fstack-protector", "-fstrict-volatile-bitfields", "-Wno-error=unused-but-set-variable", "-fno-jump-tables", "-fno-tree-switch-conversion", "-MMD"]

And seems to use GCC 8.4, just like you suggested

toolchain-xtensa-esp32\\xtensa-esp32-elf\\include\\c++\\8.4.0

[Mis1eader-dev]

I'll make an issue on the other repo and link back here

[Mis1eader-dev]

Found a fork of platform-espressif32, I'll try to use that instead