Here was an odd thing,
during some experimenting I find this.
Obviously not real code.
Just to show the use of + and +=
Serial.print(F("HelloGoodbye"));
//Change that to
Serial.print(F("Hello") + F("Goodbye"));
//Change that to
Serial.print(F("Hello"));
Serial.print(F("Goodbye"));
//Change that to
String x = F("Hello") + F("Goodbye");
Serial.print(x);
//Change that to
String x = F("Hello");
x += F("Goodbye");
Serial.print(x);
All produce slightly different sketch outputs.
amazing how something that looks shorter can produce longer output.
No chance of that with assembler, WYSIWYG.
String is an object/struct used to handle array of char. A C(++) object/struct may be extended with operators such as "+", "-", "+=" and so on in order to attach a function to handle the operators. So "+=" is not necessary an arithmetic operator, but it may work for struct and classes as well.
Would be nice to know, what methods produces which output
If you by "bigger output" mean a larger compiled program size or larger memory usage, then it is obvious that multiple smaller assignments would require less than one larger assignement since the space / memory used by smaller assignemt can be reused by subsequent assignments. Anyhow, you should avoid to use String in arduino, so why bother at all?
Hiddenvision:
Just the sketch size. Dynamic Memory remained unchanged.
Because the Strings go in the heap. They're not counted in that number you get when you compile. Only the pointers to them.
Hiddenvision:
Strings suit me cos I am LAZY.!
I know you think that. But I promise you this, if you code with Arduino very much you are going to run into lots of libraries that won't take Strings and you'll spend far more effort trying to jam a String in there than you would learning that everything you do with String has an equivalent with char arrays you just have to learn a different function name.
But seriously I don't know what is the best method, that's why I was posing the scenario.
There is Strcat() Concat(), dammcat() and coolcat() to mention but a few.!
Not to mention the various ways to define the actual 'text' in the first place.
I am tinkering, so will find my answers in time if only thru process of elimination.
Also thinking, rather than everyone bitching about how strings are "BAD",
why has nobody re-written the Strings Class to improve it.!
In real terms it should not matter how things are written,
code should compile down to the same output if the intention is the same.
Sorry, I'm too used to assembler, all this nasty C stuff does it best though.
Hiddenvision:
Also thinking, rather than everyone bitching about how strings are "BAD",
why has nobody re-written the Strings Class to improve it.!
Because it isn't bad for bad code. It works great on systems with more memory and/or garbage collection to clean up the leftover bits when you concatenate Strings. The code is good. It's just the Arduino that doesn't quite have what it takes to really use it.
Hiddenvision:
In real terms it should not matter how things are written,
code should compile down to the same output if the intention is the same.
That's just crazy-talk. How is a compiler supposed to know your intention? All it sees is the code you write. If you tell it to do something the hard way how is it supposed to know that you didn't do that on purpose?
Hmm. If you overload "operator+" to handle string concatenation, does that get used for "+=" as well, or do you have to provide a separate overload of "operator+="?
Is the OP going to give us hints as to what these "different outputs" actually are?
Serial.print(F("Hello") + F("Goodbye"));
String x = F("Hello") + F("Goodbye");
Those don't even compile, do they? You can't add two pointers together, and there's nothing to tell the compiler that it should convert them to Strings just so that the add will make sense...
String x = F("Hello");
x += F("Goodbye");
And that one's a bit ridiculous: "I will save RAM by putting my string literals in flash, and then I will waste RAM by converting them to Strings so that I can concatenate them!"
westfw:
Hmm. If you overload "operator+" to handle string concatenation, does that get used for "+=" as well, or do you have to provide a separate overload of "operator+="?
"+" and "+=" are two different operators so each must be implemented on their own.
westfw:
Those should be the same, though...
Nope, you have two calls to F() in the latter and that will result in larger code than a single call. Reason being that F() is a macro and a macro is basically code that must be copied by the compiler and more code = bigger program.