Should I compare a std::string to "string" or "string"s?

Question

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.

Answer 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.