August 2016

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.

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

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.

CppCon 2015 C++ Atomics: The Sad Story of memory_order_consume--Paul E. McKenney

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:

C++ Atomics: The Sad Story of memory_order_consume: A Happy Ending At Last?

by Paul E. McKenney

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

One of the big advantages of C++ atomics is that developers can now let the compiler know about the intent behind their multi-threaded synchronization mechanisms. At least they can tell the compiler as long as the synchronization mechanism in question is not RCU. You see, all production compilers promote RCU's memory_order_consume to memory_order_acquire. Although this promotion does ensure correctness, it also ensures the additional overhead of memory-barrier instructions on weakly ordered systems and of needlessly suppressed compiler optimizations on all systems.

All previous attempts to resolve this issue have foundered on either standard-committee reluctance to eviscerate the standard for a special case, compiler-writer reluctance to eviscerate their compilers for a special case, and kernel-developers reluctance to eviscerate their source base for late-to-the-party compiler support.

But now there is a glimmer of hope in the guise of a small set of small patches to the Linux kernel that eliminate the most challenging use cases. Will this hope be realized? Come to this talk to here the story, which by September will hopefully have a happy ending!

CppCast Episode 66: Salvus with Michael Afanasiev

Episode 66 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Michael Afanasiev to discuss his work on the Salvus library used for performing full-waveform inversions.

CppCast Episode 66: Salvus with Michael Afanasiev

by Rob Irving and Jason Turner

About the interviewee:

Michael Afanasiev is currently working on his PhD in Geophysics. He became interested in programming and high performance computing during his BSc in Computational Physics, playing around with simulations of star formation. After a brief attempt to lead a roguish and exciting lifestyle as a field Geophysicist, he was brought back to the keyboard during a MSc, where he began working on full waveform inversion (FWI). In 2013 he moved to Switzerland to continue working on FWI as a PhD student at ETH Zurich, where he’s currently wrapping things into a thesis. He spends most of his time writing scientific software, wandering through the alps, and atoning for the times he repeated the mantra “Fortran is the best language for scientific computing.”

CppCon 2015 Concurrency TS Editor's Report--Artur Laksberg

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:

Concurrency TS Editor's Report

by Artur Laksberg

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

In this presentation we will talk about the new C++ concurrency features that have been included in the Concurrency Technical Specification.

The TS should be of interest to anyone writing concurrent code in C++. The proposal includes improved futures for wait-free composition of asynchronous operations (including their relationship with C++ 'await'), new synchronization constructs as well as atomic smart pointers.

CppCon 2015 Writing Great Libraries: 89 Easy Steps--Zach Laine

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:

Writing Great Libraries: 89 Easy Steps

by Zach Laine

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Writing code that does what you want it to do, correctly and efficiently, is hard. Doing so when you don't even know yet what you want the code to do yet is quite a bit harder. Yet this is the job of a library writer -- the users of a library may have a very different use case from that of the original author.

How do library writers develop correct and efficient APIs that are also:

- easy to use correctly - hard to use incorrectly - highly reusable - gracefully interoperable with other code

This talk gives lots of practical advice and techniques for accomplishing those goals and more.