{"id":5705,"date":"2019-06-13T15:01:49","date_gmt":"2019-06-13T15:01:49","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-rules-about-strings\/"},"modified":"2023-06-27T07:59:49","modified_gmt":"2023-06-27T07:59:49","slug":"c-core-guidelines-rules-about-strings","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-rules-about-strings\/","title":{"rendered":"C++ Core Guidelines: Rules for Strings"},"content":{"rendered":"

The C++ core guidelines use the term string as a sequence of characters. Consequently, the guidelines are about  C-strings, C++-strings, the C++17 std::string_view<\/span>‘s, and std::byte<\/span>‘s. <\/p>\n

<\/p>\n

 <\/div>\n

 \"thread<\/p>\n

I will in this post only loosely refer to the guidelines and ignore the strings which are part of the guidelines support library, <\/a>such as gsl::string_span, zstring<\/span>, and czstring<\/span>. For short, I call in this post a std::string<\/span>, a C++-string, and a const char*<\/span> a C-string.<\/p>\n

Let me start with the first rule:<\/p>\n

SL.str.1: Use std::string<\/code> to own character sequences<\/a><\/h2>\n

Maybe, you know another string that owns its character’s sequence: a C-string. Don’t use a C-string! Why? Because you have to take care of the memory management, the string termination character, and the string length.<\/p>\n

 <\/p>\n

\n
\/\/ stringC.c<\/span>\r\n\r\n#include <stdio.h><\/span>\r\n#include <string.h><\/span>\r\n \r\nint<\/span> main<\/span>( void<\/span> ){\r\n \r\n  char<\/span> text[10<\/span>];\r\n \r\n  strcpy(text, \"The Text is too long for text.\"<\/span>);   \/\/ (1) text is too big<\/span>\r\n  printf(\"strlen(text): %u<\/span>\\n<\/span>\"<\/span>, strlen(text));       \/\/ (2) text has no termination character '\\0'<\/span>\r\n  printf(\"%s<\/span>\\n<\/span>\"<\/span>, text);\r\n \r\n  text[sizeof<\/span>(text)-<\/span>1<\/span>] =<\/span> '\\0'<\/span>;\r\n  printf(\"strlen(text): %u<\/span>\\n<\/span>\"<\/span>, strlen(text));\r\n \r\n  return<\/span> 0<\/span>;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The simple program stringC.c<\/span> has inline (1) and line (2) undefined behavior. Compiling it with a rusty GCC 4.8 seems to work fine.<\/p>\n
\"stringC\"The C++ variant does not have the same issues.<\/p>\n
\n
\/\/ stringCpp.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n  std::<\/span>string text{\"The Text is not too long.\"<\/span>};  \r\n \r\n  std::<\/span>cout <<<\/span> \"text.size(): \"<\/span> <<<\/span> text.size() <<<\/span> std::<\/span>endl;\r\n  std::<\/span>cout <<<\/span> text <<<\/span> std::<\/span>endl;\r\n \r\n  text +=<\/span>\" And can still grow!\"<\/span>;\r\n \r\n  std::<\/span>cout <<<\/span> \"text.size(): \"<\/span> <<<\/span> text.size() <<<\/span> std::<\/span>endl;\r\n  std::<\/span>cout <<<\/span> text <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The output of the program should not surprise you.<\/p>\n
\"stringCpp\"<\/p>\n
In the case of a C++ string, I cannot make an error because the C++ runtime takes care of the memory management and the termination character. Additionally, if you access the elements of the C++ string with the at-operator instead of the index operator, bounds errors are not possible. You can read the details of the at-operator in my previous post: C++ Core Guidelines: Avoid Bounds Errors<\/a>.<\/p>\n
You know, what was strange in C++, including C++11? There was no way to create a C++ string without a C-string. This is strange because we want to get rid of the C-string. This inconsistency is gone with C++14.<\/p>\n<\/p>\n
SL.str.12: Use the s<\/code> suffix for string literals meant to be standard-library string<\/code>s<\/a> <\/h2>\n
With C++14, we got C++-string literals. It’s a C-string literal with the suffix s: “cStringLiteral”s<\/span>.<\/p>\n
Let me show you an example that makes my point: C-string literals and C++-string literals a different.<\/p>\n
 <\/p>\n
\n
\/\/ stringLiteral.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n#include <utility><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n    \r\n    using<\/span> namespace<\/span> std::<\/span>string_literals;                         \/\/ (1)<\/span>\r\n\r\n    std::<\/span>string hello =<\/span> \"hello\"<\/span>;                                  \/\/ (2)<\/span>\r\n    \r\n    auto<\/span> firstPair =<\/span> std::<\/span>make_pair(hello, 5<\/span>);\r\n    auto<\/span> secondPair =<\/span> std::<\/span>make_pair(\"hello\"<\/span>, 15<\/span>);                \/\/ (3)<\/span>\r\n    \/\/ auto secondPair = std::make_pair(\"hello\"s, 15);            \/\/ (4)<\/span>\r\n    \r\n    if<\/span> (firstPair <<\/span> secondPair) std::<\/span>cout <<<\/span> \"true\"<\/span> <<<\/span> std::<\/span>endl; \/\/ (5)<\/span>\r\n    \r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
It’s a pity; I must include the namespace std::string_literals<\/span> in line (1) to use the C++-string-literals. Line (2) is the critical line in the example. I use the C-string-literal “hello”<\/span> to create a C++ string. This is why the type of firstPair<\/span> is (std::string, int<\/span>), but the type of the secondPair<\/span> is (const char*, int<\/span>). Ultimately, the comparison in line (5) fails because you can not compare different types. Look carefully at the last line of the error message: <\/p>\n
\"stringLiteralsError\"<\/p>\n
When I use the C++-string-literal in line (4 ) instead of the C-string-literal in line (3), the program behaves as expected:<\/p>\n
\"stringLiterals\"<\/p>\n
C++-string-literals was a C++14 feature. Let’s jump three years further. With C++17, we got std::string_view<\/span> and std::byte<\/span>. I already wrote, in particular, about std::string_view<\/span>. Therefore, I will only recap the most important facts.<\/p>\n
SL.str.2: Use std::string_view<\/code> or gsl::string_span<\/code> to refer to character sequences<\/a><\/h2>\n
Okay, a std::string<\/span> view only refers to the character sequence. To say it more explicitly: A std::string_view<\/span> does not own the character sequence. It represents <\/span>a view of a sequence of characters. This sequence of characters can be a C++ string or a C-string. A std::string_view<\/span> only needs two pieces of information: the pointer to the character sequence and their length. It supports the reading part of the interface <\/span>of the std::string<\/span>. Additionally to a std::string, std::string_view<\/span> has two modifying operations: remove_prefix<\/span> and remove_suffix<\/span>.<\/p>\n
Maybe you wonder: Why do we need a std::string_view<\/span>? A std::string_view<\/span> is relatively cheap to copy and needs no memory. My previous post C++17 – Avoid Copying with std::string_view <\/a>shows the impressive performance numbers of a std::string_view<\/span>.<\/p>\n
As I already mentioned it, we got with C++17 also a std::byte<\/span>.<\/p>\n
SL.str.4: Use char*<\/code> to refer to a single character<\/a> and SL.str.5: Use std::byte<\/code> to refer to byte values that do not necessarily represent characters<\/a><\/h2>\n
If you don’t follow rule str.4 and use const char*<\/span> as a C-string, you may end with critical issues.<\/p>\n
 <\/p>\n
\n
char<\/span> arr[] =<\/span> {'a'<\/span>, 'b'<\/span>, 'c'<\/span>};\r\n\r\nvoid<\/span> print<\/span>(const<\/span> char<\/span>*<\/span> p)\r\n{\r\n    cout <<<\/span> p <<<\/span> '\\n'<\/span>;\r\n}\r\n\r\nvoid<\/span> use<\/span>()\r\n{\r\n    print(arr);   \/\/ run-time error; potentially very bad<\/span>\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
arr<\/span> decays to a pointer when used as an argument of the function print<\/span>. The undefined behavior is that arr<\/span> is not zero-terminated. You’re mistaken if you now think you can use std::byte as a character.<\/p>\n
std::byte<\/span> is a distinct type implementing the concept of a byte as specified in the C++ language definition. This means a byte is not an integer or a character and is not open to programmer errors. Its job is to access object storage. Consequently, its interface consists only of methods for bitwise logical operations.<\/p>\n
 <\/p>\n
\n
namespace<\/span> std { \r\n\r\n    template<\/span> <class<\/span> IntType<\/span>> \r\n        constexpr byte operator<\/span><<(byte b, IntType shift); \r\n    template<\/span> <class<\/span> IntType<\/span>> \r\n        constexpr byte operator<\/span>>>(byte b, IntType shift); \r\n    constexpr byte operator<\/span>|(byte l, byte r); \r\n    constexpr byte operator<\/span>&(byte l, byte r); \r\n    constexpr byte operator<\/span>~(byte b); \r\n    constexpr byte operator<\/span>^(byte l, byte r); \r\n\r\n} \r\n<\/pre>\n<\/div>\n
 <\/p>\n
You can use the function std::to_integer(std::byte b)<\/span> to convert a std::byte<\/span> to an integer type and the call std::byte{integer}<\/span> to do it the other way around. integer<\/span> has to be a non-negative value smaller than std::numeric_limits<unsigned_char>::max().<\/span><\/p>\n
What’s next?<\/h2>\n
I’m almost done with the rules for the standard library. Only a few rules to iostreams and the C-standard library are left. So you know what I will write about in my next post.<\/a><\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
The C++ core guidelines use the term string as a sequence of characters. Consequently, the guidelines are about  C-strings, C++-strings, the C++17 std::string_view‘s, and std::byte‘s. <\/p>\n","protected":false},"author":21,"featured_media":5700,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[372],"tags":[],"class_list":["post-5705","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modern-c"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5705","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5705"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5705\/revisions"}],"predecessor-version":[{"id":6784,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5705\/revisions\/6784"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5700"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5705"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5705"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5705"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}