[Q] Get rid of String class

[DaeMonSxy]

How about to get rid of String class?
outdated, unstable etc
move the whole lib to char array, or std::string ( there are benefits)

[mathieucarbou]

No, this would be a breaking change. Also, this is a arduino lib and String is used pretty much everywhere.

But if you feel to raise a PR with some macro definitions to swap the String implementation used, please go ahead.

[DRSDavidSoft]

The Arduino's WString class is not outdated, and it is unstable if you don't use it correctly.

Using char array is best since you will have complete control on when to allocate and when to free the memory, however you will need to implement pretty much every conversion yourself. I haven't once seen std::string being used in Arduino.

The WLED fork of ESPAsyncWebServer makes extensive use of the WString class, and it works quite smoothly apparantly:

https://github.com/Aircoookie/ESPAsyncWebServer

[mathieucarbou]

Completely agree.
I also recently overloaded all the methods to support flavors with char* to specifically avoid using Arduino String.

[DRSDavidSoft]

@mathieucarbou This is a good change, a simple string comparison with char* suffices well, it shouldn't depend on Arduino String (WString).

Although, if the type of the provided strings are the same, WString is smart enough to do a pointer comparison (==). In any case I support the move to char* due to performance reasons.

Sadly it makes rebasing WLED's fork a bit more non trivial :(

[DaeMonSxy]

without judgeing,
I have had issues using String in the past, so moved all my codes to char array and or std::string.
(some readings: https://majenko.co.uk/blog/our-blog-1/the-evils-of-arduino-strings-32)

All in all, i came across the idea recently, since all im using this fork for server for both esp32 and esp8266 platforms.
some of my libraries are common for both platforms.
last few days I spent working on esp32 code,
yesterday returned to finish some webserver updates on esp8266 and having crashes all the time, especially with :beginResponse

beginResponse_P seem to work ok, but beginResponse crashing.

so trying to find the issue now, that is the reason I picked up the String std::string char* topic recently

[mathieucarbou]

Did you try the variant with const char* ? esp8266 is quite outdated and will go EOL in 4-5 years. This will come fast. It might be possible to improve its support, but requires someone to do that well.
Me and @vortigont are not using esp8266, and discourage people from using them also, so the esp8266 support is at risk of fading away and not being maintained properly over time if we don't have someone to do that.

[DRSDavidSoft]

@DaeMonSxy That's true. I have been using both WString and char* for quite a while now, and I remember the first time I found the "evils of the arduino string" myself :D

The main issue, as I said, is the incorrect usage of the String class in Arduino. It's not meant to be used like a high level, scripting programming language despite the design looking like JavaScript implementations. You're in trouble if you use the + operator, use .concat(), or re-assign values with a greater length of previously assigned values, without calling .reserve() on the class with a known good pre-determine value. If you look at its source code, you'll see what I mean.

https://github.com/esp8266/Arduino/blob/master/cores/esp8266/WString.cpp

Behind the curtains, the String class is still making use of char* buffer. The main problem is memory fragmentation due to incorrect use of it. The problem is that using String will not prevent you from implementation of bad practices. It will try its best to allocate, copy buffer and so on so that the code you have written is satisfied.

When you use char array you are essentially limiting the program to never allocate to another memory region. You are also dealing with the overflow and how to handle when the content overfills the allocated space yourself. This is why it's suggested to use char *, not that String itself is evil!

This means that if an initial string is allocated correctly, using a simple comparison using this class is harmless. The only harm in using String() is what happens when you assign a value to it, without thinking of repercussions. This is still a microcontroller with limited resources we are talking about.

I don't know how std::string works at all, it seems interesting, I'll read more about it for sure!

[DRSDavidSoft]

@mathieucarbou Sad to see ESP8266 going away in 4-5 years, but I guess due to all advantages of ESP32 it is to be expected. I believe the NON-OS variants will also fade away and in 2030s we have all moved to FreeRTOS and an ESP32 Async WebServer :D

Currently it's not possible to migrate existing deployed projects to ESP32, but I will try to design new projects with ESP32 in mind. I will continue using ESP8266 for small projects for a year or two maybe, but we all have to keep the EOL in mind. 🤝

[mathieucarbou]

I am one of the contributors of Psychic http also and I have started to work on some adapters to facilitate transition from AsyncWS to psychic which is based on esp-idf. But currently, psychic is new and in development and for some use cases consumes more resources.

[DRSDavidSoft]

@mathieucarbou That's so cool to hear! I'm sure in due time PsychicHTTP will take over and we will have an awesome and great library. I remember in early ESP8266 days the development was sparse and fragmented too before it reached a stable state. I'm excited to join ESP32 development soon, too. It will be awesome to migrate existing projects to it and also design new ones entirely based on PsychicHTTP.

[vortigont]

the most benefit moving away from WString would be towards std::string_view. It might significantly reduce number of copy's and perform string operations in-place for things like comparison, trim, substrings, etc...
There are two problems here:

• it requires C++17
• no go for 8266 PROGMEM'ed literals

with c++17 esp32 arduino's toolchain is still using c++11 by default and requires tweaking build flags.
For 8266 - IMHO, I would froze the code in some major release and dropped it's further development :) But, luckily, Mathieu is more conservative here :)))