Home » Blog » Tags » basics

basics

Quick Q: Initializing a std::string with function return value, is there a copy?

By Adrien Hamelin | Sep 29, 2016 11:47 AM | Tags: c++11 basics

Quick A: No, at worse it will be a move.

Recently on SO:

Initializing a std::string with function return value, is there a copy?

In general, if the std::string is constructed in the call and then returned most modern compilers with apply the return value optimization (a special case of copy elision). Your case in particular is the Named RVO (thanks @NathanOliver for pointing this out), if you want to look up the precise rules. From C++17 on this optimization is guaranteed through the standard.

Whether or not the optimization is applied is hard to tell, however if it is not, then in C++11 and above it is very likely that the std::string object in the scope of the function will be moved from and that the return value will be moved to. You could theoretically call std::move on the return value, but thereby you would also prevent any RVO from happening. While move may be efficient, RVO typically yields faster code, because nothing is moved or copied at all, but the object is constructed in place, so I would advise against doing it, and in favor of relying on your compiler.

How to avoid bugs using modern C++

By Andrey Karpov | Sep 15, 2016 05:11 AM | Tags: c++17 c++11 basics

One of the main problems with C++ is having a huge number of constructions whose behavior is undefined, or is just unexpected for a programmer. Let's see which techniques in modern C++ help writing not only simple and clear code, but make it safer and more reliable.

How to avoid bugs using modern C++

by Pavel Belikov

From the article:

Of course, there are some flaws in the range-based for: it doesn't allow flexible management of the loop, and if there is more complex work with indexes required, then for won't be of much help to us. But such situations should be examined separately. We have quite a simple situation: we have to move along the items in the reverse order. However, at this stage, there are already difficulties. There are no additional classes in the standard library for range-based for. Let's see how it could be implemented.

Great Expectations--Glennan Carnie

By Adrien Hamelin | Sep 9, 2016 12:06 PM | Tags: c++11 basics

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

By Adrien Hamelin | Sep 7, 2016 02:37 PM | Tags: c++11 basics

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

By Andrey Karpov | Sep 1, 2016 02:01 AM | Tags: static code analysis pvs-studio gcc bugs basics

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.