[clang-tidy] performance-inefficient-string-concatenation: sometimes code complained to is optimal

[loskutov]

The check description states that

void f(const std::string&) {}
std::string a("Foo"), b("Baz");
void g() {
    f(a + "Bar" + b);
}

can be rewritten "in a slightly more efficient way" like:

void f(const std::string&) {}
std::string a("Foo"), b("Baz");
void g() {
    f(std::string(a).append("Bar").append(b));
}

In fact, the first version:

• is (arguably) more readable
• can lead to at most two allocations in most implementations (new string created for a + "Bar", then b is concatenated using rvalue-overload of operator+, which is equivalent to append), whilst the second one can lead to three allocations (copy of a is created, and then both append calls might lead to reallocation).

Maybe this transformation made sense before C++11, but nowadays it seems that only assignments of form a = [... + ]a + ... are in fact suboptimal.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

[Izaron]

The first example is really not quite good. There is the "small string optimization", so strings have to be 16+ chars long (on most machines) to provoke any memory allocations. Seems like the check behaves like there is no such optimization.

[loskutov]

I wouldn't take the example literally—"Bar" could be arbitrarily long, and the replacement suggestion would still be senseless.