Why you shouldn't have virtual member functions with default parameters -- Andreas Fertig

By Blog Staff | Apr 26, 2024 12:32 PM | Tags: None

In this episode, you learn how default parameters work and why you shouldn't put them on virtual member functions.

C++ Insights Episode 49: Why you shouldn't have virtual member functions with default parameters

by Andreas Fertig

SObjectizer Tales – Epilogue--Marco Arena

By Marco Arena | Apr 24, 2024 11:00 PM | Tags: sobjectizer intermediate c++20

The last episode of the series about SObjectizer and message passing:

SObjectizer Tales – Epilogue

by Marco Arena

From the article:

In this last episode, we conclude the series and offer suggestions for delving into more topics regarding SObjectizer.

When and How Variables are Initialized? - Part 2 -- Sandor Dargo

By Blog Staff | Apr 22, 2024 12:39 PM | Tags: None

During the last two weeks, we saw a bug related to uninitialized values and undefined behaviour, we listed the different kinds of initializations in C++ and we started to more detailed discovery with copy-initialization. This week, we continue this discovery with direct-, list- and aggregate-initialization.

When and How Variables are Initialized? - Part 2

by Sandor Dargo

From the article:

Direct-initialization initializes an object from an explicit set of constructor arguments. Different syntaxes invoke direct initialization such as T object(<at least one arg>);, T(<at least one arg>); or new T(<at least one arg>); but it might also happen when you use curly braces (T object{oneArg};). Additional use cases are static casts, constructor initializer lists and values taken by value in lambda captures.

While at first glance this might obvious there are some catches.

