Articles & Books

Quick Q: Conditional use of std::lock_guard

Quick A: Use std::unique_lock instead.

Recently on SO:

Conditional use of std::lock_guard

How about this one?

void bar(std::mutex * optionalMutex = nullptr)
{
        auto lockScope = (optionalMutex == nullptr) ?
                           std::unique_lock<std::mutex>()
                         : std::unique_lock<std::mutex>(*optionalMutex);

}

Explanation: You're compiler had trouble with your prior statement because, you can not suddenly change the type of the ternary ? expression, i.e. the literal 0 is not a std::lock_guard and vice versa. So I changed the two branches to the same type, here std::unique_lock<std::mutex> because lock_guard isn't designed be used without a valid mutex. But still prefer std::lock_guard over std::unique_lock in the simpler cases, because it will make you code more readable.

Also your statement wasn't viable for the compiler, i.e. even syntactical correct, because the variable lockScope would only have existed in one branch.

Move safety - know what can be done in the moved-from state--Jonathan Müller

What state is an object after move?

Move safety - know what can be done in the moved-from state

by Jonathan Müller

From the article:

C++ programmers have this notion of exception safety. It is a very useful concept. With it one can easily describe the post-conditions of a function if it throws.

There is another situation where you need to easily describe some post-conditions: when talking about the state of an object after a move operation, i.e. after a move constructor or move assignment operator. I thus want to introduce vocabulary for those post-conditions of the right-hand argument similar to the exception safety of a function: The move safety, if you will.

The exception safety describes the post-conditions of a function if the function throws an exception. Similarly, the move safety describes the post-conditions of the object after a move operation. It thus gives information about what can be done safely with a moved-from object...

Quick Q: Why two null constructors for std::unique_ptr?

Quick A: The nullptr_t constructor was added later.

Recently on SO:

Why two null constructors for std::unique_ptr?

For (1), consider that it ensures that both the no-arg constructor unique_ptr() and null-pointer constructor unique_ptr(nullptr_t) have the same compile-time guarantees, i.e. both are constexpr. We can see the difference in §20.8.1.2:

constexpr unique_ptr() noexcept;
explicit unique_ptr(pointer p) noexcept;
...
constexpr unique_ptr(nullptr_t) noexcept
: unique_ptr() { }

Why the two were not combined into a single constructor with a default value is likely historical contingency.

With regards to (2), why we should care about constexpr despite having a non-trivial destructor, consider the answer given here:

constexpr constructors can be used for constant initialization, which, as a form of static initialization, is guaranteed to happen before any dynamic initialization takes place.

For example, given a global std::mutex:

std::mutex mutex;

In a conforming implementation (read: not MSVC), constructors of other objects can safely lock and unlock mutex, becuase std::mutex's constructor is constexpr.

Parameter or Argument?--Malte Langkabel

Did you know the difference?

Parameter or Argument?

by Malte Langkabel

From the article:

I often hear people getting confused when talking about parameters and arguments. That confusion grows even stronger when one of them knows the difference but the other one doesn’t. So let’s shed some light on this issue and spread the knowledge! Programming involves talking to each other but that doesn’t have to be more painful than it already is wink

Zeroing Memory is Hard (VC++ 2015 arrays)--Bruce Dawson

Here is a curious behaviour:

Zeroing Memory is Hard (VC++ 2015 arrays)

by Bruce Dawson

From the article:

Quick, what’s the difference between these two C/C++ definitions of initialized local variables?

char buffer[32] = { 0 };
char buffer[32] = {};

One difference is that the first is legal in C and C++, whereas the second is only legal in C++.

Okay, so let’s focus our attention on C++. What do these two definitions mean?

Meeting C++ 2016: closing keynote & full schedule

With the announcement of the closing keynote the full schedule for Meeting C++ 2016 stands!

Closing keynote & full schedule of Meeting C++ 2016

by Jens Weller

From the article:

Since mid of June the program of the 5th Meeting C++ conference was taking shape. With the selection of the talks it was also clear in which tracks they go, so that the schedule it self was almost ready, except a last detail: the closing keynote.

The closing keynote will be held by Louis Dionne on "C++ metaprogramming: evolution and future directions".

Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Library--JWAKELY

C++ continues to evolve:

Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Library

by JWAKELY

From the article:

The recent WG21 meeting in Oulu, Finland, was an especially busy one for the Library Working Group. Every day was spent working through the list of proposals intended for inclusion in C++17, and we also had three “evening” sessions that ran well past the evening (until nearly midnight, although the sun was still up to trick us into working late)...

 

Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Core Language--Jason Merrill

C++ continues to evolve:

Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Core Language

by Jason Merrill

From the article:

It was quite a trek to get to Oulu, Finland for the June 2016 C++ Standards Committee meeting, but we were warmly received and the meeting went well once we arrived. We had very pleasant weather most of the week, and it was fun to experience the midnight sun, even though it played havoc with my sleep schedule.