: Standard C++

Home »

« Prev Next »

Function overloading is more flexible than template function specialization -- Raymond Chen

By Blog Staff | May 29, 2025 05:00 PM | Tags: None

When trying to specialize a templated function for specific types, it’s easy to fall into subtle traps around how parameter types are matched. A colleague recently ran into this issue while attempting to specialize a function for a Widget and a string literal, only to be met with confusing compiler errors that hinted at deeper quirks in C++'s type deduction and function template specialization rules.

Function overloading is more flexible (and more convenient) than template function specialization

by Raymond Chen

From the article:

A colleague of mine was having trouble specializing a templated function. Here’s a simplified version.
template<typename T, typename U>
bool same_name(T const& t, U const& u)
{
    return t.name() == u.name();
}
They wanted to provide a specialization for the case that the parameters are a Widget and a string literal.
template<>
bool same_name<Widget, const char[]>(Widget const& widget, const char name[])
{
    return strcmp(widget.descriptor().name().c_str(), name) == 0;
}
However, this failed to compile:
// msvc
error C2912: explicit specialization 'bool 
same_name<Widget,const char[]>(const Widget &,const char 
[])' is not a specialization of a function template
What do you mean “not a specialization of a function template”? I mean doesn’t it look like a specialization of a function template? It sure follows the correct syntax for a function template specialization.

CppCon 2024 C++ Under the Hood: Internal Class Mechanisms -- Chris Ryan

By Blog Staff | May 28, 2025 12:41 PM | Tags: None

Registration is now open for CppCon 2025! 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 2025!

C++ Under the Hood: Internal Class Mechanisms

by Chris Ryan

Summary of the talk:

My talk will examine the internal C++ mechanisms around the topics of:

The C++ onion as it relates to construction, destruction and polymorphism,

Order of Object construction & destruction, and pre- & post-main() processing.

Member Function Pointers (not your father’s C function pointer),

Member Data Pointers (not raw pointers) (data-morphic functionality),

Understanding the Call Stack, Stack Frames and Base Pointer mechanisms.

C++26: More constexpr in the Core Language -- Sandor Dargo

By Blog Staff | May 27, 2025 05:00 PM | Tags: None

In this article, we review how constexpr evolves in the C++26 core language. We are getting constexpr cast from void*, placement new, structured bindings and even exceptions (not discussed today).

C++26: More constexpr in the Core Language

by Sandor Dargo

From the article:

Since constexpr was added to the language in C++11, its scope has been gradually expanded. In the beginning, we couldn’t even use if, else or loops, which were changed in C++14. C++17 added support for constexpr lambdas. C++20 added the ability to use allocation and use std::vector and std::string in constant expressions. In this article, let’s see how constexpr evolves with C++26. To be more punctual, let’s see what language features become more constexpr-friendly. We’ll discuss library changes in a separate article, as well as constexpr exceptions, which need both language and library changes.

P2738R1: constexpr cast from void*

Thanks to the acceptance of P2738R1, starting from C++26, one can cast from void* to a pointer of type T in constant expressions, if the type of the object at that adress is exactly the type of T.

Note that conversions to interconvertible - including pointers to base classes - or not related types are not permitted.

The motivation behind this change is to make several standard library functions or types work at compile time. To name a few examples: std::format, std::function, std::function_ref, std::any. The reason why this change will allow many more for more constexpr in the standard library is that storing void* is a commonly used compilation firewall technique to reduce template instantiations and the number of symbols in compiled binaries.

Introducing the Laso scolarship for Spanish students

By Jordi Mon Companys | May 27, 2025 08:32 AM | Tags: None

The Laso scholarship was created in memory of Luis Martinez de Bartolomé, a dear colleague and friend, and recognize his significant contribution to open source and C++ world

Introducing the Laso scolarship for Spanish students

by the conan.io team

From the article:

The Laso scholarship will be provided to students of Spanish public universities in any degree of CS, Engineering or similar. The scholarship will cover the costs of one year tuition.

Team tickets and asking questions for Meeting C++ 2025

By Meeting C++ | May 27, 2025 07:20 AM | Tags: meetingcpp events conference

Two news items for Meeting C++ 2025, introducing team tickets and adding questions to the ticket ordering process to know your t-shirt size and more.

New Team Tickets for Meeting C++ 2025

by Jens Weller

From the article:

I'd like to make it easier to send your team to Meeting C++ 2025 with offering a team ticket.

I can't really break with the 1:1 relation between a ticket and its attendee, but I can offer a ticket...

Asking questions with the tickets for Meeting C++ 2025

by Jens Weller

From the article:

There is an update I've made to the tickets for this year, adding Questions that you may answer when registering for Meeting C++ 2025.

This years conference keeps me busy right now, but I quickly wanted to bring you an update on the ticktes. For the first time Meeting C++ includes a few questions with the registration for attendees. This way we get more accurate data on, but also for the attendees...

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

