Should I compare a std::string to “string” or “string”s?

问题

Consider this code snippet:

bool foo(const std::string& s) {
    return s == "hello"; // comparing against a const char* literal
}

bool bar(const std::string& s) {
    return s == "hello"s; // comparing against a std::string literal
}

At first sight, it looks like comparing against a const char* needs less assembly instructions¹, as using a string literal will lead to an in-place construction of the std::string.

(EDIT: As pointed out in the answers, I forgot about the fact that effectively s.compare(const char*) will be called in foo(), so of course no in-place construction takes place in this case. Therefore striking out some lines below.)

However, looking at the operator==(const char*, const std::string&) reference:

All comparisons are done via the compare() member function.

From my understanding, this means that we will need to construct a std::string anyway in order to perform the comparison, so I suspect the overhead will be the same in the end (although hidden by the call to operator==).

• Which of the comparisons should I prefer?
• Does one version have advantages over the other (may be in specific situations)?

¹ I'm aware that less assembly instructions doesn't neccessarily mean faster code, but I don't want to go into micro benchmarking here.

回答1:

Neither.

If you want to be clever, compare to "string"sv, which returns a std::string_view.

---

While comparing against a literal like "string" does not result in any allocation-overhead, it's treated as a null terminated string, with all the concomittant disadvantages: No tolerance for embedded nulls, and users must heed the null terminator.

"string"s does an allocation, barring small-string-optimisation or allocation elision. Also, the operator gets passed the length of the literal, no need to count, and it allows for embedded nulls.

And finally using "string"sv combines the advantages of both other approaches, avoiding their individual disadvantages. Also, a std::string_view is a far simpler beast than a std::string, especially if the latter uses SSO as all modern ones do.

---

At least since C++14 (which generally allowed eliding allocations), compilers could in theory optimise all options to the last one, given sufficient information (generally available for the example) and effort, under the as-if rule. We aren't there yet though.

回答2:

No, compare() does not require construction of a std::string for const char* operands.

You're using overload #4 here.

The comparison to string literal is the "free" version you're looking for. Instantiating a std::string here is completely unnecessary.

回答3:

From my understanding, this means that we will need to construct a std::string anyway in order to perform the comparison, so I suspect the overhead will be the same in the end (although hidden by the call to operator==).

This is where that reasoning goes wrong. std::compare does not need to allocate its operand as a C-style null-terminated string to function. According to one of the overloads:

int compare( const CharT* s ) const; // (4)

4) Compares this string to the null-terminated character sequence beginning at the character pointed to by s with length Traits::length(s).

Although whether to allocate or not is an implementation detail, it does not seem reasonable that a sequence comparison would do so.

来源：https://stackoverflow.com/questions/56427627/should-i-compare-a-stdstring-to-string-or-strings