Take this expression: T object{ arg };. In this case, object is directly initialized only if it’s a non-class type, otherwise, we talk about list-initialization. But if you use the parentheses syntax (T object(arg) then there is no such distinction between class and non-class types, in both cases, direct-initialization is performed. Also, T object{ arg1, arg2 }; would never be direct-initialized, that’s always an aggregate-initialization.

In the expression [arg]() {}, the generated lambda members will not be copy-initialized, but they will be directly initialized.

Overload 180: C++ Safety, In Context -- Herb Sutter

By Blog Staff | Apr 18, 2024 09:21 AM | Tags: None

The safety of C++ has become a hot topic recently. Herb Sutter discusses the language’s current problems and potential solutions.

Overload 180: C++ Safety, In Context

by Herb Sutter

From the article:

We must make our software infrastructure more secure against the rise in cyberattacks (such as on power grids, hospitals, and banks), and safer against accidental failures with the increased use of software in life-critical systems (such as autonomous vehicles and autonomous weapons).

The past two years in particular have seen extra attention on programming language safety as a way to help build more-secure and -safe software; on the real benefits of memory-safe languages (MSLs); and that C and C++ language safety needs to improve – I agree.

But there have been misconceptions, too, including focusing too narrowly on programming language safety as our industry’s primary security and safety problem – it isn’t. Many of the most damaging recent security breaches happened to code written in MSLs (e.g., Log4j [CISA-1]) or had nothing to do with programming languages (e.g., Kubernetes Secrets stored on public GitHub repos [Kadkoda23]).

In that context, I’ll focus on C++ and try to:

• highlight what needs attention (what C++’s problem is), and how we can get there by building on solutions already underway;
• address some common misconceptions (what C++’s problem isn’t), including practical considerations of MSLs; and
• leave a call to action for programmers using all languages.

tl;dr: I don’t want C++ to limit what I can express efficiently. I just want C++ to let me enforce our already-well-known safety rules and best practices by default, and make me opt out explicitly if that’s what I want. Then I can still use fully modern C++… just nicer.

Let’s dig in.

SObjectizer Tales – 28. If I had a magic wand....--Marco Arena

By Marco Arena | Apr 17, 2024 11:00 PM | Tags: sobjectizer intermediate c++20

A new episode of the series about SObjectizer and message passing:

SObjectizer Tales – 28. If I had a magic wand...

by Marco Arena

From the article:

In this episode I delve into what I dislike the most about the library and explore what I would change if I had a magic wand.

2024-04 Mailing Available

By Administrator | Apr 16, 2024 11:16 AM | Tags: None

The 2024-04 mailing of new standards papers is now available.

Results summary: 2024 Annual C++ Developer Survey "Lite"

By Blog Staff | Apr 11, 2024 08:44 PM | Tags: None

Over the past week, we ran our 2024 annual global C++ developer survey. Thank you to everyone who responded. As promised, here is a summary of the results:

CppDevSurvey-2024-summary.pdf

The results have now been forwarded to the C++ standards committee to help inform C++ evolution. Your feedback will be very helpful, and thank you again for your participation! Stay safe, everyone.

Update to add note: We discovered after the survey went live that SurveyMonkey has started rejecting responses from some countries. They did not notify us this was going to happen, and it means we don't have responses this year from countries that were included in all previous years. We'll look into fixing that for next year because we do want to hear from all C++ programmers worldwide.

SObjectizer Tales – 27. Design ideas--Marco Arena

By Marco Arena | Apr 10, 2024 11:47 PM | Tags: sobjectizer intermediate c++20

A new episode of the series about SObjectizer and message passing:

SObjectizer Tales – 27. Design ideas

by Marco Arena

From the article:

In this episode we aim to inspire new ideas and approaches to design applications using SObjectizer and its paradigm.

Trip Report: Spring ISO C++ Meeting in Tokyo, Japan -- Jonathan Müller

By Blog Staff | Apr 8, 2024 03:51 PM | Tags: None

Last week, I attended the spring 2024 meeting of the ISO C++ standardization committee in Tokyo, Japan. This was the third meeting for the upcoming C++26 standard and my first meeting as assistant chair of SG 9, the study group for ranges.

Trip Report: Spring ISO C++ Meeting in Tokyo, Japan

by Jonathan Müller

From the article:

I started the week on Monday in LEWG, the working group for the C++ standard library design. After the usual papers adding/extending std::format (Victor Zverovich keeps us busy), we approved a proposal that adds thread attributes, and reviewed the library parts of P2900 contracts. LEWG being LEWG, we mostly complained about the names (std::contracts::contract_violation has too many contracts in it), but overall liked it. However, contracts are a language feature, and the real controversy was over at EWG, the language design group. In particular, what happens if you have undefined behavior in a precondition? Consider the following example:

std::string_view slice(std::string_view str, int pos, int length)
pre (0 <= pos && pos <= std::ssize(str) && 0 <= length && pos + length <= std::ssize(str))
{
return std::string_view(str.data() + pos, str.data() + pos + length);
}

A slicing function for std::string_view using signed integers for demonstration purposes.

An integer overflow of pos + length in the precondition is undefined behavior. Some argue that this should instead be well-defined and lead to a precondition violation. While this would be nice and can lead to a general "safe mode" of C++ which could (and should!) be usable outside of contracts as well, I don't see how it can be worked out before C++26. I'd much rather have contracts with undefined behavior in C++26 then delaying it even further. The nice thing about undefined behavior is that it can be always well-specified later.

How not to check array size in C++

By Andrey Karpov | Apr 8, 2024 06:29 AM | Tags: std::size sizeof size countof

How often do you see the sizeof(array)/sizeof(array[0]) statement used to get the size of an array? I really hope it's not too often, because it's 2024 already. In this note, we'll talk about the statement flaws, where it comes from in modern code, and how to finally get rid of it.

How not to check array size in C++

by Mikhail Gelvikh

From the article:

Since we're coding in C++ here, let's harness the power of templates! This brings us to the legendary ArraySizeHelper (aka "the safe sizeof" in some articles), which developers write sooner or later in almost every project. In the old days — before C++11 — you could encounter such monstrosities.