intermediate

Getting your head around auto’s type-deduction rules--Glennan Carnie

Are the rules clear to you?

Getting your head around auto’s type-deduction rules

by Glennan Carnie

From the article:

Automatic type-deduction is perhaps one of the more divisive features of Modern C++.  At its core it’s a straightforward concept:  let the compiler deduce the type of an object from its initialiser.   Used in the right way this can improve the readability and maintainability of your code.

However, because auto is based on template type-deduction rules there are some subtleties that can catch the unwary programmer.

In this article we’ll have a look at auto in the context of the template type-deduction rules to see where all these subtleties come from...

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

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.

Tutorial: Emulating strong/opaque typedefs in C++--Jonathan Müller

Who would like this feature?

Tutorial: Emulating strong/opaque typedefs in C++

by Jonathan Müller

From the article:

Last week, I’ve released my type_safe library. I described it’s features in the corresponding blog post but because the blog post got rather long, I couldn’t cover one feature: strong typedefs.

Strong or opaque typedefs are a very powerful feature if you want to prevent errors with the type system - and as I’ve been advocating for, you want that. Unlike “normal” typedefs, they are a true type definition: they create a new type and allow stuff like overloading on them and/or prevent implicit conversions.

DLib 19.2 released

Today a new version of DLib is available:

DLib 19.2 released

Release notes

by Davis King

From the article:

... So the obvious thing to do was to add an implementation of MMOD with the HOG feature extraction replaced with a convolutional neural network.  The new version of dlib, v19.2, contains just such a thing.  On this page you can see a short tutorial showing how to train a convolutional neural network using the MMOD loss function.  It uses dlib's new deep learning API to train the detector end-to-end on the very same 4 image dataset used in the HOG version of the example program.  Happily, and very much to the surprise of myself and my colleagues, it learns a working face detector from this tiny dataset.