October 2016

Finding bugs in the code of LLVM project with the help of PVS-Studio

Let's take a look at the suspicious fragments in the LLVM code which PVS-Studio detected.

Finding bugs in the code of LLVM project with the help of PVS-Studio

by Andrey Karpov

From the article:

LLVM developers, of course, will be able to understand if there is a bug here or not. I have to play detective. Looking at the code, I was thinking in the following direction: The function should read the opening bracket '<', then it reads the identifiers and commas in the loop. If there is no comma, we expected a closing bracket. If something goes wrong, then the function returns an error code. I reckon there was supposed to be the following algorithm of the function work (pseudocode).

CppCast Episode 76: Embedded Development with Dan Saks

Episode 76 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Dan Saks from Saks & Associates to discuss state of C++ in the embedded development industry.

CppCast Episode 76: Embedded Development with Dan Saks

by Rob Irving and Jason Turner

About the interviewee:

Dan Saks is the president of Saks & Associates, which offers training and consulting in C and C++ and their use in developing embedded systems. He has been a columnist for The C/C++ Users Journal, The C++ Report, Embedded Systems Design, embedded.com and several other publications. Dan served as the first secretary of the C++ Standards Committee and contributed to the CERT Secure Coding Standards for C and C++.

Modern C++ Features – User-Defined Literals--Arne Mertz

Learn more about litterals.

Modern C++ Features – User-Defined Literals

by Arne Mertz

From the article:

User-defined literals are a convenient feature added in C++11.

C++ always had a number of built-in ways to write literals: Pieces of source code that have a specific type and value. They are part of the basic building blocks of the language:

32 043 0x34   //integer literals, type int
4.27 5E1      //floating point literals, type double
'f', '\n'     //character literals, type char
"foo"         //string literal, type const char[4]
true, false   //boolean literals, type bool

These are only the most common ones, there are many more, including some newcomers in the newer standards. Other literals are nullptr and different kinds of prefixes for character and string literals. There also are suffixes we can use to change the type of a built-in numeric literal:

32u     //unsigned int
043l    //long
0x34ull //unsigned long long
4.27f   //float
5E1l    //long double

void foo(T& out) - How to fix output parameters--Jonathan Müller

Or how to improve readability and reduce errors.

void foo(T& out) - How to fix output parameters

by Jonathan Müller

From the article:

There are some cases where you need to return a value from a function but cannot use the return value. It happens, for example, in functions where you want to return multiple values at once. While you can pass multiple inputs to a function - the parameters, you cannot pass multiple return values in the same way.

C++ programmers tend to use a good old (lvalue) reference for that. You take a non-const reference as parameter and assign the output to that reference. The caller will pass a variable and upon function completion find the value of the variable changed.

Yet this approach has some problems: For starters, it is not obvious when just looking at the call that the variable is going to be changed. This is the reason that C++ style guides such as the one used by Google recommend using a pointer for that. The caller then has to explicitly pass in the address of the variable, making it explicit.

But with a pointer you can now pass in nullptr, you have to check for that in the function: A pointer where you really mean “reference” does not follow the guidelines I’ve been advocating for.

So is there not a universal solution?

There is, but first we need to understand the full scope of the problem.

Quick Q: Is std::vector so much slower than plain arrays?

Quick A: A vector isn’t slower than an array when they do the same things. But it lets you do much more…

Some time ago on SO:

Is std::vector so much slower than plain arrays?

Using the following:

g++ -O3 Time.cpp -I <MyBoost>
./a.out
UseArray completed in 2.196 seconds
UseVector completed in 4.412 seconds
UseVectorPushBack completed in 8.017 seconds
The whole thing completed in 14.626 seconds


So array is twice as quick as vector.

But after looking at the code in more detail this is expected; as you run across the vector twice and the array only once. Note: when you resize() the vector you are not only allocating the memory but also running through the vector and calling the constructor on each member.

Re-Arranging the code slightly so that the vector only initializes each object once:

std::vector<Pixel>  pixels(dimensions * dimensions, Pixel(255,0,0));

Now doing the same timing again:

g++ -O3 Time.cpp -I <MyBoost>
./a.out
UseVector completed in 2.216 seconds


The vector now performance only slightly worse than the array. IMO this difference is insignificant and could be caused by a whole bunch of things not associated with the test.

I would also take into account that you are not correctly initializing/Destroying the Pixel object in the UseArrray() method as neither constructor/destructor is not called (this may not be an issue for this simple class but anything slightly more complex (ie with pointers or members with pointers) will cause problems.

Presenting Code

How should we present code? - is the question.

Presenting Code

by Jens Weller

From the article:

At CppCon 2015 I decided to give a small lightning talk on how to present code in the coming year. This was a reflection on visiting many C++ related conferences and seeing many talks live and online...

Recommendations to speed C++ builds in Visual Studio--Sridhar Madhugiri

This post discusses features, techniques and tools you can use to reduce build time for C++ projects:

Recommendations to speed C++ builds in Visual Studio

by Sridhar Madhugiri

From the article:

Developers invoke build frequently while writing and debugging code, so improvements here can have a large impact on productivity. Many of the recommendations focus on this stage...