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

By Adrien Hamelin | Aug 5, 2016 02:00 PM | Tags: performance intermediate

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.

Quick Q:Why does std::set seem to force the use of a const_iterator?

By Adrien Hamelin | Aug 5, 2016 01:57 PM | Tags: basics

Quick A: A set does not allow the modification of its keys.

Recently on SO:

Why does std::set seem to force the use of a const_iterator?

A set is like a map with no values, only keys. Since those keys are used for a tree that accelerates operations on the set, they cannot change. Thus all elements must be const to keep the constraints of the underlying tree from being broken.

Memory consistency made simple(ish)--Glennan Carnie

By Adrien Hamelin | Jul 29, 2016 01:21 PM | Tags: advanced

How to synchronize between threqds or

Memory consistency made simple(ish)

by Glennan Carnie

From the article:

The C++11 memory consistency model is probably one of the most significant aspects of Modern C++; and yet probably one of the least well-understood.  I think the reason is simple:  it’s really difficult to understand what the problem actually is.

The memory consistency problem is a concurrency problem.  That is, it’s a problem that occurs when we start writing multi-threaded code.  More specifically, it’s a parallelism problem – the real subtleties occur when you have two or more processors executing code...

Const Correctness--Arne Mertz

By Adrien Hamelin | Jul 28, 2016 02:33 PM | Tags: intermediate

Do you use const well?

Const Correctness

by Arne Mertz

From the article:

Writing const correct code is about more than using const in a few places and letting the compiler figure out if it makes sense.

There are two components about using the keyword const in C++ code: A syntactic component and a semantic component...

Quick Q: Conditional use of std::lock_guard

By Adrien Hamelin | Jul 28, 2016 02:19 PM | Tags: None

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

By Adrien Hamelin | Jul 27, 2016 01:16 PM | Tags: intermediate c++11

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

Quic Q: Is the new C++ return syntax limited?

By Adrien Hamelin | Jul 25, 2016 02:07 PM | Tags: c++11 basics

Quick A: No, there is a specified syntax for it.

Recently on SO:

Is the new C++ return syntax limited?

Yeah, this is not something you'd normally guess.

virtual auto what() const noexcept -> const char * override;

This is just the order you have to use. The syntax could have been different, probably, but this is what we've got.

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

By Adrien Hamelin | Jul 25, 2016 01:59 PM | Tags: None

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

By Adrien Hamelin | Jul 21, 2016 02:04 PM | Tags: basics

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

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

By Adrien Hamelin | Jul 20, 2016 02:08 PM | Tags: performance advanced

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?