String variable memory size

Hi my program is very short in memory, I'm already using the flash library to store fixed strings on prog mem..
and # defines for all constants (for what i read this saves ram)..
But my program takes sms and pdu encoding etc and this is all string based thats why i believe i so short in mem...
After the initial loop run i stay with 515byte mem, and i still didn't implement all the features...

So my question is when i declare a global variable like:

String str1global
void setup()
{
Serial.begin(9600);
Serial.println(str1globa);

}

int function()
{
String str2local
Serial.println(str1globa);
}

in this case hoe much ram is taken by str1global when declared ? will it only use when data is putted inside ?

when i leave the function will the memused by the str2local will be freeup ?

Regards.

If you are short on memory, you need to ditch the String class. Use char arrays, instead. People did that for years and years before the String class was built to make character processing easier.

Declaring a String as a global string, with no initialization data, makes a very small object. Printing an uninitialized string makes no sense.

A local String goes out of scope, and the destructor is called, when the function or block ends. Printing the uninitialized global, or even the local, String still makes no sense.

hi and thanks for the answer, i'm not printing a empty string i wrote that sample of code here justo to show an example....
thats not my reall code...

i'm using some libraries that work with strings, i need to change all these external libraries for use char array instead of string...

Thanks

When I last looked at the string class the string took up memory equivalent to the length of the string, plus a couple or so bytes to indicate how long the string was.

I don't think the problem is the absolute size of memory used, but fragmentation.

Absolutely. I was answering the direct question. But in general I would agree that using the String class is likely to cause a lot of problems. Not because of any fundamental flaws in it. But because with a limited amount of RAM you can't afford a lot of fragmented memory. And that is what you are likely to get.

But in general I would agree that using the String class is likely to cause a lot of problems. Not because of any fundamental flaws in it.

But, there is a fundamental flaw, that could be relatively easily fixed. That flaw is in the append() function. When a character is added to a String object, new space is allocated, equal the the length of the original String plus the length of the new String. The old String is copied into the new space, and the String to append is added to the end. The old space is freed, and the String object then points to the new space.

If the append() function, and the += operator was re-written to allocate space for the old string, the new string, and some growth room, the number of re-allocations and copies needed could be greatly reduced, resulting in less fragmentation.

This is especially important when Strings are used to collect data read from the serial port or ethernet client, one character at a time.

But isn't that locking the door after the horse has been stolen?

Why not allocate the extra room at the very start? Say I have a 1-byte string, you might assume I would append to it. So you might allocate 10 bytes. And then keep filling it up until you need to reallocate. Doing that at append time is already too late. But what if I don't append? Then I have wasted 9 bytes. Similarly with allocating extra memory on an append. Maybe I won't do another one.

Maybe some sort of "hint" to the string function. For example set a "granularity" for strings. So if you know you are planning to append, you might make it 16 or so. And if not, just 1.

I think this is one of those things that doesn't have a very simple solution. If you know your data (eg. you are expecting a maximum of 100 characters) then a 100 character buffer (or maybe 101 to allow for the 0x00) is the simplest. But even that can be wasteful. Your maximum might be 100 but your typical might be 10. Hence my suggestion of a granularity option.

Why not allocate the extra room at the very start?

Well, sure, that would be smart, too. Most real String classes do that.

The initial allocation for the String should be definable in the constructor or some other method. It can't be done in the constructor, the way that the String class is currently written, though, since the constructor can be used to construct a string from an int or long.

In my opinion, none of the "create a String from a number" constructors should be provided, although some int-to-string method (and float to string method) should be provided (called BuildFromNum() in the String class I use on a daily basis). The constructor with numeric argument should defined the initial size of the String's internal array.

A grow-by- method (granularity as you call it) method would be a useful addition to.

PaulS:
The initial allocation for the String should be definable in the constructor or some other method. It can't be done in the constructor, the way that the String class is currently written, though, since the constructor can be used to construct a string from an int or long.

STL vectors have a reserve() function which is what you could use here. The constructor would allocate a minimal amount of memory, and then you reserve the amount of memory you expect to need. After that appending is quick and cheap.