Inline Namespaces 101--Jonathan Müller

By Adrien Hamelin | Nov 27, 2018 01:58 PM | Tags: c++11 advanced

Obscure feature? Not for long.

Inline Namespaces 101

by Jonathan Müller

From the article:

Almost three years ago — wow, how time flies — I blogged about namespace aliases and called them one of C++ most underrated features (which probably was a bit of a click bait).

Let’s talk about some other namespace feature, that is, well, not quite underrated, but relatively obscure: inline namespace. They are namespaces that don’t really introduce a scope, except when they do.

So what can you do with them?

How to teach C++--Marius Elvert

By Adrien Hamelin | Nov 27, 2018 01:53 PM | Tags: community

Do you have a way?

How to teach C++

by Marius Elvert

From the article:

In the closing Keynote of this year’s Meeting C++, Nicolai Josuttis remarked how hard it can be to teach C++ with its ever expanding complexity. His example was teaching rookies about initialization in C++, i.e. whether to use assignment =, parens () or curly braces {}. He also asked for more application-level programmers to participate.

Well, I am an application programmer, and I also have experience with teaching C++. Last year I held a C++ introductory course for experienced C programmers who mostly had never used C++ before. From my experience, I can completely agree with what Nico had to say about teaching C++. The language and its subtlety can be truly overwhelming.

Most of the complexity in C++ boils down to tuning your code for optimal performance. We cannot just leave that out, can we? After all, the sole reason to use C++ is performance, right?

CLion 2018.3 released with remote dev support -- Anastasia Kazakova

By Anastasia Kazakova | Nov 27, 2018 12:20 PM | Tags: None

CLion has just got a huge update!!

How to Design Function Parameters That Make Interfaces Easier to Use (1/3)--Jonathan Boccara

By Adrien Hamelin | Nov 26, 2018 02:30 PM | Tags: intermediate community

Readability is important.

How to Design Function Parameters That Make Interfaces Easier to Use (1/3)

by Jonathan Boccara

From the article:

When you look at an function in an interface, 3 prominent things give you indications about how to use it: its name, its parameters and its return type. And when you look at a piece of code calling that function, it’s just its name and its function parameters.

We’ve already covered in details how to give good names to the components of your code. Now we’re going to examine how to design function parameters in a way that both your interfaces and the code that calls them are as expressive as can be.

Summed up in one sentence, you want to make the decision of what arguments to pass to your functions a no-brainer.

There are a lot of things to say about how to achieve this. So much so that you will find the contents broken down into 3 articles in order to make it easier to digest:

• Part 1: interface-level parameters, one-parameter functions, const parameters,
• Part 2: calling contexts, strong types, parameters order,
• Part 3: packing parameters, processes, levels of abstraction.

To support this series I’ve taken many examples from interfaces I’ve worked on, except that I’ve stripped out all domain aspects to make them both simpler and disclosable...

Treating symptoms instead of the cause--Andrzej Krzemieński

By Adrien Hamelin | Nov 26, 2018 02:16 PM | Tags: community

An interesting point of view.

Treating symptoms instead of the cause

by Andrzej Krzemieński

From the article:

Compiler warnings can sometimes help us find bugs before we even build our program, but it only works provided that we can make use of the warnings. Especially, when we are aware that warnings detect only symptoms of the bugs rather than bugs themselves...

A zero cost abstraction?--Josh Peterson

By Adrien Hamelin | Nov 26, 2018 02:12 PM | Tags: performance

Safe and performant?

A zero cost abstraction?

by Josh Peterson

From the article:

Recently Joachim (CTO at Unity) has been talking about “performance by default”, the mantra that software should be as fast as possible from the outset. This is driving the pretty cool stuff many at Unity are doing around things like ECS, the C# job system, and Burst (find lots more about that here).

One question Joachim has asked internally of Unity developers is (I’m paraphrasing here): “What is the absolute lower bound of time this code could use?” This strikes me as a really useful way to think about performance. The question changes from “How fast is this?” to “How fast could this be?”. If the answers to those two questions are not the same, the next question is “Do we really need the additional overhead?”

Another way to think about this is to consider the zero-cost abstraction, a concept much discussed in the C++ and Rust communities. Programmers are always building abstractions, and those abstractions often lead to the difference between “how fast it is” and “how fast it could be”. We want to provide useful abstractions that don’t hurt performance...

Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

By Andrey Karpov | Nov 21, 2018 02:00 AM | Tags: static code analysis pvs-studio c++ bugs

The PVS-Studio analyzer is gradually becoming more complicated but these changes can be hardly described in a Release-history. For example, this year we have consistently implemented symbolic computations in the analyzer. This is why it was agreed to write a note on algorithms and technologies, which PVS-Studio now uses to search for errors and potential vulnerabilities.

Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

by Andrey Karpov

From the article:

Here a mixture of technologies is working: data flow analysis, symbolic execution, and automatic method annotation (we will cover this technology in the next section). The analyzer sees that X variable is used in the Div function as a divisor. On this basis, a special annotation is built for the Div function. Further it is taken into account that in the function a range of values [0..4] is passed as the X argument. The analyzer comes to a conclusion that a division by 0 has to occur.

San Diego Committee Meeting: A Trip Report--Corentin Jabot

By Adrien Hamelin | Nov 19, 2018 01:08 PM | Tags: experimental community

Trip report.

San Diego Committee Meeting: A Trip Report

by Corentin Jabot

From the article:

As I left Rapperswil earlier this year, I said very firmly that I would not go to the San Diego Meeting.

Crossing an ocean to work on C++ 12 hours a day for a week is indeed madness.

And so naturally, I found myself in a San Diego hotel straight from the 60s, to do some C++ for a week. With the exception of the author of this blog, all people there are incredibly smart and energetic, and so a lot of great work was done...

Trip Report: Freestanding in San Diego--Ben Craig

By Adrien Hamelin | Nov 19, 2018 01:05 PM | Tags: experimental community

One more report.

Trip Report: Freestanding in San Diego

by Ben Craig

From the article:

All three are dealing with "freestanding". I've been working for the last year or so trying to redefine freestanding in a way that would be useful to more people. I have personal experience using C++ in various operating system kernels / drivers, and a bit of experience working on micro controllers and digital signal processors, so that's where my papers focused. At the CppCon 2018 SG14 meeting, some GPU companies have said that my definitions are useful for their architectures (with some tweaks), and I've heard from several other people that my definitions are even useful in some environments where performance and determinism are key, even when there is an OS. I'm still trying to figure out if and how to incorporate all these groups into one thing that could get standardized.

I pitched "Freestanding Proposal" at my first WG21 meeting was November of 2017 in Albuquerque. I was an unknown then. San Diego was my third WG21 meeting. All the papers and interviews and trip reports have now made it where people were asking me about freestanding quite frequently. There were a few times I got stopped while walking around by someone I had never talked to before, and they knew who I was, and asked about freestanding. I found this very flattering. I'm thrilled (and terrified) that my work is getting such visibility...

CppCast Episode 175: San Diego LEWG Trip Report with Ashley Hedberg

By robwirving | Nov 16, 2018 08:09 AM | Tags: None

Episode 175 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Ashley Hedberg to discuss the San Diego C++ Committee meeting from her perspective on the Library Evolution Working Group.

CppCast Episode 175: San Diego LEWG Trip Report with Ashley Hedberg

by Rob Irving and Jason Turner

About the interviewee:

Ashley Hedberg has been working at Google for the last three years. She currently works on Abseil, an open-source collection of C++ library code designed to augment the C++ standard library. San Diego was her second WG21 meeting.