C++ 17 Transformation…—phantom

The transformation is only a beginning towards catching up from C++98, but it does show why modern C++ features improve your code.

C++ 17 Transformation...

by phantom

From the article:

I'm basically really bad at working on my own projects, but with the recent release of Visual Studio 2017 RC and its improved C++17 support I figured it was time to crack on again...

To that end I've spent a bit of time today updating my own basic windowing library to use C++17 features. Some of the things have been simple transforms such as converting 'typedef' to 'using', others have been more OCD satisfying...

Basic dependent typing—Krzysztof Ostrowski

Using fundamental types to do "simple things simple" fits very well in the most of cases.

Basic dependent typing

by Krzysztof Ostrowski

From the article:

If we assume that our application uses only a subset of values carried by given fundamental type, we are likely to get warning from the compiler. We shall take that warning seriously. How to inform type system about our assumptions? Example solutions follow.

Collaborative Online Compilers

I was doing some research on possible live formats...

Collaborative Online Compilers

by Jens Weller

From the article:

While doing some brainstorming for possible (youtube) live formats with C++ content, the thought of having a shared online IDE/Compiler came into my mind. Think of Google Docs but for C++...

The “unsigned” Conundrum—Tony “Bulldozer00” DaSilva

Are you clear with unsigned?

The “unsigned” Conundrum

by Tony “Bulldozer00” DaSilva

From the article:

A few weeks ago, CppCon16 conference organizer Jon Kalb gave a great little lightning talk titled “unsigned: A Guideline For Better Code“. Right up front, he asked the audience what they thought this code would print out to the standard console:

Even though -1 is obviously less 1, the program prints out “a is not less than b“. WTF?

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.

Quick Q: Is the ‘override’ keyword just a check for a overriden virtual method?

Quick A: Yes.

Recently on SO:

Is the 'override' keyword just a check for a overriden virtual method?

That's indeed the idea. The point is that you are explicit about what you mean, so that an otherwise silent error can be diagnosed:

struct Base
    virtual int foo() const;

struct Derived : Base
    virtual int foo()   // whoops!
       // ...

The above code compiles, but is not what you may have meant (note the missing const). If you said instead, virtual int foo() override, then you would get a compiler error that your function is not in fact overriding anything.

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

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.