{"id":5681,"date":"2019-05-16T17:09:38","date_gmt":"2019-05-16T17:09:38","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-the-standard-library\/"},"modified":"2019-05-16T17:09:38","modified_gmt":"2019-05-16T17:09:38","slug":"c-core-guidelines-the-standard-library","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-the-standard-library\/","title":{"rendered":"C++ Core Guidelines: The Standard Library"},"content":{"rendered":"

The rules to the C++ standard library are mainly about containers, strings, and iostreams.<\/p>\n

<\/p>\n

\"iso<\/p>\n

Curiously, there is no section on the standard template library (STL) algorithms in this chapter. Curiously, because there is a proverb in the C++ community: If you write an explicit loop, you don’t know the algorithms of the STL. Anyway. Only for completeness, let me start with the first three rules which do provide not much beef.<\/p>\n

SL.1: Use libraries wherever possible<\/a>, because reinventing the wheel is a bad idea. Additionally, you benefit from the work of others. This means you use already tested and well-defined functionality. This holds, in particular, true if you SL.2: Prefer the standard library to other libraries. <\/a>Imagine, for example, you hire someone. The benefit is that he already knows the library, and you don’t have to teach him your libraries. You save a lot of money and time. I once had a customer who named his infrastructure namespace std<\/span>. Of course, if you want to have a lot of fun, do it. If not: SL.3: Do not add non-standard entities to namespace std<\/code><\/a>.<\/p>\n

The next rules to STL containers are more concrete.<\/p>\n<\/p>\n

Containers<\/h2>\n

 The first rule is quite easy to argue.<\/p>\n

SL.con.1: Prefer using STL array<\/code> or vector<\/code> instead of a C array<\/a><\/h3>\n

I assume you know a std::vector. <\/span>One of the significant advantages of a std::vector<\/span> to a C array is that the std::vector<\/span> automatically manages its memory. Of course, that holds true for all further containers of the Standard Template Library. But now, let’s look closer at the automatic memory management of std::vector<\/span>.<\/span><\/p>\n

std::vector<\/span><\/h3>\n
\n
\/\/ vectorMemory.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n#include <vector><\/span>\r\n\r\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\r\nvoid<\/span> showInfo(const<\/span> T&<\/span> t,const<\/span> std::<\/span>string&<\/span> name){\r\n\r\n  std::<\/span>cout <<<\/span> name <<<\/span> \" t.size(): \"<\/span> <<<\/span> t.size() <<<\/span> std::<\/span>endl;\r\n  std::<\/span>cout <<<\/span> name <<<\/span> \" t.capacity(): \"<\/span> <<<\/span> t.capacity() <<<\/span> std::<\/span>endl;\r\n\r\n}\r\n\r\nint<\/span> main(){\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>vector<<\/span>int<\/span>><\/span> vec;                                            \/\/ (1)<\/span>\r\n\r\n    std::<\/span>cout <<<\/span> \"Maximal size: \"<\/span> <<<\/span> std::<\/span>endl;\r\n    std::<\/span>cout <<<\/span> \"vec.max_size(): \"<\/span> <<<\/span> vec.max_size() <<<\/span> std::<\/span>endl;  \/\/ (2)<\/span>\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>cout <<<\/span> \"Empty vector: \"<\/span> <<<\/span> std::<\/span>endl;\r\n    showInfo(vec, \"Vector\"<\/span>);\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>cout <<<\/span> \"Initialised with five values: \"<\/span> <<<\/span> std::<\/span>endl;   \r\n    vec =<\/span> {1<\/span>,2<\/span>,3<\/span>,4<\/span>,5<\/span>};\r\n    showInfo(vec, \"Vector\"<\/span>);                                        \/\/ (3)<\/span>\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>cout <<<\/span> \"Added four additional values: \"<\/span> <<<\/span> std::<\/span>endl;\r\n    vec.insert(vec.end(),{6<\/span>,7<\/span>,8<\/span>,9<\/span>});\r\n    showInfo(vec,\"Vector\"<\/span>);                                         \/\/ (4)<\/span>\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>cout <<<\/span> \"Resized to 30 values: \"<\/span> <<<\/span> std::<\/span>endl;\r\n    vec.resize(30<\/span>);\r\n    showInfo(vec,\"Vector\"<\/span>);                                         \/\/ (5)<\/span>\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>cout <<<\/span> \"Reserved space for at least 1000 values: \"<\/span> <<<\/span> std::<\/span>endl;\r\n    vec.reserve(1000<\/span>);\r\n    showInfo(vec,\"Vector\"<\/span>);                                        \/\/ (6)<\/span>\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n    std::<\/span>cout <<<\/span> \"Shrinke to the current size: \"<\/span> <<<\/span> std::<\/span>endl;\r\n    vec.shrink_to_fit();                                           \/\/ (7)<\/span>\r\n    showInfo(vec,\"Vector\"<\/span>);\r\n\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
To spare typing, I wrote the small function showInfo<\/span>. This function returns for a vector its size and its capacity. The size of a vector is its number of elements, and the capacity of a container is the number of elements a vector can hold without an additional memory allocation. Therefore, the capacity of a vector has at least to be as big as its size. You can adjust the size of a vector with its method resize<\/span> and the capacity of a container with its method reserve<\/span>.<\/p>\n
But, back to the program from top to bottom. I create (line 1) an empty vector. Afterward, the program displays (line 2) the maximum number of elements a vector can have. After each operation, I return their size and capacity. That holds for the initialization of the vector (line 3), for the addition of four new elements (line 4), the resizing of the containers to 30 elements (line 5), and the reserving of additional memory for at least 1000 elements (line 6). With C++11, you can shrink with the method shrink_to_fit<\/span> (line 7) the vector’s capacity to its size.<\/p>\n
Before I present the program’s output on Linux, let me make a few remarks.<\/p>\n
    \n
  1. Adjusting the size and capacity of the container is done automatically. I haven’t used any memory operations like new<\/span> and dele<\/span><\/li>\n
  2. By using the method vec.resize(n)<\/span> the vector vec <\/span>will get new default-initialized elements if <\/span>n > cont.size() <\/span>holds.<\/li>\n
  3. By using the method vec.reserve(n)<\/span> the container vec<\/span> will get new memory for at least n elements if <\/span>n > cont.capacity()<\/span> holds.<\/li>\n
  4. The call shrink_to_fit<\/span> is non-binding. That means the C++ runtime has not had to adjust the capacity of a container to its size. But, using the method shrink_to_fit<\/span> with GCC, clang, or cl.exe always freed the unnecessary memory.<\/li>\n<\/ol>\n
    \"vectorMemory\"<\/p>\n
    Okay, but what is the difference between a C array and a C++ array?<\/p>\n
    std::array<\/h3>\n
    std::array<\/span> combines the best of two worlds. On the one hand, std::array<\/span> has the size and efficiency of a C-array; on the other hand, std::array<\/span> has the interface of a std::vector.<\/span> <\/p>\n
    My small program compares the memory efficiency of a C array, a C++ array (std:<\/span>:array), and a std::vector.<\/span> <\/p>\n
    \n
    \/\/ sizeof.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <array><\/span>\r\n#include <vector><\/span>\r\n \r\nint<\/span> main<\/span>(){\r\n  \r\n  std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n  \r\n  std::<\/span>cout <<<\/span> \"sizeof(int)= \"<\/span> <<<\/span> sizeof<\/span>(int<\/span>) <<<\/span> std::<\/span>endl;\r\n  \r\n  std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n  \r\n  int<\/span> cArr[10<\/span>] =<\/span> {1<\/span>, 2<\/span>, 3<\/span>, 4<\/span>, 5<\/span>, 6<\/span>, 7<\/span>, 8<\/span>, 9<\/span>, 10<\/span>};\r\n  \r\n  std::<\/span>array<<\/span>int<\/span>, 10<\/span>><\/span> cppArr =<\/span> {1<\/span>, 2<\/span>, 3<\/span>, 4<\/span>, 5<\/span>, 6<\/span>, 7<\/span>, 8<\/span>, 9<\/span>, 10<\/span>};\r\n  \r\n  std::<\/span>vector<<\/span>int<\/span>><\/span> cppVec =<\/span> {1<\/span>, 2<\/span>, 3<\/span>, 4<\/span>, 5<\/span>, 6<\/span>, 7<\/span>, 8<\/span>, 9<\/span>, 10<\/span>};\r\n  \r\n  std::<\/span>cout <<<\/span> \"sizeof(cArr)= \"<\/span> <<<\/span> sizeof<\/span>(cArr) <<<\/span> std::<\/span>endl;            \/\/ (1)<\/span>\r\n  \r\n  std::<\/span>cout <<<\/span> \"sizeof(cppArr)= \"<\/span> <<<\/span> sizeof<\/span>(cppArr) <<<\/span> std::<\/span>endl;        \/\/ (2)<\/span>\r\n  \r\n                                                                         \/\/ (3)<\/span>\r\n  \r\n  std::<\/span>cout <<<\/span> \"sizeof(cppVec) = \"<\/span>   <<<\/span> sizeof<\/span>(cppVec) +<\/span> sizeof<\/span>(int<\/span>) *<\/span> cppVec.capacity() <<<\/span> std::<\/span>endl;\r\n  std::<\/span>cout <<<\/span> \"               = sizeof(cppVec): \"<\/span> <<<\/span> sizeof<\/span>(cppVec) <<<\/span> std::<\/span>endl;\r\n  std::<\/span>cout <<<\/span> \"               + sizeof(int)* cppVec.capacity(): \"<\/span>   <<<\/span> sizeof<\/span>(int<\/span>)*<\/span> cppVec.capacity() <<<\/span> std::<\/span>endl;\r\n\r\n  std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n  \r\n}\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    \"sizeof\"<\/p>\n
    The C array (line 1) and the C++ array (line 2) take 40 bytes. That is precisely sizeof(int) * 10.<\/span> In contrast, the std::vector<\/span> needs additional 24 bytes (line 3) to manage its data on the heap. <\/span><\/p>\n
    This was the C part of a std::array, but the std::array supports the interface of a std::vector. This means, in particular, that std:<\/span>:array knows its size; therefore, error-prone interfaces such as the following one are a heavy code smell.<\/p>\n
     <\/p>\n
    \n
    void<\/span> bad<\/span>(int<\/span>*<\/span> p, int<\/span> count){\r\n   ... \r\n}\r\n\r\nint<\/span> myArray[100<\/span>] =<\/span> {0<\/span>};    \r\nbad(myArray, 100<\/span>);\r\n\r\n\/\/ ----------------------------- <\/span>\r\n\r\nvoid<\/span> good<\/span>(std::<\/span>array<<\/span>int<\/span>, 10<\/span>><\/span> arr){\r\n   ...\r\n}\r\n\r\nstd::<\/span>array<<\/span>int<\/span>, 100<\/span>><\/span> myArray =<\/span> {0<\/span>};\r\ngood(myArray);\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    When you use a C array as a function argument, you remove almost all type information and pass it as a pointer to its first argument. This is extremely error-prone because you must also provide the number of elements. If your function accepts a std::array<int, 100><\/span>, this will not hold.<\/p>\n
    You can use a template if the function good is not generic enough.<\/p>\n
    <\/p>\n
    \n
    template<\/span> <<\/span>typename<\/span> T><\/span>\r\nvoid<\/span> foo(T&<\/span> arr){\r\n\r\n   arr.size();                                         \/\/ (1)<\/span>\r\n\r\n}\r\n\r\n\r\nstd::<\/span>array<<\/span>int<\/span>, 100<\/span>><\/span> arr{};                                             \r\nfoo(arr);                                                    \r\n    \r\nstd::<\/span>array<<\/span>double<\/span>, 20<\/span>><\/span> arr2{};\r\nfoo(arr2);  \r\n<\/pre>\n<\/div>\n
     <\/p>\n
    Because a std::array<\/span> knows its size, you can ask for it in line 1.<\/p>\n
    What’s next?<\/h2>\n
    The following two rules for containers are pretty interesting. In the next post<\/a>, I will give an answer to the question: When to use which container?<\/p>\n
     <\/p>\n
     <\/div><\/p>\n","protected":false},"excerpt":{"rendered":"
    The rules to the C++ standard library are mainly about containers, strings, and iostreams.<\/p>\n","protected":false},"author":21,"featured_media":5679,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[372],"tags":[],"class_list":["post-5681","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\/5681","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=5681"}],"version-history":[{"count":0,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5681\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5679"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5681"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5681"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5681"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}