In this particular case, the two are actually identical. The compiler will transform the second variant, the one using the +
operator, into a call to Concat, the first variant.
Well, that is, if the two actually contained string variables that was concatenated.
This code:
B = "abc" + "def";
actually transforms into this, without concatenation at all:
B = "abcdef";
This can be done because the result of the addition can be computed at compile-time, so the compiler does this.
However, if you were to use something like this:
A = String.Concat(stringVariable1, stringVariable2);
B = stringVariable1 + stringVariable2;
Then those two will generate the same code.
However, I would like to know exactly what those "many" said, as i think it is something different.
What I think they said is that string concatenation is bad, and you should use StringBuilder or similar.
For instance, if you do this:
String s = "test";
for (int index = 1; index <= 10000; index++)
s = s + "test";
Then what happens is that for each iteration through the loop, you'll build one new string, and let the old one be eligible for garbage collection.
Additionally, each such new string will have all the contents of the old one copied into it, which means you'll be moving a large amount of memory around.
Whereas the following code:
StringBuilder sb = new StringBuilder("test");
for (int index = 1; index <= 10000; index++)
sb.Append("test");
Will instead use an internal buffer, that is larger than what needs be, just in case you need to append more text into it. When that buffer becomes full, a new one that is larger will be allocated, and the old one left for garbage collection.
So in terms of memory use and CPU usage, the later variant is much better.
Other than that, I would try to avoid focusing too much on "is code variant X better than Y", beyond what you already have experience with. For instance, I use StringBuilder now just because I'm aware of the case, but that isn't to say that all the code I write that use it actually needs it.
Try to avoid spending time micro-optimizing your code, until you know you have a bottleneck. At that time, the usual tip about measure first, cut later, is still in effect.