Oh boy this reply got quite long!!! :o :o :o
Robin2: The problem is the word "maybe" :)
Without trying, I can't be sure of anything.
DKWatson: Enhance your skills and develop (or Google) macros and/or functions that provide similar functionality. In fact you can get carried away and end up with a library that offers capability beyond that of the String class.
Yeah I could, but is not my goal right now. Anyway, I bet there are already some libraries that extend this funcionality, as you said.
PieterP: Using less intuitive cstring functions does not make you a better programmer.
Not better, but more experienced.
My definition of "better programmer" is the one who knows how to apply all the good practices of programming. Doesn't need to create perfect code at the first time; even large software develop companies have to release patches/updates to fix some stray bugs or oversights that couldn't be noticed no matter how much they tested.
PieterP: If you reserve enough memory beforehand, and you see to it that not too many intermediate Strings are created, you won't run into trouble, especially if you have such a large heap as on the ESP.
Probably that is, but who knows... real life is never that easy.
Danois90: if I would venture into using the String class, I would program my sketch to monitor the amount of free, dynamic memory very carefully. If at any point the available memory drops below 5-10%, I would "alarm the user" somehow.
This could work fine if fragmented free space is also counted. The method usually looks for the furthest byte (position) ever allocated to something, but doesn't take in account whatever is in between (e. g. destroyed objects creates free space, if it was between other data, then it's fragmented free space).
PieterP: The amount of free memory doesn't tell you anything about the fragmentation level.
That's exactly what I said just before.
J-M-L: for example when you use + (concatenate) operations that will allocate a temporary
StringSumHelper- even if you used plenty of pre-allocated space for the function.
So C-strings are safer anyway?
J-M-L: So you have very limited control on what's really happening... and long running system will possibly be impacted over time, which drives developer to handle this by rebooting their system from time to time to clean up...
That's what I'm afraid of...
J-M-L: so all bets are already off if you rely on those libraries...
I have planned to use mostly some of the core libraries (Wi-Fi controller, TCP server, serial controller for the Bluetooth terminal/console, UDP client if I plan to use NTP for logging purposes), and another one for password storage with SHA-256 hashing (probably I'm gonna use the virtual EEPROM or files from the internal SPFS). Hope I'm not in trouble already.
Danois90: If the amount of free heap is reported as 20k, and you cannot allocate a buffer of 2-5k, that would indicate that fragmentation may become an issue.
Then it's matter of testing it out.
Although I'm thinking: if objects are constanly created but inmediately destroyed (let's say because of how String concatenation works), fragmentation shouldn't occur as long as somehow another object or array isn't allocated outside of the function's code (i. e. due to an interrupt).
Robin2: If that happens is there anything you can do to fix it, apart from re-booting?
Danois90: I do not think there is any feature to "defragmentate" memory.
Also called "compaction", it's the last stage of garbage collecting. Since that implies moving entire blocks of data, the process becomes pretty time-consuming; and also will block the program execution (even disable interrupts to avoid race condition) if no multitasking capability is available.
Danois90: But knowing (in code) that there is a problem evolving, makes it possible to issue a reset before the device locks up.
In code, only if you can tell me that the restart() function from the ESP SDK (available in the Arduino IDE as well, inside an object called "ESP"), provokes an actual "reboot" rather than a simple "soft-reset".
Another solution is some kind of hardware watchdog timer; you know, the timer that triggers a reset if it isn't restarted after certain timeout. When the execution freezes for whatever reason, the microcontroller is no longer able to restart that timer; thus eventually this watchdog kicks in and triggers the same reset as if you pushed the button.
Does the ESP8266 have one? If it does, then I'd have no more to worry about.
econjack: It seems to me your coding style is geared to working around an issue that you know exists even though a tighter approach mitigates the problem altogether. It makes even less sense since you know how to use C strings and, thus, avoid the problem. Why would you do that?
On an ATmega328P I have no doubt that C-strings are the way to go; however, in an enviroment with more RAM like the ESP8266, I might give myself the luxury of using String instead, without compromising reliability. The point of this thread is to discuss if that last (bolded) statement is true or not.
Robin2: The String class can bite you even if the program is perfectly written
That's why I have such negative preconception with String.
wildbill: If you make use of Strings, even with this much RAM, you're gambling that everything will be ok. If this is a 24/7 application, that gamble may not bite you for days, so you're never certain that your testing was enough. In the end, it comes down to how critical the application is and what the consequences will be if it crashes - you just have to decide whether to accept the risk.
So... I guess I can take it. The application isn't that critical, but an unresponsive device is annoying nonetheless.
econjack: I was arguing that he sees them as the solution to a problem that can be avoided by other, less risky, alternatives. His alternative is a "work-around" for a known problem when a simple, viable, alternative that he knows how to code and understands, exists.
And you are right.
But the project isn't that big anyway (unless I decide to make it commercial); so that's why I am not necessarily looking for optimization but simplicity and workarounds for any possible caveat.