{"id":5751,"date":"2019-08-01T07:54:31","date_gmt":"2019-08-01T07:54:31","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-supporting-sections\/"},"modified":"2023-06-26T10:03:56","modified_gmt":"2023-06-26T10:03:56","slug":"c-core-guidelines-supporting-sections","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-supporting-sections\/","title":{"rendered":"C++ Core Guidelines: Supporting Sections"},"content":{"rendered":"<p>Let&#8217;s recapitulate. I have written about 100 posts on the C++ Core Guidelines in the last two years. Why? The document answers:&nbsp; &#8220;<em>This document is a set of guidelines for using C++ well. this document aims to help people to use modern C++ effectively.&#8221;.<\/em> But my story does not end here. The guidelines have a supporting section.<em><br \/><\/em><\/p>\n<p><!--more--><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" size-full wp-image-5750\" src=\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/08\/cog-wheels-2125178_1280.jpg\" alt=\"cog wheels 2125178 1280\" width=\"500\" height=\"281\" style=\"display: block; margin-left: auto; margin-right: auto;\" srcset=\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/08\/cog-wheels-2125178_1280.jpg 1280w, https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/08\/cog-wheels-2125178_1280-300x169.jpg 300w, https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/08\/cog-wheels-2125178_1280-1024x576.jpg 1024w, https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/08\/cog-wheels-2125178_1280-768x432.jpg 768w\" sizes=\"auto, (max-width: 500px) 100vw, 500px\" \/><\/p>\n<p>I know, 100 posts are quite a lot. Before I dive into the supporting sections of the guidelines, I want to give you assistance to find my existing posts to the C++ Core Guidelines.<\/p>\n<ol>\n<li>You can use the category<a href=\"https:\/\/www.modernescpp.com\/index.php\/category\/modern-c?start=90\"> C++ Core Guidelines<\/a> and get all posts.<\/li>\n<li>You can directly jump to the TOC<a href=\"https:\/\/www.modernescpp.com\/index.php\/der-einstieg-in-modernes-c\"> &gt;&gt;Start Here&lt;&lt;<\/a>&nbsp; of my blog. Here is the section to the&nbsp; <a href=\"https:\/\/www.modernescpp.com\/index.php?option=com_content&amp;view=article&amp;id=170;modern-c&amp;catid=39;ueberblick#CppCoreGuidelines\">C++ Core Guidelines<\/a> in my 300 posts.<\/li>\n<\/ol>\n<p>Here is an overview of the supporting sections.<\/p>\n<ul>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-A\">A: Architectural ideas<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-not\">NR: Non-Rules and myths<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-references\">RF: References<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-profile\">Pro: Profiles<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-gsl\">GSL: Guidelines support library<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-naming\">NL: Naming and layout rules<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-faq\">FAQ: Answers to frequently asked questions<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-libraries\">Appendix A: Libraries<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-modernizing\">Appendix B: Modernizing code<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-discussion\">Appendix C: Discussion<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-tools\">Appendix D: Supporting tools<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-glossary\">Glossary<\/a><\/li>\n<li><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-unclassified\">To-do: Unclassified proto-rules<\/a><\/li>\n<\/ul>\n<p>Let&#8217;s see what&#8217;s inside.<\/p>\n<h2><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#S-A\">A: Architectural ideas<\/a><\/h2>\n<p>The first section is relatively short. It has only three rules which are a few sentences of content. Their focus is programming language agnostic.<\/p>\n<h3><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#Ra-stable\">A.1: Separate stable code from less stable code<\/a><\/h3>\n<p>Here is the sentence to the rule: &#8220;<em>Isolating less stable code facilitates its unit testing, interface improvement, refactoring, and eventual deprecation.&#8221;<\/em> Okay, what does that mean?<\/p>\n<p>Putting an interface between stable and less stable code is the way to separate it. Due to the interface, your less stable code becomes a sub-system that you can test or refactor in isolation. You can now test the sub-system and the integration of the sub-system into the application. The first test is typically called a unit test, and the second is a sub-system integration test. The sub-system has two channels to the app: the functional and the non-functional channel. Both have to be tested. The functional channel provides the functionality of the sub-system, and the non-functional channel the exceptions that can happen and to which the application may react. Thanks to the interface, the concrete sub-system implements the interface and can, therefore, be quite quickly replaced by another, maybe more stable implementation.<\/p>\n<\/p>\n<h3><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#Ra-lib\">A.2: Express potentially reusable parts as a library<\/a><\/h3>\n<p>Okay, this is relatively easy, but there is a more difficult question two answer in this regard.<\/p>\n<ol>\n<li>When is a part of software potentially reusable?<\/li>\n<li>When do the costs of implementing the library pay off?<\/li>\n<li>What is the right kind of abstraction?<\/li>\n<\/ol>\n<p>The three questions are blurry and, therefore, difficult to answer. This holds in particular for the last question. Let me try it.<\/p>\n<p>First, don&#8217;t put too much effort into making your code reusable as a library because &#8220;You aren&#8217;t gonna need it&#8221; (<a href=\"https:\/\/en.wikipedia.org\/wiki\/You_aren%27t_gonna_need_it\">YAGNI<\/a>),&nbsp; but write your code so it can be reusable. This means following simple guidelines such as writing your code for understandability, maintainability, testability, and other abilities because it is highly probable that you or another programmer has to work with your code in the future. Or to say it in the words of Philip Wadler: &#8220;<span class=\"css-901oao css-16my406 r-1qd0xha r-ad9z0x r-bcqeeo r-qvutc0\"><em>Make your code readable. Pretend the next person who looks at your code is a psychopath, and he knows where you live.<\/em>&#8220;<\/span><\/p>\n<p>&#8220;Don&#8217;t repeat yourself&#8221; (<a href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a>) when you need the same or similar functionality again. Now you should think about the very latest about abstraction. When I have two similar functions, I write a third function which stands for the implementation, and the similar functions are just wrappers for using the implementation function.&nbsp; Here are my ideas, put into code to make my point.<\/p>\n<div style=\"background: #f0f3f3; overflow: auto; width: auto; gray;border-width: .1em .1em .1em .8em;\">\n<pre style=\"margin: 0; line-height: 125%;\">std<span style=\"color: #555555;\">::<\/span>vector<span style=\"color: #555555;\">&lt;<\/span><span style=\"color: #007788; font-weight: bold;\">void<\/span><span style=\"color: #555555;\">*&gt;<\/span> myAlloc;\r\n\r\n<span style=\"color: #007788; font-weight: bold;\">void<\/span><span style=\"color: #555555;\">*<\/span> <span style=\"color: #cc00ff;\">newImpl<\/span>(std<span style=\"color: #555555;\">::<\/span><span style=\"color: #007788; font-weight: bold;\">size_t<\/span> sz,<span style=\"color: #007788; font-weight: bold;\">char<\/span> <span style=\"color: #006699; font-weight: bold;\">const<\/span><span style=\"color: #555555;\">*<\/span> file, <span style=\"color: #007788; font-weight: bold;\">int<\/span> line){           <span style=\"color: #0099ff; font-style: italic;\">\/\/ (3)<\/span>\r\n    <span style=\"color: #006699; font-weight: bold;\">static<\/span> <span style=\"color: #007788; font-weight: bold;\">int<\/span> counter{};\r\n    <span style=\"color: #007788; font-weight: bold;\">void<\/span><span style=\"color: #555555;\">*<\/span> ptr<span style=\"color: #555555;\">=<\/span> std<span style=\"color: #555555;\">::<\/span>malloc(sz);\r\n    std<span style=\"color: #555555;\">::<\/span>cerr <span style=\"color: #555555;\">&lt;&lt;<\/span> file <span style=\"color: #555555;\">&lt;&lt;<\/span> <span style=\"color: #cc3300;\">\": \"<\/span> <span style=\"color: #555555;\">&lt;&lt;<\/span> line <span style=\"color: #555555;\">&lt;&lt;<\/span> <span style=\"color: #cc3300;\">\" \"<\/span> <span style=\"color: #555555;\">&lt;&lt;<\/span>  ptr <span style=\"color: #555555;\">&lt;&lt;<\/span> std<span style=\"color: #555555;\">::<\/span>endl;\r\n    myAlloc.push_back(ptr);\r\n    <span style=\"color: #006699; font-weight: bold;\">return<\/span> ptr;\r\n}\r\n\r\n<span style=\"color: #007788; font-weight: bold;\">void<\/span><span style=\"color: #555555;\">*<\/span> <span style=\"color: #006699; font-weight: bold;\">operator<\/span> <span style=\"color: #cc00ff;\">new<\/span>(std<span style=\"color: #555555;\">::<\/span><span style=\"color: #007788; font-weight: bold;\">size_t<\/span> sz,<span style=\"color: #007788; font-weight: bold;\">char<\/span> <span style=\"color: #006699; font-weight: bold;\">const<\/span><span style=\"color: #555555;\">*<\/span> file, <span style=\"color: #007788; font-weight: bold;\">int<\/span> line){      <span style=\"color: #0099ff; font-style: italic;\">\/\/ (1)<\/span>\r\n    <span style=\"color: #006699; font-weight: bold;\">return<\/span> newImpl(sz,file,line);\r\n}\r\n\r\n<span style=\"color: #007788; font-weight: bold;\">void<\/span><span style=\"color: #555555;\">*<\/span> <span style=\"color: #006699; font-weight: bold;\">operator<\/span> <span style=\"color: #006699; font-weight: bold;\">new<\/span> [](std<span style=\"color: #555555;\">::<\/span><span style=\"color: #007788; font-weight: bold;\">size_t<\/span> sz,<span style=\"color: #007788; font-weight: bold;\">char<\/span> <span style=\"color: #006699; font-weight: bold;\">const<\/span><span style=\"color: #555555;\">*<\/span> file, <span style=\"color: #007788; font-weight: bold;\">int<\/span> line){   <span style=\"color: #0099ff; font-style: italic;\">\/\/ (2) <\/span>\r\n    <span style=\"color: #006699; font-weight: bold;\">return<\/span> newImpl(sz,file,line);\r\n}\r\n<\/pre>\n<\/div>\n<p>&nbsp;<\/p>\n<p>The overloaded new operators in the simple form (line 1) and arrays (line 2) invoke the implementation in line (3).<\/p>\n<p>I don&#8217;t want to answer question 3 because the answer depends on many factors. It depends on the domain of the software. Does the software, for example, run on a desktop, embedded device, or a high-trading server? It depends on factors such as maintainability, testability, and scalability, &#8230; but also on performance. It depends on the skill level of the users. Maybe, your library is an infrastructure library or a library for your customers.<\/p>\n<p>Writing reusable software in the form of a library is about 3-4 times more effort than doing a one-way shoot. My rule of thumb is to<strong> think about a library when you know you will reuse the functionality. You should write a library when you reuse the functionality at least two times<\/strong>.<\/p>\n<h3><a href=\"https:\/\/isocpp.github.io\/CppCoreGuidelines\/CppCoreGuidelines#Ra-dag\">A.4: There should be no cycles among libraries<\/a><\/h3>\n<p>Cycles among libraries make your software system more complicated. First, it makes your libraries challenging to test but impossible to reuse independently. Second, your libraries become more challenging to understand, maintain, and extend. When you find such a dependency, you should break it. There are a few possibilities due to <a href=\"https:\/\/codedive.pl\/index\/speaker\/name\/john-lakos\">John Lakos<\/a> (Large Scale C++ Software Design, p185):<\/p>\n<ol>\n<li>Repackage <span style=\"font-family: courier new, courier;\">c1<\/span> and <span style=\"font-family: courier new, courier;\">c2<\/span> so they are no longer mutually dependent.<\/li>\n<li>Physically combine <span style=\"font-family: courier new, courier;\">c1<\/span> and <span style=\"font-family: courier new, courier;\">c2<\/span> into a single component, c12.<\/li>\n<li>Think of <span style=\"font-family: courier new, courier;\">c1<\/span> and <span style=\"font-family: courier new, courier;\">c2<\/span> as a single component, <span style=\"font-family: courier new, courier;\">c12<\/span>.<\/li>\n<\/ol>\n<h2>What&#8217;s next?<\/h2>\n<p>The following supporting section to non-rules and myths has more content. I assume you already know most of the non-rules as myths. Let me demystify them in my <a href=\"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-non-rules-and-myths\">next post<\/a>.<\/p>\n<p>&nbsp;<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Let&#8217;s recapitulate. I have written about 100 posts on the C++ Core Guidelines in the last two years. Why? The document answers:&nbsp; &#8220;This document is a set of guidelines for using C++ well. this document aims to help people to use modern C++ effectively.&#8221;. But my story does not end here. The guidelines have a [&hellip;]<\/p>\n","protected":false},"author":21,"featured_media":5750,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[372],"tags":[],"class_list":["post-5751","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\/5751","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=5751"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5751\/revisions"}],"predecessor-version":[{"id":6777,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5751\/revisions\/6777"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5750"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5751"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5751"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5751"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}