intermediate

The Case for Optional References--Tristan Brindle

And why not simply use a pointer?

The Case for Optional References

by Tristan Brindle

From the article:

I have a confession to make. Whenever I’ve come across code that looks like this:

struct example {
    example() = default;

    example(std::string& s) : str_{s} {}

private:
    boost::optional<std::string&> str_{};
};

there is a little voice inside my head that whispers “why didn’t you just use a pointer?”. Like so, for instance:

struct example {
    example() = default;

    example(std::string& s) : str_{&s} {}

private:
    std::string* str_ = nullptr;
};

This is equivalent to the first example, except that it’s slightly less typing, it doesn’t have any dependencies, and feels in some sense “cleaner”. I personally have always preferred it.

Except, I was wrong. After attending Bjarne Stroustrup’s keynote and this excellent talk at Cppcon this morning, I’m persuaded that optional references are a good thing. In this post I hope to be able to convince you of the same...

Quick Q: std::ignore for ignoring unused variable

Quick A: While in theory possible, it is not the intended usage and other solutions exist.

Recently on SO:

std::ignore for ignoring unused variable

std::ignore may work but it is intended to be used for tuples. So you need to include the tuple header and who knows what operations are done for the assignment. This also may break in another c++ version because it was never documented to be used that way.

A better way for this is the C++17 attribute [[maybe_unused]]

void func([[maybe_unused]] int i)
{
}

It places the declaration right at the variable declaration, so you don't have to declare it in an extra line/statement.

The same can be used for local (and local-static) variables

...
[[maybe_unused]] static int a = something();
...

And also for many more:

Appears in the declaration of a class, a typedef­, a variable, a non­static data member, a function, an enumeration, or an enumerator. If the compiler issues warnings on unused entities, that warning is suppressed for any entity declared maybe_unused.

See http://en.cppreference.com/w/cpp/language/attributes

As for the people concerned that you can still use the variables after you declare them unused:

Yes, this is possible but (at least with clang) you will get warnings in case you use maybe_unused declared variables.

Exploring std::string--Shahar Mike

The insides are revealed:

Exploring std::string

by Shahar Mike

From the article:

Every C++ developer knows that std::string represents a sequence of characters in memory. It manages its own memory, and is very intuitive to use. Today we’ll explore std::string as defined by the C++ Standard, and also by looking at 4 major implementations.

Type annotation in C++--Stoyan Nikolov

How do you do it?

Type annotation in C++

by Stoyan Nikolov

From the article:

In systems like game engines and our HTML renderer Hummingbird, developers have to work with objects transformed in different coordinate systems. Using one generic type can lead to confusion on what object is required in a particular situation. Errors are often subtle and hard to track. I tried to mitigate this by using stringent static typing in our software. New types are created by annotating them with metadata...

Auto Type Deduction in Range-Based For Loops--Petr Zemek

Which one to use?

Auto Type Deduction in Range-Based For Loops

by Petr Zemek

From the article:

Have you ever wondered which of the following variants you should use in range-based for loops and when? auto, const auto, auto&, const auto&, auto&&, const auto&&, or decltype(auto)? This post tries to present rules of thumb that you can use in day-to-day coding. As you will see, only four of these variants are generally useful.

Quick Q: Is the std::array bit compatible with the old C array?

Quick A: Yes, you can copy bitwisely from one to the other.

Recently on SO:

Is the std::array bit compatible with the old C array?

The requirement on the data() method is that it return a pointer T* such that:

[data(), data() + size()) is a valid range, and data() == addressof(front()).

This implies that you can access each element sequentially via the data() pointer, and so if T is trivially copyable you can indeed use memcpy to copy sizeof(T) * size() bytes to/from an array T[size()], since this is equivalent to memcpying each element individually.

However, you cannot use reinterpret_cast, since that would violate strict aliasing, as data() is not required to actually be backed by an array - and also, even if you were to guarantee that std::array contains an array, since C++17 you cannot (even using reinterpret_cast) cast a pointer to an array to/from a pointer to its first member (you have to use std::launder).

CppCon 2015 Pruning Error Messages From Your C++ Template Code--Roland Bock

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:

Pruning Error Messages From Your C++ Template Code

by Roland Bock

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Many template libraries are regarded with ambivalent feelings by developers: On the one hand, such libraries can offer wonderful functionality. On the other hand, they are dreaded for the sheer amount of error messages spilled out by the compiler when there is even a small bug in the developer's code. This talk will demonstrate several techniques to drastically reduce the amount of compiler output in case of errors (with real-life examples, of course).

CppCon 2015 Demystifying Floating Point--John Farrier

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:

Demystifying Floating Point

by John Farrier

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Every day we develop software that relies on math while we often overlook the importance of understanding the implications of using our IEEE floats. From the often cited “floating point error” to unstable algorithms, this talk will explain the importance of floats, understanding their storage, the impact of the IEEE floats on math, and designing algorithms better. Finally, the talk will conclude with a quick case study of storing time for games and simulations.