basics

Great Expectations--Glennan Carnie

Let's review the basics!

Great Expectations

by Glennan Carnie

From the article:

Previously, we’ve looked at the basic concepts of function parameter passing, and we’ve looked at the mechanics of how parameters are passed at the Application Binary Interface (ABI) level.

Far too often we focus on the mechanisms and efficiency of parameter passing, with the goal: if it’s efficient then it’s good; that’s all there is to it.  In this article I want to move past simple mechanics and start to explore function parameter design intent – that is, what can I expect (to change) about the objects I use as function arguments; and what can I expect to be able to do with an object as a function implementer.

To that end, we’ll take a look at parameter passing from the perspective of the mutability (ability to be modified) of the parameters from both a caller’s and a function’s (callee’s) point of view...

Quick Q: Marking std::unique_ptr class member as const

Quick A: It prevents you of being able to move your class.

Recently on SO:

Marking std::unique_ptr class member as const

Because of the nature of a std::unique_ptr (sole ownership of an object) it's required to have no copy constructor whatsoever. The move constructor(6) only takes non-const rvalue-references which means that if you'd try to make your _child const and move it you'd get a nice compilation error smile

Even if a custom unique_ptr would take a const rvalue-reference it would be impossible to implement.

Bugs found in GCC with the help of PVS-Studio

I regularly check various open-source projects to demonstrate the abilities of the PVS-Studio static code analyzer (C, C++, C#). Now it is time for the GCC compiler to get checked.

Bugs found in GCC with the help of PVS-Studio

by Andrey Karpov

From the article:

This part could also be called "Example number one thousand, why macros are bad". I really don't like macros and always urge people to avoid using them if possible. Macros make it difficult to read the code, provoke errors, and make the work of static analyzers harder. As best I can tell, from a brief interaction with the GCC code, the authors are big fans of macros. I was really tired looking at what the macros are expanded to, and perhaps missed quite a number of interesting errors. I should confess that I was lazy at times. But still, I will demonstrate a couple of errors, connected with macros.

Top 15 C++ Exception handling mistakes and how to avoid them--Deb Haldar

This article changed my vision about exceptions:

Top 15 C++ Exception handling mistakes and how to avoid them

by Deb Haldar

From the article:

Do you use exception handling in your C++ code?

If you don’t, why not?

Perhaps you’ve been conditioned to believe that exception handling is bad practice in C++. Or maybe you think that it’s prohibitively expensive in terms of performance. Or maybe it’s just not the way your legacy code is laid out and you’re stuck in the rut.

Whatever your reason is, it’s probably worth noting that using C++ Exceptions instead of error codes has a lot of advantages. So unless you’re coding some real-time or embedded systems, C++ exceptions can make your code more robust, maintainable and performant in the normal code path (yes performant, you read that right !).

In this article we’re going to look at 15 mistakes that a lot of developers make when just stating off with C++ exceptions or considering using C++ exceptions...