intermediate

CppCon 2015 Templator: Demo of a nice tool for Visualizing Template Instantiations—Peter Sommerlad

Have you registered for CppCon 2016 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2015 for you to enjoy. Here is today’s feature:

Templator: Demo of a nice tool for Visualizing Template Instantiations

by Peter Sommerlad

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Many C++ beginners shy away from employing templates in their code, because of the myth of templates being hard. Even seasoned C++ developers can have problems manually interpreting template code correctly as Olve Maudal's C++ pub quiz demonstrates. Overloads and template specializations make it hard for programmers and also IDEs to show a developer what happens without compiling a program and even with a compile one might not get, what actually happens unless an unintelligible error message from your compiler appears.

My students tried to alleviate that problem by visualizing template instantiation and overload selection in a C++ IDE and allow to navigate through template code in instantiation context that a compiler would only create internally and that is otherwise not available for humans. While still in its nascent state I hope to show what is possible and if things go as planned at the time of the submission you should be able to solve the template pub quiz questions without running the programs.

CppCon 2015 Programming with less effort C++: Measuring the programming effort…—Sylvain Jubertie

Have you registered for CppCon 2016 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2015 for you to enjoy. Here is today’s feature:

Programming with less effort C++: Measuring the programming effort with metrics

by Sylvain Jubertie

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

The C++ language and libraries propose different ways to implement codes. For example, using explicit loops or STL algorithms to traverse containers and process data. C++11&14 bring also new features to the C++ language aimed at simplifying the writing of codes. But what is the gain we can expect in term of development effort when using these different possibilities and features ? or, as a developer may ask himself: Is it viable for me to spend some time learning new C++ libraries or standards to provide less effort/spend less time on my future codes ?

Before answering these questions, we must give a definition of the development effort, and define a way to measure it. Thus, we first propose to describe existing software metrics, from the simple Single Line Of Code (SLOC) to the more complex Halstead metrics, then to implement them in an automatic tool based on Clang tools, and finally to apply them on several codes to compare their respective development efforts.

First results show that using modern C++ features like auto, decltype and lambdas help to dramatically reduce the development effort. These results may help to convince developers to use new C++ features, or to port their codes from old standards to new ones, or even switch from other languages to C++ !

[C++17] Structured Bindings - Convert struct to a tuple (simple reflection)

An interesting piece of code!

[C++17] Structured Bindings - Convert struct to a tuple (simple reflection)

From the article:

