Runtime dependency for std::string concatenation

Question

std::string sAttr("");
sAttr = sAttr+VAL_TAG_OPEN+sVal->c_str()+VAL_TAG_CLOSE;

else where in the code I have defined

const char VAL_TAG_OPEN[]   = "<value>";

sVal is a variable that is retrieved off of a array of string pointers. This works fine in most of the system, windows and linux. However at a customer site, where to my belief has a version of linux on which we had done some extensive testing, produce a result as if I have never used the VAL_TAG_OPEN and VAL_TAG_CLOSE. The results I recieve is for

sAttr = sAttr+sVal->c_str();

Whats going on ?. Does std::string concatenation varies across runtime ?

Answer 1

Why the ->c_str()? If sVal is a std::string, try removing this call. Remember that the order of evaluation is undefined, so you may end up adding pointers instead of concatenating strings, because VAL_TAG_OPEN, sVal->c_str() and VAL_TAG_CLOSE are all plain C strings. I suggest you use the addition assignment operator +=, e.g. :

sAttr += VAL_TAG_OPEN;
sAttr += *sVal; /* sVal->c_str() ? */
sAttr += VAL_TAG_CLOSE;

(which should be faster anyway).

Answer 2

No, std::string concatenation should definitely not depend upon runtime, but somehow VAL_TAG_OPEN and VAL_TAG_CLOSE seem to be empty strings.

I'd guess you've some kind of buffer overflow or invalid pointer arithmetic somewhere, so that your program overwrites the memory containing those "constant" values. Wherever your memory ends up being is indeed runtime (and therefore OS version) specific. I've been trapped by similar things in the past by switching compilers or optimizer options.

As you mention keeping raw pointers to std::string instances in raw arrays, such errors are indeed not all to improbable, but may be difficult to detect, as using a DEBUG build won't give you any iterator checks with all these all to RAW things... Good luck.

Answer 3

sAttr = sAttr+VAL_TAG_OPEN+sVal->c_str()+VAL_TAG_CLOSE;

Like fbonnet said, it's an order of evaluation issue.

If that line gets evaluated strictly left to right, then the result of each addition is a std::string object, which has an operator overload for addition and things work as you expect.

If it doesn't get evaluated left to right, then you wind up adding pointers together and who knows what that will get you.

Avoid this construct and just use the += operator on std::string.

Answer 4

I don't thing its the order of evaluation that is causing the issue. Its because of the constant char arrays at the beginning and end

const char VAL_TAG_OPEN[]   = "<value>";
const char VAL_TAG_CLOSE[]  = "</value>"

The concatenation operator thought VAL_TAG_OPN and VAL_TAG_CLOSE as not a null terminator string. Hence the optimizer just ignored them thinking it as garbage.

sAttr += std::string(VAL_TAG_OPEN);
sAttr += *sVal;
sAttr += std::string(VAL_TAG_CLOSE);

This does solve it.