: Standard C++

Home »

« Prev Next »

2026 Annual C++ Developer Survey "Lite"

By Blog Staff | Apr 21, 2026 05:58 PM | Tags: None

The annual global C++ developer survey is now open:

2026 Annual C++ Developer Survey "Lite"

Please share your feedback in this annual 10-minute survey to help inform C++ standardization and C++ tool vendors. This is the biggest opportunity we all have each year to make our voices heard and help improve our industry and community!

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 and C++ tool vendors to help inform C++ evolution and tooling.

The survey closes in one week.

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

CppCon 2025 C++: Some Assembly Required -- Matt Godbolt

By Blog Staff | Apr 21, 2026 02:12 PM | Tags: None

Registration is now open for CppCon 2026! The conference starts on September 12 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 2026!

C++: Some Assembly Required

by Matt Godbolt

Summary of the talk:

Join Matt in exploring how the C++ ecosystem has evolved through the interplay of intentional design and emergent collaboration. Standards committees craft language features and compiler teams implement them, but something amazing happens in the spaces between: tools appear, communities form, and solutions emerge that nobody quite planned for. What started as individual developers solving their own problems has grown into an interconnected ecosystem that shapes how we all write C++.

From documentation to testing, from build systems to package managers, we'll examine how the C++ community has assembled itself around shared pain points and accidental standards. Using examples and perhaps too many rainforest metaphors, this talk celebrates not just the language we've built, but the organic ecosystem that's grown up around it. Come discover why C++'s greatest strength might be that it's always required some assembly.

Let's check vibe code that acts like optimized C++ one but is actually a mess

By Andrey Karpov | Apr 21, 2026 04:04 AM | Tags: vibe code simd pvs-studio optimization markus code review claude opus

The value of a skilled developer is shifting toward the ability to effectively review code. Although generating code now is easier than ever, evaluating it for proper decomposition, correctness, efficiency, and security is still important. To see why it's important to understand generated code and to recognize what lies beneath a program's elegant syntax, let's look at a small project called markus, created using Claude Opus.

Let's check vibe code that acts like optimized C++ one but is actually a mess

by Andrey Karpov

From the article:

Clearly, the 64-bit code is much more efficient, except when SSE2 is involved. Even then, though, everything runs quickly. The code Claude Opus generated for the markus project is the worst of all the options. Not only is the simplest implementation with a regular loop faster, it's also shorter. The extra code lines only made things worse.

CppCon 2025 How C++ Finally Beats Rust at JSON Serialization -- Lemire & Thiesen

By Blog Staff | Apr 17, 2026 12:33 PM | Tags: None

How C++ Finally Beats Rust at JSON Serialization

by Daniel Lemire & Francisco Geiman Thiesen

Summary of the talk:

JSON, or JavaScript Object Notation, has become a cornerstone for storing and exchanging data. Its appeal lies in its simplicity—human-readable text that elegantly captures structured data through attribute-value pairs and arrays: {"age": 5, "name": "Daniel", "toys": ["wooden dog", "little car"]}. JSON is intuitive yet powerful. But ingesting and producing JSON can turn into a performance choke point. In C++, it can be a tedious, error-prone task. Programmers wrestle with unexpected content, manually mapping data to and from native structures, all while striving for speed and safety.

With languages like Java, C#, Zig, Rust, or Python, JSON serialization and deserialization typically requires far less work. In particular, Rust's serde library blends convenience with high speed. We wish for a C++ library to automatically handle JSON production and consumption, seamlessly tied to native data structures. It is not merely to simplify life for developers; it is also about crafting code that is both fast and solid, generated at compile time by a battle-tested library.

Thankfully, C++ might soon be getting reflective metaprogramming ( PR2996 ). Leveraging the experimental Bloomberg LLVM fork with reflective metaprogramming, we have built a full-fledged implementation—complete with tests, benchmarks, and documentation. Our goal is to have production-ready code the moment mainstream compilers catch up. The results speak for themselves: we are parsing JSON directly into C++ structures at gigabytes per second, outpacing even mature heavyweights like Rust's serde. Better yet, the conversion between C++ data structures and JSON is fully automated, thanks to metaprogramming. It has the potential to be a leap forward for C++ in the data-driven age. Unfortunately, there are still problems and limitations: we present them and provide some solutions.

Devirtualization and Static Polymorphism -- David Álvarez Rosa

By Blog Staff | Apr 16, 2026 12:41 PM | Tags: None

Ever wondered why your clean, object-oriented design sometimes slows things down? This piece breaks down how virtual dispatch impacts performance—and how techniques like devirtualization and static polymorphism can eliminate that overhead entirely.

Devirtualization and Static Polymorphism

by David Álvarez Rosa

From the article:

Ever wondered why your “clean” polymorphic design underperforms in benchmarks? Virtual dispatch enables polymorphism, but it comes with hidden overhead: pointer indirection, larger object layouts, and fewer inlining opportunities.

Compilers do their best to devirtualize these calls, but it isn’t always possible. On latency-sensitive paths, it’s beneficial to manually replace dynamic dispatch with static polymorphism, so calls are resolved at compile time and the abstraction has effectively zero runtime cost.

CppCon 2025 Why Every C++ Game Developer Should Learn SDL 3 Now -- Mike Shah

By Blog Staff | Apr 15, 2026 12:30 PM | Tags: None

Why Every C++ Game Developer Should Learn SDL 3 Now

by Mike Shah

Summary of the talk:

The C++ programming language does not have a standard graphics library, However, there exists many popular graphics frameworks for cross-platform graphics. In this talk, I will provide an introduction to the Simple Directmedia Layer (SDL) library, which has at the start of 2025 released version 3. This library for several decades has been a standard in the games and graphics industry. Throughout this talk, I will show how to get started with the library, some more advanced examples (including compiling graphics applications to web), and then talk about what a standard graphics library could look like in C++, or if it is even necessary. I will also talk about the 3D GPU library in SDL3. Attendees will leave this talk ready to build multimedia / game applications and with an understanding on if SDL3 is the right tool for them.

Announcement: cppreference.com update

By Herb Sutter | Apr 14, 2026 03:35 PM | Tags: None

cppreference.com is the premier public reference site for documenting and tracking the C++ language. It is run by Nate Kohl, with the help of many volunteer wiki editors. I want to thank Nate and all the volunteers for making it such an enduringly valuable resource.

Like all software, the site requires maintenance. It has been in read-only mode for some time while Nate has been leading the work to migrate it to MediaWiki. Because the Standard C++ Foundation's web wizard, James Riordon, recently migrated the ISO C++ committee wiki (now also maintained by the Foundation) to MediaWiki, I asked Nate whether the Foundation and James could help. Nate accepted our offer, and thanks to Nate and James's work, cppreference is now almost ready to return to normal read-write operation.

To help keep the site running smoothly going forward, the Foundation plans to continue providing hosting and administrative support for the site's infrastructure, including future MediaWiki and related updates. That should let Nate stay focused on leading the site's content and coordinating the volunteer editors who keep cppreference current.

We expect the refreshed site, including support for all languages, to return to read-write mode later this month. Fingers crossed. My thanks again to Nate, James, and everyone who has helped make cppreference the indispensable reference it is today, and to everyone for their patience while this necessary maintenance has been underway.

Cheers,

Herb

using std::cpp 2026: Cross-Platform C++ AI Development with Conan, CMake, and CUDA

By jdgarcia | Apr 14, 2026 01:58 PM | Tags: None

Cross-Platform C++ AI Development with Conan, CMake, and CUDA

by Luis Caro Campos

From the talk at using std::cpp 2026:

Every year, the ISO C++ survey delivers the same verdict: dependency management is the #1 pain point for developers. For AI and machine learning development, introducing CUDA into the mix can cause that "pain point" to become a bigger bottleneck when developers these days are demanding “one-line, cross-platform” solutions.

This talk demonstrates how to use Conan and CMake to model the CUDA compatibility matrix directly in your code, achieving an ideal pipeline that works both on development machines, and CI, regardless of your target platform: One source checkout. One command. Identical builds on every platform.

CppCon 2025 Implementing Your Own C++ Atomics -- Ben Saks

By Blog Staff | Apr 14, 2026 09:23 AM | Tags: None

Implementing Your Own C++ Atomics

by Ben Saks

Summary of the talk:

Atomic objects are extremely useful for concurrent programming. Unfortunately, some embedded toolchains like AVR-GCC omit portions of the C++ Standard Library, including headers like ＜atomic＞ .This makes it much harder to program concurrent software on these platforms, since many tutorials and open-source libraries assume Standard Library support. For example, these talks from past CppCons present lock-free data structures and algorithms that rely strongly on lock-free instantiations of std::atomic＜T＞:

Single Producer Single Consumer Lock-free FIFO From the Ground Up – Charles Frasch – CppCon 2023
Introduction to Wait-free Algorithms in C++ Programming – Daniel Anderson – CppCon 2024
User API & C++ Implementation of a Multi Producer, Multi Consumer, Lock Free, Atomic Queue – Erez Strauss – CppCon 2024

This session will show you how to implement your own atomic types in the absence of library support. These atomic types can greatly expand the number of tutorials and open-source libraries available for you to use. A clear understanding of how atomic types are implemented will also help you use objects of those types more effectively on platforms that do provide native support.

Power of C++26 Reflection: Strong (opaque) type definitions -- r/cpp

By Blog Staff | Apr 9, 2026 02:35 PM | Tags: None

Inspired by a similar previous thread showcasing cool uses for C++26 reflection.

Power of C++26 Reflection: Strong (opaque) type definitions

From the article:

With reflection, you can easily create "opaque" type definitions, i.e "strong types". It works by having an inner value stored, and wrapping over all public member functions.

Note: I am using queue_injection { ... } with the EDG experimental reflection, which afaik wasn't actually integrated into the C++26 standard, but without it you would simply need two build stages for codegen. This is also just a proof of concept, some features aren't fully developed (e.g aggregate initialization)
struct Item { /* ... */ }; // name, price as methods

struct FoodItem;
struct BookItem;
struct MovieItem;

consteval { 
    make_strong_typedef(^^FoodItem, ^^Item); 
    make_strong_typedef(^^BookItem, ^^Item); 
    make_strong_typedef(^^MovieItem, ^^Item); 
}

// Fully distinct types
void display(FoodItem &i) {
    std::cout << "Food: " << i.name() << ", " << i.price() << std::endl;
}
void display(BookItem &i) {
    std::cout << "Book: " << i.name() << ", " << i.price() << std::endl;
}

int main() {
    FoodItem fi("apple", 10); // works if Item constructor isn't marked explicit
    FoodItem fi_conversion(Item{"chocolate", 5}); // otherwise
    BookItem bi("the art of war", 20);
    MovieItem mi("interstellar", 25);

    display(fi);
    display(bi);
    // display(Item{"hello", 1}); // incorrect, missing display(Item&) function
    // display(mi); // incorrect, missing display(MovieItem&) function
}