News : Standard C++

Home » Blog » Categories » News

« Prev Next »

News

CppCon 2023 std::linalg: Linear Algebra Coming to Standard C++ -- Mark Hoemmen

By Blog Staff | Jul 14, 2024 09:57 AM | Tags: None

Registration is now open for CppCon 2024! The conference starts on September 15 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting videos of some of the top-rated talks from last year's conference. Here’s another CppCon talk video we hope you will enjoy – and why not register today for CppCon 2024!

CppCon 2023 std::linalg: Linear Algebra Coming to Standard C++

by Mark Hoemmen

Summary of the talk:

Many fields depend on linear algebra computations, which include matrix-matrix and matrix-vector multiplies, triangular solves, dot products, and norms. It's hard to implement these fast and accurately for all kinds of number types and data layouts. Wouldn't it be nice if C++ had a built-in library for doing that? Wouldn't it be even nicer if this library used C++ idioms instead of what developers have to do now, which is write nonportable, unsafe, verbose code for calling into an optimized Fortran or C library?

The std::linalg library does just that. It uses the new C++23 feature mdspan to represent matrices and vectors. The library builds on the long history and solid theoretical foundation of the BLAS (Basic Linear Algebra Subroutines), a standard C and Fortran interface with many optimized implementations. The C++ Standard Committee is currently reviewing std::linalg for C++26. The library already has two implementations that work with C++17 or newer compilers, and can take advantage of vendor-specific optimizations. Developers will see how std::linalg can make their C++ safer and more concise without sacrificing performance for use cases that existing BLAS libraries already optimize, while opening up new use cases and potential optimizations.

CppCon 2023 Spanny: Abusing C++ mdspan Is Within Arm’s Reach -- Griswald Brooks

By Blog Staff | Jul 12, 2024 01:52 PM | Tags: None

Lightning Talk: Spanny: Abusing C++ mdspan Is Within Arm’s Reach

by Griswald Brooks

Summary of the talk:

mdspan introduced in C++23 gave us a standard multidimensional way to view into a container of data. While the canonical use case is to refer to a stack or heap allocated data, the accessor policy allows you to inject any side effect allowing the data to come from anywhere... like a robot arm inspecting bins.

User-Defined Formatting in std::format – Part 2 -- Spencer Collyer

By Blog Staff | Jul 11, 2024 01:10 PM | Tags: None

Last time, we saw how to provide formatting for a simple user-defined class. Spencer Collyer builds on this, showing how to write a formatter for more complicated types.

User-Defined Formatting in std::format – Part 2

by Spencer Collyer

From the article:

In the previous article in this series [Collyer24], I showed how to write a class to format user-defined classes using the std::format library. In this article I will describe how this can be extended to container classes or any other class that holds objects whose type is specified by the user of your class.

A note on the code listings: The code listings in this article have lines labelled with comments like // 1. Where these lines are referred to in the text of this article, it will be as ‘line 1’ for instance, rather than ‘the line labelled // 1’.

Nested formatter objects

The objects created from the formatter template structs are just ordinary C++ objects – there is nothing special about them 1. In particular, there is nothing to stop you including an object of a formatter template type inside one of your user-defined formatter structs.

You might wonder why you would want to do that. One simple case is if you have a templated container class, and want to create a formatter that can output the container in one go, rather than having to write code to iterate over the container and output each value in turn. Having a nested formatter for the contained value type allows you to do this and allow the values to be formatted differently to the default, as the following examples will show. Other uses will no doubt come to mind for your own classes.

Qt and Trivial Relocation (Part 4) -- Giuseppe D'Angelo

By Blog Staff | Jul 9, 2024 03:08 PM | Tags: None

The conclusion of the last post was that we need to change something in our models: maybe std::vector should use a different strategy when erasing elements; maybe types like std::tuple<int &> should not be allowed to be stored in a vector; maybe Qt should not be using memmove when erasing objects of trivially relocatable type (but it can still optimize the reallocation of a vector); maybe Qt’s definition of trivial relocability does not match ours, and we need to fix our definitions. In this post we will explore these possibilities and reach some conclusions.

Qt and Trivial Relocation (Part 4)

by Giuseppe D'Angelo

From the article:

As we have already discussed in the previous blog posts, it is possible to implement erasure in a number of ways, which are not equivalent. The Standard Library chose a specific implementation strategy (move-assign the elements after the ones to be destroyed to the left; destroy the moved-from last elements). Changing it now, over 26 years after the fact, sounds extremely scary; std::vector is such a central class that surely such a change would break somebody’s code.

That doesn’t mean that we can’t at least reason about a possible change there!

Also, there is another library that we keep talking about in these blog posts. This other library has a much smaller userbase than the Standard Library, and that has fewer regards with breaking backwards compatibility. We should certainly reason about that library as well. I’m talking about Qt, of course ��

Final report from using std::cpp 2024

By jdgarcia | Jul 8, 2024 01:29 PM | Tags: None

From April 24th to 26th we had our annual edition of the C++ conference using std::cpp 2024. This is the major conference held in Spain since 2013.

Our final report has now been published:

Report from using std::cpp 2024

It includes answers to many interesting questions from the audience, not only about the conference, but also about the state of the C++ programming language ecosystem.

Do you want to know which is the most widely used version of the C++ language amont our attendees? What are the most popular platforms and compilers? Which tools are used?