By Blog Staff | May 26, 2025 12:37 PM | Tags: None

Peering Forward - C++’s Next Decade

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.

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.

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.

CppCon 2024 From Macro to Micro in C++ -- Conor Spilsbury

By Blog Staff | May 24, 2025 12:32 PM | Tags: None

Lightning Talk: From Macro to Micro in C++

by Conor Spilsbury

Summary of the talk:

Our continuous real-time monitoring led us to investigate an anomaly in the data about our system's performance. This led us to investigate and identify the culprit: a specific data structure used in our code and the way that structure was being initialized.

Streamlined Iteration: Exploring Keys and Values in C++20 -- Daniel Lemire

By Blog Staff | May 23, 2025 04:49 PM | Tags: None

Modern C++ offers a variety of ways to work with key-value data structures like std::map and std::unordered_map, from traditional loops to sleek functional-style expressions using C++20 ranges. By exploring both styles and benchmarking them across platforms, we can better understand how newer language features affect readability, expressiveness, and performance.

Streamlined Iteration: Exploring Keys and Values in C++20

by Daniel Lemire

From the article:

In software, we often use key-value data structures, where each key is unique and maps to a specific value. Common examples include dictionaries in Python, hash maps in Java, and objects in JavaScript. If you combine arrays with key-value data structures, you can represent most data.

In C++, we have two standard key-value data structures: the std::map and the std::unordered_map. Typically, the std::map is implemented as a tree (e.g., a red-black tree) with sorted keys, providing logarithmic time complexity O(log n) for lookups, insertions, and deletions, and maintaining keys in sorted order. The std::unordered_map is typically implemented as a hash table with unsorted keys, offering average-case constant time complexity O(1) for lookups, insertions, and deletions. In the std::unordered_map, the hash table uses a hashing function to map keys to indices in an array of buckets. Each bucket is essentially a container that can hold multiple key-value pairs, typically implemented as a linked list. When a key is hashed, the hash function computes an index corresponding to a bucket. If multiple keys hash to the same bucket (a collision), they are stored in that bucket’s linked list.

Quite often, we only need to look at the keys, or look at the values. The C++20 standard makes this convenient through the introduction of ranges (std::ranges::views::keys and std::ranges::views::values). Let us consider two functions using the ‘modern’ functional style. The first function sums the values and the next function counts how many keys (assuming that they are strings) start with a given prefix.

CppCon 2024 To Int or to Uint, This is the Question -- Alex Dathskovsky

By Blog Staff | May 22, 2025 12:26 PM | Tags: None

To Int or to Uint, This is the Question

by Alex Dathskovsky

Summary of the talk:

In our daily work, we often use integral data types to perform arithmetic calculations, but we may not always consider how the selection of the data type can affect performance and compiler optimizations. This talk will delve into the importance of choosing the correct data type for the job and how it impacts compiler optimizations. We will also examine the overall performance implications for the application. We will explore specific algorithms where using unsigned data types is more beneficial and other situations where signed data types are the best choice. Furthermore this talk will dive into the differences between signed and unsigned integers, how the processor handles certain operations and explain many of the surprising pitfalls of using integral types.

Attendees will come away with a deeper understanding of how data type selection can impact their code and how to make better choices for optimal performance.

This session will follow the guidelines from my short article on LinkedIn but it will go into higher details and contain more examples and explanations.

Owning and non-owning C++ Ranges -- Hannes Hauswedell

By Hannes Hauswedell | May 22, 2025 09:39 AM | Tags: None

This is the first article in a series discussing some of the underlying properties of C++ ranges and in particular range adaptors. At the same time, I introduce the design of an experimental library which aims to solve some of the problems discussed here.

Owning and non-owning C++ Ranges

by Hannes Hauswedell

From the article:

We will begin by having a look at ranges from the standard library prior to C++20, since this is what people are most used to. Note that although the ranges themselves are from C++17, I will use some terminology/concepts/algorithms introduced later to explain how they relate to each other. Remember that to count as a range in C++, a type needs to have just begin() and end(). Everything else is bonus.

[…]

Containers are the ranges everybody already used before Ranges were a thing. They own their elements, i.e. the storage of the elements is managed by the container and the elements disappear when the container does. Containers are multi-pass ranges, i.e. you can iterate over them multiple times and will always observe the same elements.

[…]

If containers are owning ranges, what are non-owning ranges? C++17 introduced a first example: std::string_view, a range that consists just of a begin and end pointer into another range’s elements.

[…]

However, the most important (and controversial) change came by way of P2415, which allowed views to become owning ranges. It was also applied to C++20 as a defect report, although it was quite a significant design change. This is a useful feature, however, it resulted in the std::ranges::view concept being changed to where it no longer means “non-owning range”.

[…]