Allocating memory for String object

I am looking at the String example code at http://arduino.cc/en/Tutorial/StringLengthTrim. I notice that he declares the String as follows:

String txtMsg = "";

Later he appends characters to the String:

txtMsg += inChar;

Can the String object extend its own memory? I don't think so. I had some weird problems with a sketch (garbage in variables, etc), kind of typical of a buffer overrun, and I changed my String delaration to;

String foo = "                                                                   ";

and my problems went away.

Or is this a bug?

Yes, it can (see realloc), but it's not nice.

The general consensus (from the people that know) is to stay well away from the String object unless you have lots and lots of ram (such as a Due).

wsanders:
Can the String object extend its own memory?

That's exactly why people use it. However ...

Please note that in versions of the IDE up to and including 1.0.3, the String library has bugs as discussed here and here.

In particular, the dynamic memory allocation used by the String class may fail and cause random crashes.

I recommend reworking your code to manage without String. Use C-style strings instead (strcpy, strcat, strcmp, etc.), as described here for example.

Alternatively, install the fix described here: Fixing String Crashes

Preferably upgrade your IDE to version 1.0.4 or above at: http://arduino.cc/en/Main/Software

Can the String object extend its own memory?

It allocates new memory, puts the extended text in there, then the previous memory is freed.

Chances are high that the freed small memory is too small for new strings, because everybody using String objects, always grows them.
Thus you have a lot of unusable garbage memory and need way more than really required.

There's no protection against too little available dynamic memory in the Arduino, even if a serial monitor is attached you won't see an error message, unless you programmed such a thing yourself. Nobody using String objects checks for memory problems.

Bottom line: Strings are great, but not recommended for people who like to use String objects.

I changed my String delaration toString foo = " "; and my problems went away.

Have you tried the below

String txtMsg;

instead of

String txtMsg = "";

Have you tried the below ....

Actually after I declare it

String txtMsg = "                                                                                                                                      ";

I clear it out in setup():

txtMsg = "";

before I use it.

Thanks for the tips. I noticed in other posts there's not much love for String().

I did a comparison here:

Thanks for the tips. I noticed in other posts there's not much love for String().

In the past there may have been issues with using String due to memory issues, but reportedly those issues have been fixed. For newbies the String functions are fairly easy to use and understand.

Thanks for this very clear and helpful writeup. (+)
Seems the Arduino String memory fragmentation issue is really solved.
String overhead is impressive, interesting that RAM overhead is rather small.

"State Machine" deserves a link to your previous posts Gammon Forum : Electronics : Microprocessors : How to process incoming serial data without blocking
including the "parsing numbers on the fly" in the example there.

Thanks!

There is a link to it: http://www.gammon.com.au/serial (same page)

Thanks Nick for the C strings vs Strings test.

My compiled code goes up 2K in size when I use a String for just one object instead of a char[] array. But I am not concerned with size - yet. There does not seem to be a performance penalty, just size.

There's a performance penalty:

Old topic, yes, but with the Due/Zero/Teensy/Esp8266 I think it warrants an update.

It's really time to move past the "old" avr micros when we can, otherwise we will continue to program in the "dark ages".

Using the String class is a real boon for cleaner/easier to read code. For beginners in particular that is a good thing. Yes the old hands can use old str??? functions where absolutely necessary, but moving to faster 32 bit arm (and esp8266) processors with more memory make that less and less important.

Even the standard template vector lib can be used efficiently on the arms and esp8266.

So yes it's 2015, even Atmel knows it, hence the newer arm cores.

For my part, I will buy no further avr micros, they just don't make sense for anyone but the beginner that want to flash an LED.