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?

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

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

Use the official range-v3 with MSVC 2017 version 15.9--CoderCasey

By Adrien Hamelin | Nov 12, 2018 01:21 PM | Tags: experimental community

Everything is in the title.

Use the official range-v3 with MSVC 2017 version 15.9

by CoderCasey

From the article:

We’re happy to announce that the ongoing conformance work in the MSVC compiler has reached a new milestone: support for Eric Niebler’s range-v3 library. It’s no longer necessary to use the range-v3-vs2015 fork that was introduced for MSVC 2015 Update 3 support; true upstream range-v3 is now usable directly with MSVC 2017.

Using STL algorithms with cppcheck--Paul Fultz II

By Adrien Hamelin | Nov 7, 2018 11:31 AM | Tags: community

Making the code more expressive.

Using STL algorithms with cppcheck

by Paul Fultz II

From the article:

From Sean Parent’s C++ Seasoning talk, he explains how raw loops suffer from several issues:

• Difficult to reason about and difficult to prove post conditions
• Error prone and likely to fail under non-obvious conditions
• Introduce non-obvious performance problems
• Complicates reasoning about the surrounding code

Instead algorithms should be preferred, either using the algorithms in the standard library or writing a new algorithm. Even more so, Sean Parent suggests that all coding guildines should be replaceed with “No raw loops” in order to improve code quality...

Exploring Clang Tooling Part 3: Rewriting Code with clang-tidy--Stephen Kelly

By Adrien Hamelin | Nov 7, 2018 11:29 AM | Tags: community

The series continue.

Exploring Clang Tooling Part 3: Rewriting Code with clang-tidy

by Stephen Kelly

From the article:

In the previous post in this series, we used clang-query to examine the Abstract Syntax Tree of a simple source code file. Using clang-query, we can prototype an AST Matcher which we can use in a clang-tidy check to refactor code in bulk.

This time, we will complete the rewriting of the source code...

Introducing Conduit for C++: Lazy Sequences Using the Coroutine TS--Buckaroo

By Adrien Hamelin | Nov 6, 2018 01:12 PM | Tags: community

It is worth looking at it.

Introducing Conduit for C++: Lazy Sequences Using the Coroutine TS

by Buckaroo

From the article:

Conduit is a new library that leverages the Coroutine TS to introduce lazy sequences to C++.

Lazy sequences are an idea that’s very popular in the functional-programming community, but less common in the C++ world.

Simply put, a lazy sequence is one where the elements are computed as they are requested, rather than in advance.
This can lead to big efficiency gains since you only perform the computation required. It also allows you to represent infinite sequences, which of course could never fit into a vector!

Let’s see how Conduit works with some simple examples…

Pacific++ 2018: C++ Past vs. Future--Titus Winters

By Adrien Hamelin | Nov 6, 2018 01:10 PM | Tags: community

Did you see it?

Pacific++ 2018: C++ Past vs. Future

by Titus Winters

From the video:

Over the last 35 years, C++ has remained a constant fixture in the programming landscape. With advancements in the language through C++11, 14, and 17, we've created new dialects that have breathed new life into C++. With C++ Core Guidelines and a rich community of authors and speakers providing guidance on C++, it is easier now to steer clear of problem areas and hopefully stay in the "good parts" of the language.
Or at least, that's what we'd like. In practice, many habits of C++ programmers are unsafe and will be hard to keep working. The triple perils of ADL, ODR, and ABI leave a wide assortment of pitfalls for code maintenance. Many systems happen to work, but perhaps more out of luck than actual correctness.
How do we explain this dichotomy? How is the language better than it ever has been, and at the same time so dangerous and burdened with silent pitfalls and legacy? Can the standard evolve over time to reduce these perils? More importantly: should it?
In this talk I'll remind people of how precarious most C++ code is in the face of change (like advancing to a new language version), and discuss the most fundamental issue facing the committee these days: how to balance between the legacy code of the past and the yet-to-be-written code of the future.