August 2016

CppCon 2016: David Schwartz Keynote and Jason Turner Plenary

cppcon-037.PNGDavid Schwartz, the Chief Cryptographer of the Ripple distributed payment system, will be presenting a keynote at CppCon 2016 about developing blockchain software in C++.

Also, Jason Turner will give a plenary talk about using C++17 to write high-performance code on the Commodore 64.

You can read more about their talks here.

There’s still time to register for CppCon 2016! Come join us in September!

Cppcheck-1.75 has been released--Daniel Marjamäki

A new version is here!

Cppcheck-1.75 has been released

by Daniel Marjamäki

From the article:

General changes:

  • Replaced internal preprocessor by the brand-new preprocessor 'simplecpp'
  • Improved Windows installer: Install a copy of the license instead of asking to accept it
  • The Windows x64 binaries are now compiled with profile guided optimization, resulting in a speedup of 11%
  • Improved manual, especially the chapter about Libraries
  • Improved CWE mapping
  • --append is deprecated and will be removed in 1.80...

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()).

CppCon 2015 Reflection Techniques in C++--Paul Fultz II

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:

Reflection Techniques in C++

by Paul Fultz II

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Reflection is a very powerful and useful feature used in many languages to achieve things like serialization, object-relationship mapping, and general data-driven development. C++ doesn't support reflection natively in the language yet. There are proposals to add compile-time reflection to the language, but C++ has survived all this time without direct support for reflection.

This talk will discuss the various techniques the can be used to achieve reflection including boost fusion, the visitor patter, and do-it-yourself with some macros and metaprogramming. This talk will discuss how these techniques can be used to implement serialization or object-relational mapping.

CppCon 2015 constexpr: Applications--Scott Schurr

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:

constexpr: Applications

by Scott Schurr

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

I'm excited about constexpr. It's probably my favorite C++11 feature and it's gotten even better with C++14. But when I talk to other developers about constexpr they seem puzzled. What sorts of useful computations can the compiler possibly do before runtime?

I'd like to take this session to explore some of the capabilities that constexpr brings to the table. We'll look at compile-time parsing, floating-point computations, and containers. We'll also talk about motivations for computing these at compile time.

This session builds on the "constexpr: Introduction" talk.