Can the compiler optimize STL strings?

[CppFTW]

Hi, I was wondering if the compiler Visual C++ is smart enough to optimize code like this:

string temp = "abcd";
string temp2 = "hahaha";
string temp3 = temp + temp2;

"temp + temp2" can be replaced by "abcdhahaha"

vector<char> alphabet;
for (char i = 'a'; i <= 'z'; i++)
{
    alphabet.push_back(i);
}

can be optimized to:

vector<char> alphabet;
//Avoid dynamic allocation
alphabet.reserve('z'-'a');
for (char i = 'a'; i <= 'z'; i++)
{
    alphabet.push_back(i);
}

Does the compiler do all of this this?

Thanks in advance!

[Narue]

Hi, I was wondering if the compiler Visual C++ is smart enough to optimize code like this:

string temp = "abcd";
string temp2 = "hahaha";
string temp3 = temp + temp2;

"temp + temp2" can be replaced by "abcdhahaha"

Actually, Visual C++ is smart enough not to optimize in that way. There are infinite possibilities in the side effects of calling member functions. Removing the call entirely could change the behavior of the program, so the optimization is prohibited.

vector<char> alphabet;
for (char i = 'a'; i <= 'z'; i++)
{
    alphabet.push_back(i);
}

can be optimized to:

vector<char> alphabet;
//Avoid dynamic allocation
alphabet.reserve('z'-'a');
for (char i = 'a'; i <= 'z'; i++)
{
    alphabet.push_back(i);
}

This optimization doesn't avoid dynamic allocation entirely, it lumps the progressive allocations into one (Visual C++ grows by half again the current capacity). Not a bad optimization, but it's very specific to the vector class and trivial for client code to implement as necessary. I very much doubt Visual C++ implements your suggestion.

[CppFTW]

Actually, Visual C++ is smart enough not to optimize in that way. There are infinite possibilities in the side effects of calling member functions. Removing the call entirely could change the behavior of the program, so the optimization is prohibited.

I know what you mean, but wouldn't visual C++ know that the built-in STL strings behave in this way?

Well, thanks for the response though!

[Narue]

I know what you mean, but wouldn't visual C++ know that the built-in STL strings behave in this way?

No, it wouldn't. That would add unnecessary coupling with a library that can be easily replaced. It's not entirely uncommon to replace the packaged standard library with a different implementation. I've done it myself more than once.

One other thing to note is that the standard library for Visual C++ is not written by Microsoft. It was written by Dinkumware and gimped by Microsoft to work with Visual C++'s weaker feature set. Dependencies in the optimizer on a specific version of the library would also add extra work in modifying future versions to fit Visual C++.

Finally, why bother? The cost of creating a new string object will probably outweigh the overhead of calling operator+ by an order of magnitude or more. Throw in return value optimization and removal of temporary objects and you've still got dubious gain for an optimization that only works in a very specific situation.

Well, thanks for the response though!

You say that as if I didn't answer your question...

[CppFTW]

Okay, thanks for clarifying.