And above all, do you really want to know which one was considered the best talk in the conference?

CppCon 2023 Robots Are After Your Job: Exploring Generative AI for C++ -- Andrei Alexandrescu

By Blog Staff | Jul 8, 2024 11:27 AM | Tags: None

Robots Are After Your Job: Exploring Generative AI for C++

by Andrei Alexandrescu

Summary of the talk:

Almost a year since the launch of ChatGPT – considered by many as the first truly compelling code generator that translates free-form human language into code – the C++ community continues to grapple with the implications. Reactions range from indifference or skepticism to genuine concern about the future of human programmers.

Although some advanced C++ techniques are already accessible to tools like ChatGPT, certain fundamental aspects remain outside the reach of current and possibly next-generation generative AI tools. This disparity raises pivotal questions: Which parts of the intricate C++ ecosystem can we confidently delegate to generative AI? What uniquely human skills must we retain and refine?

We'll probe the potential and limits of contemporary AI, taking a novel look at the age-old binary search algorithm. Although this algorithm has long been held up as a paragon of efficiency, we challenge that notion. What would ChatGPT have to say about it, and how might it partner with us to refine this cornerstone of algorithmic logic? The conversation opens a window into a future where developers become the "one percenters" of programming—focusing solely on the most cerebral and high-level challenges, while AI takes care of the everyday tasks. Join us to explore this fascinating paradigm shift and reflect on what it means for your own work in and with C++.

CppCon 2023 Coping With Other People's C++ Code -- Laura Savino

By Blog Staff | Jul 6, 2024 11:25 AM | Tags: None

Plenary: Coping With Other People's C++ Code

by Laura Savino

Summary of the talk:

Sometimes we're fortunate enough to work with a small group of devs who share our coding values, and when we see their PRs come in, we nod along and say, "Yup, that's what I would have done. Oh, nice, that one's even better than my usual approach, I'd better tuck that idea away for next time."

This perfect alignment is precious... and particularly elusive in C++. Most of us are living in codebases that are profitable, complex, and updated in ways with which we have legitimate beef. How can we keep a sense of curiosity, progress, and satisfaction amidst patterns we would never have chosen?

This presentation explores the often-overlooked social aspects of C++ development, offering both practical tools and light-hearted commiseration. We'll draw from the field of behavior science to build strategies that address conflicting design patterns and the strong opinions that come with them.

Qt and Trivial Relocation (Part 3) -- Giuseppe D'Angelo

By Blog Staff | Jul 2, 2024 03:06 PM | Tags: None

In the last post of this series we started exploring how to erase an element from the middle of a vector.

Qt and Trivial Relocation (Part 3)

by Giuseppe D'Angelo

From the article:

The reference semantics backstab

Let’s start by analyzing erase()‘s behavior once more.

Do you remember our claim that the specific strategy used does not really matter; that is, that they are all equivalent? Well, not so fast! It is actually quite imprecise to say that they are all equivalent.

They may be, as long as we deal with types which have value semantics. If we instead use a type that has reference semantics, the choices are absolutely not equivalent, and will yield different outcomes. This is because the semantics of assignment for (certain) reference types are write-through: they assign through the reference (instead of rebinding the reference).

Since we are implementing erasure in terms of assignments (or swaps, which boil down to assignments), this means that the precise sequence of operations done by erase will be visible due to its side-effects; and it also means that changing the strategy will produce different outcomes!

CppCon 2023 Writing a Better std::move -- Jonathan Müller

By Blog Staff | Jul 1, 2024 11:22 AM | Tags: None

Lightning Talk: Writing a Better std::move

by Jonathan Müller

Summary of the talk:

std::move allows the creation of const rvalue references, which is almost always wrong. It also allows moving out of lvalue references, which can be dangerous since you don't have real ownership over them and a caller might not expect the object to disappear. Let's fix those problems using macros, reflection, and more macros.

More on Harmful Overuse of std::move -- Raymond Chen

By Blog Staff | Jun 29, 2024 02:45 PM | Tags: None

In recent discussions around the use of std::move in C++, questions have arisen regarding its potential overuse and the compiler's treatment of its return values. Addressing concerns raised by developers like Jonathan Duncan, this article delves into the nuances of std::move, examining whether its current implementation aligns with compiler optimizations and proposing potential enhancements for more efficient code generation.

More on harmful overuse of std::move

by Raymond Chen

From the article:

Some time ago, I wrote about harmful overuse of std::move. Jonathan Duncan asked,

Is there some side-effect or other reason I can’t see return std::move(name); case isn’t possible to elide? Or is this just a case of the standards missing an opportunity and compilers being bound to obey the standards?

In the statement return std::move(name);, what the compiler sees is return f(...); where f(...) is some mysterious function call that returns an rvalue. For all it knows, you could have written return object.optional_name().value();, which is also a mysterious function call that returns an rvalue. There is nothing in the expression std::move(name) that says, “Trust me, this rvalue that I return is an rvalue of a local variable from this very function!”

Now, you might say, “Sure, the compiler doesn’t know that, but what if we made it know that?” Make the function std::move a magic function, one of the special cases where the core language is in cahoots with the standard library.

This sort of in-cahoots-ness is not unheard of. For example, the compiler has special understanding of std::launder, so that it won’t value-propagate memory values across it, and the compiler has special understanding of memory barriers, so that it won’t optimize loads and stores across them.