Very simple approach to convert any struct (up to N members) to a tuple using C++17 structured bindings and the idea from Boost.DI (http://boost-experimental.github.io/di/cppnow-2016/#/7/11) used to detect type constructor traits.

CppCon 2015 Lessons in Sustainability: How to Maintain a C++ Codebase for Decades—Titus Winters

Have you registered for CppCon 2016 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2015 for you to enjoy. Here is today’s feature:

Lessons in Sustainability: How to Maintain a C++ Codebase for Decades

by Titus Winters

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Google maintains (we believe) the largest monolithic C++ codebase in the world with over 100M lines of C++ code. Early commits to this repository date back to the late 1990s. About 4000 engineers submit at least one change in C++ every week. We’ve learned a few things about what it takes to maintain a codebase at this scale.

In this talk I’ll present some of the lessons we’ve learned over the years with respect to policies, technology, education, design, and maintenance of a long-lived monolithic codebase.

Quick Q: ‘Constexpr’ vs ‘extern const’. Which has priority?

Quick A: If you need a compile time constant, you cannot use extern.

Recently on SO:

'Constexpr' vs 'extern const'. Which has priority?

Using extern const in the header file only tells the compiler that the variable exists and that it is not modifiable. It doesn't tell the compiler its value which means it's not a compile-time constant anymore. If it's not a compile-time constant then it can't be used for e.g. case or as an array size.

As said by M.M in the comment, either use

const int MAX_NUMBER_OF_ROWS= 99;

or

constexpr int MAX_NUMBER_OF_ROWS= 99;

directly in the header file and it will be a compile-time constant in all translation units that include the header file.

Overload 134 is now available

ACCU’s Overload journal of August 2016 is out. It contains the following C++ related articles.

Overload 134

From the journal:

Some Big-Os are Bigger Than Others
Big-O notation is often used to compare algorithms. Sergey Ignatchenko reminds us that asymptotic limits might not be generally applicable. by Sergey Ignatchenko

Kill the Clones
Problems in code can hide in surprising places. Adam Tornhill demonstrates how to detect software clones and uncover hidden dependencies. by Adam Tornhill

Implementing SNAAAKE
Almost everyone knows the game Snake! Thaddaeus Frogley shares a diary of how his implementation grew over time. by Thaddaeus Frogley

C++ Antipatterns
Certain mistakes crop up frequently in C++. Jonathan Wakely offers some pro-tips to help you avoid common errors. by Jonathan Wakely

Testing Propositions
Is testing propositions more important than having examples as exemplars? Russel Winder considers this hypothesis. by Russel Winder

Quick Q: unordered_map element being deleted

Quick A: Once a value is deleted, iterators pointing to it become invalid.

Recently on SO:

unordered_map element being deleted

After you call my_umap.erase(...), your iterator becomes invalid:

cppreference.com says:

References and iterators to the erased elements are invalidated. Other iterators and references are not invalidated.
This means that once the item is erased, the iterators that pointed to it are no longer valid.

You've got a couple of options:

1. Use the iterator to erase, and use the return value of erase()

Since C++11, erasing by iterator will return an iterator pointing to the next item in the map. So you can use this to keep your iterator valid:

auto it = my_umap.begin();

while (it != my_umap.end()) {

    MyStruct& myStruct = it->second;
    const bool deleteEntry = myStruct.ts.IsElapsed(std::chrono::seconds(5));

    if(deleteEntry){
        assert(my_umap.size() >= 1);
        it = my_umap.erase(it);  // <-- Return value should be a valid iterator.
    }
    else{
        ++it;  // Have to manually increment.
    }
}

2. Store your iterators in a list object and erase after iteration.

Alternatively, you can store delete candidates in a list object (e.g. vector and delete them after your initial iteration:

std::vector<MapType::iterator> deleteCandidates;

for(auto it = my_umap.begin(); it != my_umap.end(); ++it){

    MyStruct& myStruct = it->second;
    const bool deleteEntry = myStruct.ts.IsElapsed(std::chrono::seconds(5));

    if(deleteEntry)
        deleteCandidates.push_back(it);
}

for (auto it : deleteCandidates) {
    my_umap.erase(it);
}

As for why your assertion is failing, you're probably encountering undefined behaviour by accessing an invalid iterator, making your for loop believe that the map is still not empty (because invalidIterator != my_umap.end()).

Quick Q: Why doesn’t c++ have a specified order for evaluating function arguments?

Quick A: In order to get the best performance.

recently on SO:

Why doesn't c++ have a specified order for evaluating function arguments?

C++ leaves as much as practical up to the implementation of the compiler, especially where optimization opportunities might occur. Before fixing something like this, existing compiler writers are consulted to see if there is a cost.

Some order of evaluation guarantees surrounding overloaded operators and complete-argument rules where added in C++17. But it remains that which argument goes first is left unspecified. In C++17, it is now specified that the expression giving what to call (the code on the left of the ( of the function call) goes before the arguments, and whichever argument is evaluated first is evaluated fully before the next one is started, and in the case of an object method the value of the object is evaluated before the arguments to the method are. (There may be some minor errors in this description: ask a narrow question about it for a more vetted answer).

These where vetted and determined to not cause significant prolems for existing compilers. Reordering of arguments was considered, and discarded, presumably for good reasons. Or even poor reasons, like existing compilers have a default order and it could break (possibly non-compliant) code on that compiler to force them all to do it in one global order.

In short, C++ leaves lots of freedom to compiler writers. This has let compiler writers find optimization opportunities in strange crannies. The kind of optimizations available today are way beyond what the original writers of C++, let alone C++, may have suspected where practical or be considered reasonable.