Clang 20.1.0 Release Notes - Clang 20.1.0 Documentation

By Blog Staff | May 6, 2025 01:43 PM | Tags: None

Clang 20.1.0 Release Notes - Clang 20.1.0 Documentation

From the release notes:

C++ Language Changes

• Allow single element access of GCC vector/ext_vector_type object to be constant expression. Supports the V.xyzw syntax and other tidbits as seen in OpenCL. Selecting multiple elements is left as a future work.
• Implement CWG1815. Support lifetime extension of temporary created by aggregate initialization using a default member initializer.
• Accept C++26 user-defined static_assert messages in C++11 as an extension.
• Add __builtin_elementwise_popcount builtin for integer types only.
• Add __builtin_elementwise_fmod builtin for floating point types only.
• Add __builtin_elementwise_minimum and __builtin_elementwise_maximum builtin for floating point types only.
• The builtin type alias __builtin_common_type has been added to improve the performance of std::common_type.

C++2c Feature Support

• Add __builtin_is_virtual_base_of intrinsic, which supports P2985R0 A type trait for detecting virtual base classes
• Implemented P2893R3 Variadic Friends
• Implemented P2747R2 constexpr placement new.
• Added the __builtin_is_within_lifetime builtin, which supports P2641R4 Checking if a union alternative is active
• Implemented P3176R1 The Oxford variadic comma

C++23 Feature Support

