What's so hard about constexpr allocation? -- Barry Revzin

By Blog Staff | Aug 21, 2024 05:21 PM | Tags: None

Before C++20, constant evaluation couldn't handle allocations, causing any such attempts to fail. This changed with C++20, which introduced the ability to allocate memory during constant evaluation, although with strict limitations requiring deallocation during the same evaluation period. Despite these advancements, certain operations, such as declaring a constexpr std::vector, remain impossible, with the goal of this blog post being to explore why these limitations persist.

What's so hard about constexpr allocation?

by Barry Revzin

From the article:

Before C++20, we couldn’t have any allocation during constant evaluation at all. Any attempt to do so would fail the evaluation — it would no longer be constant.

In C++20, as a result of P0784R7, that changed. Finally we could do allocation during constant evaluation. However, this evaluation was extremely limited. Specifically, any allocation that happens must be deallocated during that constant evaluation.

This opened the door to a wide range of operations that weren’t possible before. We can now have local std::strings and std::vector<T>s! Those just work!

But we still cannot just declare a constexpr std::vector:

#include <vector> 
constexpr std::vector<int> v = {1, 2, 3}; // error 

And we cannot even declare a local constexpr std::vector in a consteval function:

#include <vector> 
consteval auto f() -> int { constexpr std::vector<int> v = {4, 5, 6}; // still error 
return v.size(); 
} 

This limitation still remains in C++23 and could very well still remain in C++26. The goal of this blog post is to explain why we haven’t just solved this problem already.

CppCon 2024 Leveraging C++20/23 Features for Low Level Ineractions -- Jeffrey Erickson

By Blog Staff | Aug 21, 2024 12:41 PM | 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 some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2024!

Leveraging C++20/23 Features for Low Level Ineractions

Tuesday, September 17 14:00 - 15:00 MDT

by Jeffrey Erickson

Summary of the talk:

Low level interactions are a core part of embedded implementations. All too often, C++ developers rely on C constructs and interactions due to prior biases around language support.  Herein we present effective leveraging of C++20 and C++23 constructs in an embedded driver code base. From using an existing C driver more effectively with modern C++ smart pointers to leveraging constexprs for bit and byte manipulation in the standard library, we will go over how you can stay on the cutting edge of the C++ language evolution in the embedded space.

Jeffrey E Erickson works in HW/SW Codesign Architecture at Altera, an Intel company. He holds a BS in Electrical and Computer Engineering from the University of Virginia and a doctorate from Rutgers University and UMDNJ. For 15 years he has worked in embedded systems development including FPGA-processor integration, secure firmware development, and systems modeling. He holds 3 patents in image processing and signal integrity.

CppCon 2024 Peering Forward - C++'s Next Decade -- Herb Sutter

By Blog Staff | Aug 20, 2024 09:25 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 some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2024!

Peering Forward - C++'s Next Decade

Monday, September 16 08:45 - 10:30 MDT

by Herb Sutter

Summary of the talk:

This is an exciting year for ISO C++: In just the past few months, it has started to become clear that C++ is approaching three major positive turning points that are starting to materialize together in a blossoming of usability we haven’t seen since C++11.

First, compile-time reflection, including source generation, will dominate the next decade of C++ as arguably the most powerful feature that we’ve ever standardized, and (fingers crossed!) it’s on track for being included in C++26 in the coming months. I expect reflection’s impact on library building to be comparable to that of all the other library-building improvements combined that we’ve added since C++98.

• Related: The CppCon 2024 Friday keynote will be all about reflection… more about that will be announced soon!

Second, memory safety is being taken seriously in WG21. After a decade or two of gradual smaller improvements, the committee is actively working toward taking the major step of enabling well-known proven-effective safety checks at compile time by default, without compromising performance.

• Related: The CppCon 2024 Monday evening panel and Wednesday keynote will be all about safety… more about those will be announced soon!

Third, simplifying C++ is being taken seriously. I’m not the only person actively proposing simplifications to C++, and I expect the rate of simplification proposal papers to increase again in the coming year as the fruits of in-the-field experiments turn into evidence that the experimental improvements are working and are ready to be considered for ISO C++ itself to benefit all programmers.

Most of all, the above overlap and reinforce each other. For example, reflection will enable writing more new facilities as compile-time libraries instead of as language features that have to be baked into a compiler, which helps simplify future language evolution. Reflection will also enable compile-time libraries that let developers express their intent directly and leave it to the library code to accurately generate correct implementations, which helps reduce errors and makes our code both simpler and safer.

ISO C++ has long been solidly in the top 5 programming languages and is going strong. This talk presents reasons to expect that C++’s future is bright, and that perhaps its most important decade is just ahead.

Herb is an author, designer of several Standard C++ features, and chair of the ISO C++ committee and the Standard C++ Foundation. His current interest is simplifying C++.

PVS-Studio 7.32: enhanced analysis, new plugins and more

By Andrey Karpov | Aug 18, 2024 11:27 AM | Tags: scons qt creator qt pvs-studio bazel

PVS-Studio 7.32 has been released. Discover enhanced C++ analysis optimization, new plugins and features, and a host of other updates.

PVS-Studio 7.32: enhanced analysis, new plugins and more

by Gleb Aslamov

From the article:

The PVS-Studio analyzer now supports integration with Bazel and Scons build systems for C++ projects. The PVS-Studio plugin is now available for Qt Creator 14.x. The plugin for Qt Creator 8.x is no longer supported. We aim to ensure backward compatibility between the latest plugin versions and all Qt Creator versions released in the past two years.

CppCon 2024 Perspectives on Contracts -- Lisa Lippincott

By Blog Staff | Aug 16, 2024 04:45 PM | 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 some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2024!

Perspectives on Contracts

Thursday, September 19 14:00 - 15:00 MDT

by Lisa Lippincott

Summary of the talk:

For many years, members of the C++ working group, WG21, have tried to add support for contract assertions — preconditions, postconditions, and assertion statements within a function body — to the C++ language. It’s been a long and difficult road, but we now have a proposal (P2900, “Contracts for C++”) to add significant contract support in, we hope, C++26, with more complete support to follow in C++29.

Looking back, the contracts feature has been unusually difficult and contentious. I contend that the difficulty is inherent in the feature: a contracts facility, by its nature,  cannot be understood from any single point of view.

In this lecture, I will explain why understanding contracts requires seeing the feature from a panoply of perspectives, and show how shifting between these perspectives allows one to make effective use of the facility.

This lecture is derived from presentations made to the Language Evolution subgroup of WG21 at the St. Louis meeting in June 2024.

Lisa Lippincott designed the software architectures of Tanium and BigFix, two systems for managing large fleets of computers. She's also a language nerd, and has contributed to arcane parts of the C++ standard. In her spare time, she studies mathematical logic, and wants to make computer-checked proofs of correctness a routine part of programming.

CppCon 2024 Compile-time Validation -- Alon Wolf

By Blog Staff | Aug 15, 2024 04:42 PM | 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 some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2024!

Compile-time Validation

Tuesday, September 17 15:15 - 16:15 MDT

by Alon Wolf

Summary of the talk:

C++ is often criticized for its lack of inherent memory safety, but the spectrum of potential program validations extends far beyond just memory concerns. This talk delves into the necessity of early validation, emphasizing the benefits of compile-time checks in C++. By leveraging compile-time validation, developers can catch errors and enforce constraints before the code is even executed, enhancing both safety and correctness.

A functional programming approach to compile-time validation will be discussed, highlighting its benefits and demonstrating its application in ensuring code correctness.

Moreover, the talk will delve into the realm of compile-time unit tests, showcasing how they enable developers to validate code behavior at compile time, paving the way for more efficient debugging and maintenance.

Exploring advanced features, we'll discuss existing compile-time techniques to implement lifetimes, borrow checker, and other validation rules by leveraging template metaprogramming for memory safety and how they can be improved with the upcoming C++26 reflection proposal.

Additionally, we will review language extensions and compiler-specific features that augment compile-time validation capabilities. Finally, the talk will cover the role of static analysis tools in detecting potential issues early in the development process, thus complementing compile-time techniques. Attendees will gain a comprehensive understanding of the various strategies available for enhancing program reliability through compile-time validation in C++.

Alon is a Senior Software Engineer at Medtronic specializing in 3D and computer graphics with a passion for high performance. He has developed many custom simulation and rendering engines for different platforms using modern C++. He also writes a C++ technical blog and participates in game jams.

2024-08 Mailing Available

By Administrator | Aug 15, 2024 03:07 PM | Tags: None

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

A first look at the voting results for Meeting C++ 2024

By Meeting C++ | Aug 15, 2024 02:32 AM | Tags: None

On Sunday the voting for Meeting C++ 2024 ended, now the program is taking shape. The schedule should be available by end of August.

A first look at the voting results for Meeting C++ 2024

by Jens Weller

From the article:

And through this voting, these talks made it into the top 11 - forming the main track:

    Andreas Weis - C++ Modules - Getting Started Today
    Roth Michaels - Templates made easy with C++20: how constexpr/constexpr, fold expressions, and concepts change how we write code
    Bryce Adelstein Lelbach - The C++ Execution Model
    Klaus Iglberger - There is no Silver Bullet
    Boguslaw Cyganek - Pipeline architectures in C++: overloaded pipe operator |, std::expected and its monadic operations
    Nico Josuttis - C++ Concepts: What you should know and how to use them right
    Peter Muldoon - Dependency Injection in C++ : A Practical Guide
    Jonathan Müller - An (In-)Complete Guide to C++ Object Lifetimes
    Sandor Dargo - Clean code! Horrible performance?
    Andreas Fertig - Fast and small C++ - When efficiency matters
    Timur Doumler - Contracts for C++

CppCon 2024 Using Modern C++ to Avoid Vulnerabilities by Design -- Max Hoffmann

By Blog Staff | Aug 14, 2024 04:37 PM | 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 some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2024!

Security Beyond Memory Safety - Using Modern C++ to Avoid Vulnerabilities by Design

Monday, September 16 11:00 - 12:00 MDT

by Max Hoffmann

Summary of the talk:

Nowadays, there is one topic that comes up in virtually all discussions on system programming languages: memory safety.
However, even though memory safety rules out many of the most common sources of vulnerabilities, there are still plenty of ways how a vulnerability may find its way into the codebase.

In this talk, we look beyond memory safety and explore how we can prevent vulnerabilities through simple yet effective C++ constructions and custom static analysis scripts. We analyze multiple examples, from basics like input validation to complex time-of-check vs time-of-use issues when accessing shared resources, all of which are inspired by real-world products, use cases, or vulnerabilities. For each example, we discuss attacker models, threats, and implementation pitfalls, before looking at potential solutions that are not just secure by themselves but also protect developers from accidentally introducing vulnerabilities in the future.

Attendees will leave with a deeper understanding of security engineering and inspirations for leveraging C++ to prevent potential security issues by design.

Max Hoffmann studied cybersecurity and got his Ph.D. in hardware security at the Ruhr University Bochum, Germany, in association with the Max Planck Institute for Security and Privacy at the research group of Professor Christof Paar. With a passion for teaching, he continues to contribute to the university as an external lecturer, shaping the next generation of cybersecurity professionals. As a Security Manager at ETAS, he oversees the Onboard Security portfolio, driving process improvements, supporting in technical discussions, managing vulnerabilities, and enhancing security awareness in the organization.

What to do if you don't want a default constructor? -- Sandor Dargo

By Blog Staff | Aug 13, 2024 04:38 PM | Tags: None

Do we need a default constructor? What does it mean to have a default constructor? What happens if we don’t have one? Those are the questions we are going after in this article.

What to do if you don't want a default constructor?

by Sandor Dargo

From the article:

A default constructor is a constructor that takes no arguments and initializes - hopefully - all the members with some default values. If you define no constructors at all, it’ll even be generated for you.

Do we need default constructors?

It really depends. Let’s first approach this question from a design point of view. Does it make sense to represent an object where the members are default initialized?

If you represent a tachograph, it probably makes sense to have such a default state where all the counters are initialized to zero.

The tachograph is the device that records driving times and rest periods as well as periods of other work and availability taken by the driver of a heavy vehicle.

On the other hand, if you represent a person or a task identifier - which inspired me to write this article - it doesn’t. A person with an empty name or a task ID with an empty ID doesn’t make much sense.

Well, that’s the case from a design point of view. What about the technical aspects? What happens if we don’t have a default constructor?