String vs. string

I see it mentioned on this board at least every other day - using Strings rather than strings can cause heap big trouble. Is this just because Strings exist in the program or, do the problems arise when Strings are manipulated?

In the snippet attached the Strings are only used to print menu text. Potential trouble?

String screens[numOfScreens][2] = {{"Motor Voltage","Volts"}, {"Motor Current", "Amps"}, 
{"Motor Rated HP","HP"},{"Overload Temp.","degC"}, {"Accel Time", "Secs"}, {"Restart Time","Mins"},
{"Analog Out. Curr.","mA"},{"Input Temp.","degC"}, {"Run Time", "Hours"}, {"Start Times","times"}};

Youtube link to source tutorial

The problem with the String class is the fact that the code moves things around in memory. The places where data was moved from don't get returned to the heap instantly. That's fine when you have 2 gigabytes to play with. But not when you have 2 kilobytes.

For fixed text the F macro will save a lot of memory,

...R

I did a test of that string array. Using char * instead of String saved 150 bytes of sram and 1584 bytes of program space (because the String library doesn't have to be linked in).

Pete

Delta_G:
Those are probably ok but the question then becomes why use String there anyway. There's no advantage over char arrays. And char arrays would use less RAM.

I'm thinking it was done this way to make things more understandable to the novice, ie. me, than the word char and a bunch of asterisks scattered about. The word String and text in quotes is pretty explicit.

Robin2:
For fixed text the F macro will save a lot of memory

Oh no, something else I need to investigate. (sigh)

el_supremo:
I did a test of that string array. Using char * instead of String saved 150 bytes of sram and 1584 bytes of program space (because the String library doesn't have to be linked in).

Pete

Wow! Probably not an issue for most small programs but a lot of space to be freed up if things get tight.

Thank you all for the replies.

Robin2:
The places where data was moved from don't get returned to the heap instantly.

More misinformation re: String and heap usage... In fact, they DO get "returned to the heap instantly". ALWAYS! What MAY OR MAY NOT not happen "instantly" is the heap getting re-combined into a single contiguous chunk of free RAM. But, in most cases, that really doesn't matter, as even small, scattered free chunks will be re-allocated if they are large enough to satisfy subsequent requests. Unless you are making very large numbers of memory requests, or making very large memory requests, you'll likely have no problems. Even if you do somehow manage to run out, write the code properly, and you'll KNOW what happened, and can output a message or something to make it clear what happened, and take appropriate steps (either modify your memory usage, or use a board with more memory).
Regards,
Ray L.

1 Like

OK, my Strings are now character arrays. I am impressed. Program storage went from 5640 to 3916 and RAM usage dropped from 741 to 615. I'm a convert.

RayLivingston:
More misinformation re: String and heap usage... In fact, they DO get "returned to the heap instantly". ALWAYS! What MAY OR MAY NOT not happen "instantly" is the heap getting re-combined into a single contiguous chunk of free RAM.

I am not surprised that you have better technical knowledge than I - but that is not the whole story.

But, in most cases, that really doesn't matter, as even small, scattered free chunks will be re-allocated if they are large enough to satisfy subsequent requests.

If this was really effective nobody would have any hesitation about using the String class. And it is the unpredictable occasions when "most cases" does not cover it that cause the problems.

I will continue to advise against the use of the String class.

...R

Robin2:
I will continue to advise against the use of the String class.

...R

That's fine, just do it with facts, not misinformation.
Regards,
Ray L.

Delta_G:
Read this and I bet the RAM drops a whole bunch more.

Scanned and bookmarked. Thanks. I'll check it more closely later but I'm juggling rabbit holes as it is.