String

Hello, did I use String in a wrong way?
String chaine;
int a=10;
int b=20;
int c=30;
int adresse=123;
long valeur=123456;

if i do this :
chaine=String(adresse)+" "+String(Valeur)+" a="+String(a)+" b="+String(b)+" c="+String(c);
Serial.println(chaine);
then bug

if i do that :
Serial.print(adresse);
Serial.print(" ");
Serial.print(valeur);
Serial.print(" a=");
Serial.print(a);
Serial.print(" b=");
Serial.print(b);
Serial.print(" c=");
Serial.println(c);
then ok

if i do this :
chaine=String(adresse)+" "+String(Valeur)+" a="+String(a)+" b="+String(b)+" c="+String(c);
Serial.println(chaine);
then bug

What kind of bug? Converting each value to a separate String is completely unnecessary.

In this snippet you have 5 calls to the String constructor (requiring 5 calls to the matching destructor) as well as 8 calls to the concatenation operator. For what? The device on the other end of the serial port won't be able to tell the difference between the output generated by this snippet and the other one that doesn't waste resources using the String class.

String class is best avoided entirely, it usually leads to a space leak and thus sketches that crash soon after starting.

+1 to avoid using the String class on Arduino. Use C string arrays instead, they're well-behaved.

PaulS:

if i do this :
chaine=String(adresse)+" "+String(Valeur)+" a="+String(a)+" b="+String(b)+" c="+String(c);
Serial.println(chaine);
then bug

What kind of bug? Converting each value to a separate String is completely unnecessary.

In this snippet you have 5 calls to the String constructor (requiring 5 calls to the matching destructor)

Even worse, the compiler is going to typecast the rest into Strings too. Then for every + the String chaine gets copied over as the larger version (chaine + nextString) as a new String and that keeps going on for all 9 parts.
When are the old copies of chaine destructed? Right after concatenation?
Even worst case, I don't see enough just there to fill 1k of ram.

Maybe it will be a good idea to look at sprintf()

Even worst case, I don't see enough just there to fill 1k of ram.

Its not so much that the String class allocates and deallocates at some undefined later time memory. It is that the process for freeing that memory is flawed, resulting in corruption of memory even when it is all correctly, and in a timely fashion, deallocated.

Certainly so. There's the alloc/copy itself every time it changes aspect that makes the String class bad practice on small/tiny memory models and the dealloc/heap-shotgunning that makes it worse.

But when I add up those pieces I see, even without deallocation there doesn't seem to be enough to fill 1k, probably not 256 bytes. If it's a memory crash I would expect more.

GoForSmoke:
But when I add up those pieces I see, even without deallocation there doesn't seem to be enough to fill 1k, probably not 256 bytes. If it's a memory crash I would expect more.

Do you know how many times the code fragment has to execute to provoke the problem?

Nope, you’re right again.

It’s that old thing about full code not being posted that often you point out. :wink:
All I posted about (this time at least) is what I see there.

AFAIK heap shotgunning has been behind a multitude of program/OS crashes for over 20 years now.
It’s no mystery to me after seeing the hardware-ignorance-is-good trend in comp-sci long ago.

How many programmers does it take to change a lightbulb?
Can’t be done, it’s a hardware problem!
Yet who designs the OS?