Home » Blog » Categories »

The Usual Arithmetic Confusions -- Shafik Yaghmour

By Blog Staff | Jun 3, 2025 05:01 PM | Tags: None

C++’s type conversion rules—particularly the usual arithmetic conversions and integral promotions—are often misunderstood, even by experienced developers. These rules quietly reshape operands behind the scenes during arithmetic and relational operations, sometimes leading to surprising or platform-dependent behavior that can be tricky to debug or reason about.

The Usual Arithmetic Confusions

by Shafik Yaghmour

From the article:

There are a lot of aspects of C++ that are not well understood and lead to all sorts of confusion. The usual arithmetic conversions and the integral promotions are two such aspects. Certain binary operators (arithmetic, relational and spaceship) require their operands to have a common type. The usual arithmetic conversions are the set of steps that gets operands to a common type. While the integral promotions brings integral types smaller than int and unsigned int to either int or unsigned int depending on which one can represent all the values of the source type. This is one of the areas in C++ that comes directly from C, so pretty much all of these examples applies to C as well as C++.

We will see some examples with results that many may find surprising. After seeing some of these cases we will discuss the rules and how they explain each case. While covering each rule we will present examples to clarify the rule. We will referring to ILP32 and LP64 data models and it may help to familiarize yourself with the size of types in these models.

It would also help to understand integer literals and the rules around what the type of an integer literal will be in various cases e.g.

// https://cppinsights.io/s/0ffee264 
void f() { 
    auto x1 = 1; // Integer literal 1 will have type int 
    auto x2 = 1U; // Integer literal 1L will have type unsigned int 
    auto x3 = 1L; // Integer literal 1L will have type long int 
    auto x4 = 1UL; // Integer literal 1UL will have type unsigned long int 
}

I will be including C++ Insights links for many examples.

CppCon 2024 Introduction to Wait-free Algorithms in C++ Programming -- Daniel Anderson

By Blog Staff | Jun 2, 2025 12:49 PM | Tags: None

lockfree-anderson.pngRegistration 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!

Introduction to Wait-free Algorithms in C++ Programming

by Daniel Anderson

Summary of the talk:

If you've attended any talks about concurrency, you've no doubt heard the term "lock-free programming" or "lock-free algorithms". Usually these talks will give you a slide that explains vaguely what this means, but you accept that is is approximately (but not quite exactly) equal to "just don't use locks". More formally, lock-freedom is about guaranteeing how much progress your algorithm will make in a given time. Specifically, a lock-free algorithm will always make some progress on at least one operation/thread. It does not guarantee however that all threads make progress. In a lock-free algorithm, a particular operation can still be blocked for an arbitrary long time because of the actions of other contending threads. What can we do in situations where this is unacceptable, such as when we want to guarantee low latency for every operation on our data structure rather than just low average latency?

In these situations, there is a stronger progress guarantee that we can aim for called wait-freedom. An algorithm is wait free if every operation is guaranteed to make progress in a bounded amount of time, i.e., no thread can ever be blocked for an arbitrarily long time. This helps to guarantee low tail latency for all operations, rather than low average latency in which some operations are left behind. In this talk, we will give an introduction to designing and implementing wait-free algorithms.

Without assuming too much background of the audience, we will review the core ideas of lock-free programming and understand the classic techniques for transforming a blocking algorithm into a lock-free one. The main bread-and-butter technique for lock-free algorithms is the compare-exchange loop or "CAS loop", in which an operation reads the current state of the data structure, creates some sort of updated version, and then attempts to install the update via a compare-exchange, looping until it succeeds. compare-exchange loops suffer under high contention since the success of one operation will often cause another to have to repeat work until they succeed. The bread-and-butter technique of wait-free programming that overcomes this issue is helping. When operations contend, instead of racing to see who wins, an operation that encounters another already-in-progress operation attempts to help it complete first, then proceeds with its own operation. This results in the initial operation succeeding instead of being clobbered and forced to try again.

CppCon 2024 Strategies for Developing Safety-Critical Software in C++ -- Emily Durie-Johnson

By Blog Staff | May 30, 2025 12:45 PM | Tags: None

strategies-durie.pngRegistration 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!

Lightning Talk: Strategies for Developing Safety-Critical Software in C++

by Emily Durie-Johnson

Summary of the talk:

This talk delves into the importance of a safety-first mindset in software development within the medical device domain. It explores the intersection of C++ and industry standards that ensure safety-critical software. Attendees will learn to ask guiding questions during code development that emphasize the importance of coding as if the technology will be used on their loved ones. With real-world examples and best practices, this session highlights the personal and professional responsibilities of engineers in safety-critical fields to create reliable software.

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

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

RaymondChen_5in-150x150.jpgWhen 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

internalclass-ryan.pngRegistration 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

SANDOR_DARGO_ROUND.JPGIn 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

nextdecade-sutter.pngRegistration 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!

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.