C++ Core Guidelines: Supporting Sections

Contents[Show]

Let's recapitulate. In the last two years, I have written about 100 posts to the C++ Core Guidelines. Why? The document answers:  "This document is a set of guidelines for using C++ well. The aim of this document is to help people to use modern C++ effectively.". But my story does not end here. The guidelines have a supporting section.

cog wheels 2125178 1280

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.

  1. You can use the category C++ Core Guidelines and get all posts.
  2. You can directly jump to the TOC >>Start Here<<  of my blog. Here is the section to the  C++ Core Guidelines in my 300 posts.

Here is an overview of the supporting sections.

Let's see what's inside.

A: Architectural ideas

The first section is quite short. It has only three rules which a few sentences of content. There focus is programming language agnostic.

A.1: Separate stable code from less stable code

Here is the sentence to the rule: "Isolating less stable code facilitates its unit testing, interface improvement, refactoring, and eventual deprecation." Okay, what does that mean?

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 kind of a sub-system, which you can test or refactor in isolation. You can now not only test the sub-system but also the integration of the sub-system into the application. The first kind of tests is typically called unit-test and the second 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 is an implementation of the interface and can, therefore, quite quickly replaced by another, maybe more stable implementation.

A.2: Express potentially reusable parts as a library

Okay, this is quite easy, but there are more difficult question two answer in this regard.

  1. When is a part of software potentially reusable?
  2. When do the costs of implementing the library pay off?
  3. What is the right kind of abstraction?

The three questions are quite blurry and are, therefore, difficult to answer. This holds in particular for the last question. Let me try it.

First of all, don't put too much effort into your code to make it reusable as a library because "You aren't gonna need it" (YAGNI),  but write your code that it could be reusable. This means, follow simple guidelines such as writing your code for understandability, maintainability, testability and other abilities because it's is highly probable, that you or another programmer has to work with your code in the future. Or to say it with the words of Philip Wadler: "Make your code readable. Pretend the next person who looks at your code is a psychopath and he knows where you live."

"Don't repeat yourself" (DRY), when you need the same or similar functionality once more. Now you should think 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.  Here are my ideas, put into code to make my point.

std::vector<void*> myAlloc;

void* newImpl(std::size_t sz,char const* file, int line){           // (3)
    static int counter{};
    void* ptr= std::malloc(sz);
    std::cerr << file << ": " << line << " " <<  ptr << std::endl;
    myAlloc.push_back(ptr);
    return ptr;
}

void* operator new(std::size_t sz,char const* file, int line){      // (1)
    return newImpl(sz,file,line);
}

void* operator new [](std::size_t sz,char const* file, int line){   // (2) 
    return newImpl(sz,file,line);
}

 

The overloaded new operators in the simple form (line 1) and for arrays (line 2) invoke the implementation in line (3).

I don'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, scalability, ... 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.

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 the thumb is: You should 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.

A.4: There should be no cycles among libraries

Cycles among libraries make your software-system more complicated. First, it makes your libraries difficult to test but impossible to reuse independently. Second, your libraries become more difficult to understand, maintain, and extend. When you find such a dependency, you should break it. There are a few possibilities due to John Lakos (Large Scale C++ Software Design, p185):

  1. Repackage c1 and c2 so they are no longer mutually dependent.
  2. Pysically combine c1 and c2 into a single component, c12.
  3. Think of c1 and c2 as if they were a single component, c12.

What's next?

The next 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 next post.

 

Thanks a lot to my Patreon Supporters: Paul Baxter,  Meeting C++, Matt Braun, Avi Lachmish, Roman Postanciuc, Venkata Ramesh Gudpati, Tobias Zindl, Marko, Ramesh Jangama, G Prvulovic, Reiner Eiteljörge, Benjamin Huth, Reinhold Dröge, Timo, Abernitzke, Richard Ohnemus , Frank Grimm, Sakib, and Broeserl.

 

Thanks in particular to:
 TakeUpCode 450 60
crp4

 

   

Get your e-book at Leanpub:

The C++ Standard Library

 

Concurrency With Modern C++

 

Get Both as one Bundle

cover   ConcurrencyCoverFrame   bundle
With C++11, C++14, and C++17 we got a lot of new C++ libraries. In addition, the existing ones are greatly improved. The key idea of my book is to give you the necessary information to the current C++ libraries in about 200 pages.  

C++11 is the first C++ standard that deals with concurrency. The story goes on with C++17 and will continue with C++20.

I'll give you a detailed insight in the current and the upcoming concurrency in C++. This insight includes the theory and a lot of practice with more the 100 source files.

 

Get my books "The C++ Standard Library" (including C++17) and "Concurrency with Modern C++" in a bundle.

In sum, you get more than 600 pages full of modern C++ and more than 100 source files presenting concurrency in practice.

 

Get your interactive course

 

Modern C++ Concurrency in Practice

C++ Standard Library including C++14 & C++17

educative CLibrary

Based on my book "Concurrency with Modern C++" educative.io created an interactive course.

What's Inside?

  • 140 lessons
  • 110 code playgrounds => Runs in the browser
  • 78 code snippets
  • 55 illustrations

Based on my book "The C++ Standard Library" educative.io created an interactive course.

What's Inside?

  • 149 lessons
  • 111 code playgrounds => Runs in the browser
  • 164 code snippets
  • 25 illustrations

Add comment


Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 1351

All 2412896

Currently are 134 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments