C++ programmer's guide to undefined behavior: part 8 of 11

Your attention is invited to the eighth part of an e-book on undefined behavior. This is not a textbook, as it's intended for those who are already familiar with C++ programming. It's a kind of C++ programmer's guide to undefined behavior and to its most secret and exotic corners. The book was written by Dmitry Sviridkin and edited by Andrey Karpov.

C++ programmer's guide to undefined behavior: part 8 of 11

by Dmitry Sviridkin

From the article:

To avoid issues, use conditional noexcept always and everywhere and carefully check every function you use. Or don't use noexcept at all. In the second case, however, it's worth remembering that both move operations and swap should be marked as noexcept (and really be noexcept!) to effectively work with standard containers. Don't forget to write negative tests. You may miss a false noexcept and get std::terminate in the release build without them.

Standard C++ Foundation Annual Report for Fiscal Year 2024

FY2024 Annual Report – Standard C++ Foundation

(fiscal year ending 2024-06-30)

 

Highlights

This fiscal year FY2024 from 2023-07-01 to 2024-06-30. Although most of the Foundation’s work is done virtually, the pandemic did affect some of our prominent operations in 2020 through 2022. CppCon 2023 and 2024 have now been successfully held normally again fully on-site, and the pandemic's effects are now fully behind us.

As in every recent year, the majority of funds received and spent in FY2024 were from running CppCon.

As we came out of the pandemic, per our financial assistance policy the Foundation resumed spending on supporting in-person ISO C++ standardization. When the ISO C++ committee (WG21) resumed holding in-person meetings, with online Zoom participation, the pandemic had "spilled the pipeline" of planned hosts; the Standard C++ Foundation was instrumental in keeping WG21 meetings going, by paying in whole or in part for hosting three of the first four post-pandemic WG21 meetings, two of which fell into FY2023 and one of which will fell into FY2024. The Foundation will again host a WG21 meeting in November 2025 (FY 2026).

During FY2024, the Foundation again provided financial travel assistance to expert participants whose ISO C++ proposals had been encouraged by WG21 but who would not otherwise have been able to attend to progress their proposals; however, because WG21 meetings are now hybrid, participants who are able to present their papers remotely do not need travel assistance to attend the meeting.

Thank you very much once again to the Foundation's members and all the CppCon attendees and sponsors! Your support directly enables the Foundation to be able to pay for these ISO meetings and support ISO participants from around the world.

CppCon

Every year, the Foundation runs the CppCon conference, which is currently the largest C++ conference in the world. Since its inception in 2014, a goal for CppCon has been to help raise the bar for all C++ sister conferences. In our inaugural conference in 2014, we were the first C++ conference we know of to professionally record all talks and panels using a paid film crew, and make the videos available for free to everyone in the world; since then, several other conferences have followed suit, including that some have used the same video production company CppCon uses (Bash Films, which we can highly recommend). In each year since, we have continued to strive to add features, most recently professional in-room live captioning in 2019.

CppCon 2023 was held in October 2023, and CppCon 2024 in September 2024 (which is in FY 2025 but the information is now already available to report). Both enjoyed the highest number of talk submissions ever (second only to pre-pandemic 2019), and both years had year-over-year increases in attendees, sponsors, and exhibitors. We thank all our sponsors, exhibitors, volunteers, and attendees.

The professionally recorded C++ videos are made available worldwide at no charge on the CppCon YouTube channel. Here are some basic channel statistics updated for this fiscal year:

  • combined viewership: 20.5 million views (+4.1M views in the past year)
  • total watch time: 5.5 million hours (+600K hours in the past year)
  • channel subscribers: over 154,000 (+20K subscribers in the past year)

Next report

Our next annual report will cover the fiscal year from 2024-07-01 to 2025-06-30. Besides being published here, the annual report will also be given as usual as a live presentation at our annual Foundation members meeting which is held during the week of the autumn WG21 meeting.

About the Standard C++ Foundation

The Standard C++ Foundation (Standard CPP Foundation in some databases that don’t support + in names) is a Washington 501(c)(6) not-for-profit organization whose purpose is to support the C++ software developer community and promote the understanding and use of modern Standard C++ on all compilers and platforms. We do this by operating and funding isocpp.org, the github.com/isocpp and github.com/cplusplus repositories, the CppCon conference including CppCon.org and the CppCon YouTube channel, and providing financial assistance support for WG21 (ISO C++ committee) standards meetings for meeting hosting costs, travel assistance for attendees in financial need, and grants to progress WG21 proposals that have been encouraged but whose the authors cannot progress further without some financial assistance and that the WG21 major subgroup chairs have approved funding.

###

The “Standard C++ Foundation” name and stylized “C++” logo are trademarks of the Standard C++ Foundation. See isocpp.org/home/terms-of-use.

Smart Pointers and the Pointer to Implementation Idiom -- Andreas Fertig

me.pngA post I wrote back in 2023 When an empty destructor is required resulted in feedback that I'd like to address in today's post.

Smart Pointers and the Pointer to Implementation Idiom

by Andreas Fertig

From the article:

In the 2023 post, I briefly mentioned PImpl idiom. I did not intend to make it the theme of the post. However, I got various questions about PImpl and smart pointers.

The goal of PImpl is to hide implementation details from clients. Since you can declare a pointer of an unknown class, you can shift the entire implementation of such an anonymous class into a .cpp file. That way, no client can see any details. Another benefit is that changes to that .cpp file result in only minor recompiles. Maintaining the same in a header file would cause all .cpp files, including this header, to recompile. At least the speed-up part is since C++20's modules are no longer necessary. And as long as you don't want to hide classified implementation in the .cpp file modules, it also gives you the ability to mark constructs as private.

 

C++ programmer's guide to undefined behavior: part 7 of 11

Your attention is invited to the seventh part of an e-book on undefined behavior. This is not a textbook, as it's intended for those who are already familiar with C++ programming. It's a kind of C++ programmer's guide to undefined behavior and to its most secret and exotic corners. The book was written by Dmitry Sviridkin and edited by Andrey Karpov.

C++ programmer's guide to undefined behavior: part 7 of 11

by Dmitry Sviridkin

From the article:

In the early '70s, Ken Thompson, Dennis Ritchie, and Brian Kernighan worked on the first versions of C and Unix. They made a decision that resonates with pain, suffering, bugs, and inefficiency today, 50 years later. They decided that developers were to write strings—variable-length data—in a sequence that terminated with a null character. Assembly has it, and C should have it too, if people call it "high-level assembly"! After all, the poor old PDP has limited memory: it's better to have one extra byte per string than 2, 4, or even all 8 bytes (depending on the platform) to store the size... Nah, it's better to have a byte at the end! But even other languages store a size, a reference, or a pointer to the data...

Meeting C++ 2024: the last hybrid C++ conference?

Like last year sharing my thoughts on that Meeting C++ 2024 is the only hybrid C++ conference.

Meeting C++ 2024: the last hybrid C++ conference?

by Jens Weller

From the article:

While I'm happy that Meeting C++ 2024 is not the last online conference, I do have once again to wonder if its the last hybrid one.

Once again I'd like to document my thoughts on running a hybrid conference, and also ask the C++ community for the support if you value such an offer being available world wide. In the end the numbers of this years conference will once again decide if I think that continueing is worth it.

Its easier to run a conference without a live stream...

The Definitive Guide to std::expected in C++ -- John Farrier

std::expected is a powerful feature introduced in C++23 that offers a modern, type-safe alternative to traditional error-handling methods.  std::expected allows developers to represent a value or an error in a single object, simplifying the handling of success and failure scenarios in a clean and readable way.

The Definitive Guide to std::expected in C++

John Farrier

From the article:

std::expected is an addition to the C++ standard library that provides a way to return and propagate errors without using exceptions. It represents a value or an error and is similar to the Result type in Rust. This guide covers its use, benefits, and comparison with other error handling techniques, helping developers to write more robust and readable code.

CGAL Released, Computational Geometry Algorithms Library -- Laurent Rineau

The CGAL Open Source Project is pleased to announce the recent releases of CGAL versions 5.5.5, 5.6.2, 6.0, and 6.0.1.

New CGAL versions: 5.5.5, 5.6.2, 6.0, and 6.0.1

by Laurent Rineau

From the article

CGAL version 6.0

CGAL version 6.0 was released on September 27, 2024. Following the discovery of early issues, version 6.0.1 was subsequently released on October 22, 2024.

This version is a major release, with many new features and improvements.

General changes

  • C++17 Requirement: CGAL 6.0 requires a C++17 compatible compiler.
  • GMP/MPFR Optional: GMP/MPFR are no longer mandatory; Boost.Multiprecision can be used.
  • Qt6 Demos: All demos are now based on Qt6.
  • Polyhedral Surface: The demo has been renamed to “CGAL Lab” and moved to its own directory in demo/Lab/.

New Packages

Breaking Changes

  • CMake Changes: UseCGAL.cmake removed; use CGAL::CGAL target instead.
  • Kernel: Replaced boost::variant with std::variant and boost::optional with std::optional in the intersection functions.

Enhancements

  • AABB Tree: Now supports 2D and 3D primitives.

Passing C++ STL Strings vs. String Views at the Windows C API Boundary -- Giovanni Dicanio

A common question that is often asked is whether C++ STL string objects (like std::string/wstring) or string views (e.g. std::wstring_view) should be passed as string parameters at Windows C-interface API boundaries. The following articles tries to shed some light on this subject, answering that question:

Passing C++ STL Strings vs. String Views as Input Parameters at the Windows C API Boundary

by Giovanni Dicanio

From the article:

Passing STL std::[w]string objects at Win32 API boundaries is common for C++ code that calls into Win32 C-interface APIs. When is it safe to pass *string views* instead?

(...) the code will work fine. In fact, the wstring::c_str() method is guaranteed to return a null-terminated C-style string pointer.

On the other hand, if you pass a string view like std::wstring_view in that context, you’ll likely get some subtle bugs! Try experimenting with the above API and something like “Connie is learning C++” and string views!

 

Code Generation in Rust vs C++26 -- Barry Revzin

TPWGDVRj_400x400.jpgExploring how different languages solve the same problem often reveals interesting contrasts, especially when it comes to implementing powerful features like reflection. While C++26 aims to introduce introspection and code generation via P2996 and P3294, Rust’s approach using its derive macros offers a mature solution for code generation, even without introspection, highlighting different philosophies in language design and their practical applications.

Code Generation in Rust vs C++26

by Barry Revzin

From the article:

One of the things I like to do is compare how different languages solve the same problem — especially when they end up having very different approaches. It’s always educational. In this case, a bunch of us have been working hard on trying to get reflection — a really transformative language feature — into C++26. Fundamentally, reflection itself can be divided into two pieces:

  1. Introspection — the ability to ask questions about your program during compilation
  2. Code Generation — the ability to have your code write new code

P2996 (Reflection for C++26) is the (huge) core proposal that fundamentally deals with the first problem, along with setting the foundation for being able to extend this feature in lots of different directions in the future, including generation (for which our design is P3294). But introspection, while valuable, is only half of the piece. Andrei Alexandrescu went so far as to claim in his CppCon talk that introspection without generation is useless.