Benefits of using a custom literal for strings instead of a string literal

The subject of the lines in the SO documentation that said in the Notes section:

Since C ++ 14, it is recommended to use "foo"s instead of "foo" , since s is a string literal that converts const char * "foo" to std::string "foo" .

The only advantage I see when using

 std::string str = "foo"s; 

instead

 std::string str = "foo"; 

lies in the fact that in the first case, the compiler can execute copy-elision (I think), which will be faster than calling the constructor in the second case.

However, this is (not yet) guaranteed, so the former may also call the constructor, the copy constructor.

Ignoring cases where std::string literals are required, such as

 std::string str = "Hello "s + "World!"s; 

Is there any use to using std::string literals instead of const char[] literals?

+49
c ++ string c ++ 14 user-defined-literals
Jul 28 '16 at 2:51
source share
4 answers

If you are part of the Almost Always Auto group, then UDL is very important. He allows you to do this:

 auto str = "Foo"s; 

So str will be genuine std::string , not const char* . Therefore, it allows you to decide when to do it.

This is also important for outputting an automatic return type:

 []() {return "Foo"s;} 

Or any form of type inference, indeed:

 template<typename T> void foo(T &&t) {...} foo("Foo"s); 

The only advantage that I see when using [...] instead of [...] is that in the first case, the compiler can execute copy-elision (I think), which will be faster than calling the constructor in the second case.

Copying is no faster than calling a constructor. In any case, you call one of the object constructors. The question is which one:

 std::string str = "foo"; 

This will invoke the constructor std::string , which takes const char* . But since std::string should copy the string to its own storage, it should get the length of the string for this. And since he does not know the length, this constructor is forced to use strlen to get it (technically, char_traits<char>::length , but this probably will not be much faster).

In contrast to this:

 std::string str = "foo"s; 

This will use the UDL template that has this prototype:

 string operator "" s(const char* str, size_t len); 

See, the compiler knows the length of the string literal. Thus, the UDL code is passed by a pointer to a string and size. Thus, it can call the constructor std::string , which takes const char* and a size_t . Therefore, there is no need to calculate the length of the string.

The advice in question is not for you to get around and convert each use of the literal to version s . If everything is fine with the limitations of the char s array, use it. The advice is that if you are going to store this literal in std::string , it is best to do this while it is still literal and not foggy const char* .

+41
Jul 28 '16 at 3:09
source share

The recommendations for using "blah"s have nothing to do with efficiency and all that is needed for the beginner's code to be correct.

C ++ newbies who don't have a background in C tend to think that "blah" results in an object of some reasonable string type. For example, to write things like "blah" + 42 , which works in many script languages. However, with "blah" + 42 in C ++, Undefined Behavior simply arises, going beyond the scope of the character array.

But if this string literal is written as "blah"s , then a compilation error occurs instead, which is much preferable.

+16
Jul 28 '16 at 3:22
source share

UDL also makes it easy to use \0 in a string

 std::string s = "foo\0bar"s; // s contains a \0 in its middle. std::string s2 = "foo\0bar"; // equivalent to "foo"s 
+10
Jul 28 '16 at 8:31
source share
  • Using a C ++ string literal means we don’t need to call strlen to calculate the length. The compiler already knows this.
  • Library implementations may allow, when the string data points to memory in the global space, they will use C literals, which must always force data to be copied to the memory heap when building.
+2
Jul 28 '16 at 3:13
source share



All Articles