• Removed the restriction to literal types in constexpr functions in C++23 mode.
• Extend lifetime of temporaries in mem-default-init for P2718R0. Clang now fully supports P2718R0 Lifetime extension in range-based for loops.
• __cpp_explicit_this_parameter is now defined. (#82780)
• Add __builtin_is_implicit_lifetime intrinsic, which supports P2674R1 A trait for implicit lifetime types
• Add support for P2280R4 Using unknown pointers and references in constant expressions. (#63139)

C++20 Feature Support

• Implemented module level lookup for C++20 modules. (#90154)

Slides of the 22nd of April 2025 BeCPP Meeting

By Marc Gregoire | May 6, 2025 09:17 AM | Tags: community

On April 22nd 2025, I organized the next Belgian C++ Users Group event. There were 2 sessions:
- "Algorithm intuition revisited" (Bruno Hendrickx)
- "Compile-Time Emulation of an 8080-Inspired System in C++" (Tom Tesch)

You can find the schedule (with abstracts), slides, and pictures on the BeCPP blog:
Schedule: https://becpp.org/blog/2025/03/16/next-becpp-ug-meeting-planned-for-april-22nd-2025/
Slides: https://becpp.org/blog/2025/05/06/slides-of-the-22nd-of-april-2025-becpp-meeting/
Pictures: https://becpp.org/blog/2025/05/06/pictures-of-the-22nd-of-april-2025-becpp-meeting/

Speeding up C++ Code with Template Lambdas -- Daniel Lemire

By Blog Staff | May 5, 2025 01:51 PM | Tags: None

Integer division is one of the most expensive operations in C++, but when the divisor is known at compile time, the compiler can optimize it significantly. This post explores different approaches—using templates, lambda expressions, and template metaprogramming—to speed up division while maintaining clean and efficient code.

Speeding up C++ Code with Template Lambdas

by Daniel Lemire

From the article:

Let us consider a simple C++ function which divides all values in a range of integers:

void divide(std::span<int> i, int d) {
 for (auto& value : i) {
 value /= d;
 }
}

A division between two integers is one of the most expensive operations you can do over integers: it is much slower than a multiplication which is, in turn, more expensive than an addition. If the divisor d is known at compile-time, this function can be much faster. E.g., if d is 2, the compiler might optimize away the division and use a shift and a few cheap instructions instead. The same is true with all compile-time constant: the compiler can often do better knowing the constant. (See Lemire et al., Integer Division by Constants: Optimal Bounds, 2021)

GCC 15 is now available, with support for more draft C++26 features

By Blog Staff | May 1, 2025 02:08 PM | Tags: None

GCC 15 is now available!

Here are some highlights from the release notes' C++ section:

• Several C++26 features have been implemented:
  • P2558R2, Add @, $, and ` to the basic character set (PR110343)
  • P2552R3, On the ignorability of standard attributes (PR110345)
  • P2662R3, Pack indexing (PR113798)
  • P0609R3, Attributes for structured bindings (PR114456)
  • P2573R2, = delete("reason"); (PR114458)
  • P2893R3, Variadic friends (PR114459)
  • P3034R1, Disallow module declarations to be macros (PR114461)
  • P2747R2, constexpr placement new (PR115744)
  • P0963R3, Structured binding declaration as a condition (PR115745)
  • P3144R2, Deleting a pointer to an incomplete type should be ill-formed (PR115747)
  • P3176R0, Oxford variadic comma (PR117786)
  • P2865R5, Removing deprecated array comparisons (PR117788)
  • P1967R14, #embed (PR119065)
  • P3247R2, Deprecating the notion of trivial types (PR117787)

• C++ Modules have been greatly improved.

• Compilation time speed ups, e.g. by improving hashing of template specializations.

... and more, see the release notes.

C++26: Removing Language Features -- Sandor Dargo

By Blog Staff | May 1, 2025 01:48 PM | Tags: None

C++ is often seen as an ever-growing language, with each new standard introducing powerful features while maintaining backward compatibility. However, C++26 takes a step toward simplification by officially removing deprecated features, including implicit arithmetic conversions for enumerations and direct comparisons of C-style arrays, both of which previously led to unintended behavior.

C++26: Removing Language Features

by Sandor Dargo

From the article:

Probably you all heard that C++ is an ever-growing language - I wrote so many times as well. Each standard indeed comes with a great bunch of highly-anticipated features. At the same time, due to binary compatibility considerations, very few old features are removed. This has several implications:

• we have probably more than one way to do something
• the standard keeps growing

This is true, but let’s not forget that each new standard removes some features. In this post, let’s review what are the language features that are removed in C++26 and in a later post, we’ll have a look at the removed library features.

At this point, it’s worth mentioning that a removal from the language usually happens in two steps. First a feature gets deprecated, meaning that its users would face compiler warnings for using deprecated features. As a next step, which in some cases never comes, the compiler support is finally removed.

 

2025 Annual C++ Developer Survey "Lite"

By Blog Staff | Apr 30, 2025 04:11 PM | Tags: None

The annual global C++ developer survey is now open. As the name suggests, it's short:

2025 Annual C++ Developer Survey "Lite"

Please take 10 minutes or so to participate! A summary of the results, including aggregated highlights of common answers in the write-in responses, will be posted publicly here on isocpp.org and shared with the C++ standardization committee participants to help inform C++ evolution.

The survey closes in one week.

Thank you for participating and helping to inform our committee and community!

Bjarne Stroustrup on How He Sees C++ Evolving -- David Cassel

By Blog Staff | Apr 29, 2025 01:44 PM | Tags: None

Bjarne Stroustrup, creator of C++, is advocating for the adoption of guideline-enforcing profiles to enhance the language's safety and security.

Bjarne Stroustrup on How He Sees C++ Evolving

by David Cassel

From the article:

“I wanted to educate the community at large, and members of WG21 in particular — on my views of C++’s intended direction of evolution,” Bjarne Stroustrup told TNS.

The 74-year-old creator of C++ has spent 40 years of his life watching the growth of the language he designed back in 1985.

To encourage some long-desired features, last month in Communications of the ACM Stroustrup published “21st Century C++“, a 6,300-word article promising to show “key concepts” for modern, type-safe “21st-century C++” to create “C++ on steroids”. For example, in the article Stroustrup highlighted long-standing experiments in approaches like writing safer code with guideline-enforcing profiles. To maintain compatibility with decades of already-written C++ code, “We can’t change the language,” Stroustrup writes. “But we can change the way it is used…”

Yet that evolution isn’t entirely up to him. In a section towards the end, Stroustrup acknowledges WG21, the standardization working group, and how it will inevitably play a role in how much the language can change. 

Vibe Coding C++ - Jens Weller - Meeting C++ online

By Meeting C++ | Apr 27, 2025 04:40 AM | Tags: meetingcpp intermediate experimental community basics

I've talked about my experiments with testing chatbots for their code generation with C++

Vibe Coding C++ - Jens Weller

by Jens Weller

Details of std::mdspan from C++23 -- Bartlomiej Filipek

By Blog Staff | Apr 25, 2025 01:34 PM | Tags: None

In this article, we’ll see details of std::mdspan, a new view type tailored to multidimensional data. We’ll go through type declaration, creation techniques, and options to customize the internal functionality.

Details of std::mdspan from C++23

by Bartlomiej Filipek

From the article:

In this article, we’ll see details of std::mdspan, a new view type tailored to multidimensional data. We’ll go through type declaration, creation techniques, and options to customize the internal functionality.

Type declaration 

The type is declared in the following way:

template<  
     class T,  
     class Extents,  
     class LayoutPolicy = std::layout_right,  
     class AccessorPolicy = std::default_accessor<T> 
> class mdspan; 

And it has its own header <mdspan>.

The main proposal for this feature can be found at https://wg21.link/P0009

Following the pattern from std::span, we have a few options to create mdspan: with dynamic or static extent.

The key difference is that rather than just one dimension, we can specify multiple. The declaration also gives more options in the form of LayoutPolicy and AccessorPolicy. More on that later.

C++26: No More UB in Lexing -- Sandor Dargo

By Blog Staff | Apr 23, 2025 01:34 PM | Tags: None

Undefined behavior in C++ is a well-known source of headaches for developers, but surprisingly, even the lexing process contained cases of it—until now. Thanks to P2621R3 by Corentin Jabot, unterminated strings, macro-generated universal character names, and spliced UCNs are now formally defined, aligning the standard with real-world compiler behavior.

C++26: No More UB in Lexing

by Sandor Dargo

From the article:

If you ever used C++, for sure you had to face undefined behaviour. Even though it gives extra freedom for implementers, it’s dreaded by developers as it may cause havoc in your systems and it’s better to avoid it if possible.

Surprisingly, even the lexing process in C++ can result in undefined behaviour. Thanks to Corentin Jabot’s work and his P2621R3 that won’t be the case anymore. As it was accepted as a defect report starting from C++98, in fact, you benefit from this already if you use a new enough compiler.

Truth be told, compilers didn’t do any dangerous. They handled the below cases safely and deterministically. So this change is really about updating the standard and matching implementers’ work.

Let’s quickly see the three cases.

Unterminated strings

     // unterminated string used to be UB
     const char * foo = "

Who would have thought that an unterminated string or a character was UB?! Despite the permissive standard, all major compilers identified it as ill-formed. From now on, even the standard says so.