You will be storing pointers to RAM into the EEPROM,
for Strings only the descriptor is saved, not the buffer that contains the data.
While it may seem to work directly after storing it, it will fail after a restart,
because the RAM content probably changes.
Thanks so much for taking time to explain that so well to me. I have stored arrays of strings successfully using EEPROM.put() and it has always magically worked for anything I threw at it before so I didn't see why it wouldn't do so with String as well. Now I understand.
Do String manipulation to add shotgun the heap to that.
I meant "Is it doing something more horrible than usual to the memory?".
Just wastes bytes doing so little. Do String manipulation to add shotgun the heap to that.
Worst thing it does is teach a coder to use convenient do-it-for-you String objects while buying boards with more RAM to contain the mess that would happily run on less RAM with C char array strings.
What are BAD HABITS worth?
Yes and that is well documented.
Global warming is a hoax, cigarettes are actually good for people and Mexico will pay for the wall.
And if you can believe that then use freaking Strings in your project as long as you understand that asking for help will get you told to take the damn things out for your own sake!
I never intended to imply that I recommend ever using String in an embedded system. I would never do that and I'm sure you've seen me do just the opposite in the past. I assumed we had already gotten past that in #1. Looking back, I can see how the point of using strings instead of String might not have been as clear as it could be at that point. In my #3, I actually was not even thinking of arrays of Strings. #4 was the first time I considered that and my response was merely a matter of wanting to learn, rather than an argument in favor of using String, even if it did happen to work with EEPROM.put().