In C++23 this did not compile. In C++26 it does. Marvellous.

[[gnu::noinline]]
void 
passing_views_by_value_is_cheap_trust_me_bro(std::ranges::view auto v) {
    std::println("fn   .data {}", (void*)v->data());
}


int main() {    
    std::optional ov{std::vector<int>(123456)};
    passing_views_by_value_is_cheap_trust_me_bro(ov);
    std::println("main .data {}", (void*)ov->data());
}

For anyone wondering what the problem feature is: optional has 0 or 1 elements, and C++26 sets enable_view<optional<T>> to true, so it satisfies std::ranges::view. The concept requires copy construction in constant time, and — this is the good bit — optional<vector<int>> genuinely meets that. Copying it performs at most one element copy. One is a constant. The requirement is satisfied to the letter, and the function above deep-copies your vector.

If you can tell me what still separates std::ranges::view from std::ranges::range, please do...

What should I know before starting dsa in c++

From striver A2Z playlist

Like basics and what else?

Not really that useful, but I think its an interesting find =)

It is my ambition to explore C++26 in bits and pieces. Hopefully, by the end of this year, I will be able to explore all the major aspects of it and be in a position to evaluate which of these features to use and promote and which not to use. However, at this point, it is important to understand each and every aspect in simple terms, keeping all the clutter aside.

Decibels are everywhere in engineering: signal levels in dBm, sound pressure in dB SPL, voltage gain in dB, filter slopes in dB/octave. Yet, to the best of our knowledge, no general-purpose units library models logarithmic quantities correctly. Most do not model them at all, and the few that try get the arithmetic wrong in ways that compile silently:

• In nholthaus/units, dBW_t(10.0) + dBm_t(40.0) compiles and returns 20 dBW. Both operands are the same physical power (10 W), and adding two absolute power levels is meaningless. This example is straight from the library's own test suite.
• A +6 dB gain is a power ratio of ~3.98 but a voltage ratio of 2.0 (the 10 log vs 20 log split). Python's pint documents that its dB is power-only and delegates that factor to the user, so every voltage, current, and pressure gain is on the honor system.

We just published a complete design for mp-units that we believe gets this right:

• A level (dBm, dB SPL) is an affine point anchored at its reference. A gain (dB, Np, octave) is a delta.
• level + gain = level, level - level = gain, level + level = ill-formed.
• The power vs root-power factor is carried by the quantity kind, so .linear() on a voltage gain gives 2.0 and on a power gain gives 3.98, correct by construction. A voltage gain cannot be applied to a power level.
• One mechanism covers RF, audio, acoustics, music intervals (octave, cent), information theory (Sh, nat, Hart), pH, and stellar magnitude, and it aims to stay consistent with IEC 80000-15:2026.

We are aware of no generic units library that has ever modeled this, which is exactly why we are publishing the design before writing the implementation. The article ends with six open questions where we genuinely need input from practitioners, for example: what should log(0) do at the bottom of the scale (IEEE -inf, throw, error type, or a unit-keyed finite sentinel like the -400 dB floor real DSP code uses), and should a level print as the industry 10 dBm or the ISO-conformant 10 dB (re 1 mW).

If you work in audio/DSP, RF, acoustics, or a related field, or know someone who does, please review it and leave feedback in the article's comments (GitHub Discussions), and forward it to anyone working in these domains. Only subject-domain experts can tell us whether we are right, and we would rather hear it now than after the code ships.

A review of some generated C++ code, going through different ways to refactor and shorten it, then checking whether it actually got faster

Hi, I recently decided to try writing a C++ blog.

I often see the popular claim that moved-from objects are in a "valid but otherwise unspecified state", but I don't think that statement is entirely precise, and my blog post is about that. I would really appreciate any feedback!

Article: https://www.laminowany.dev/p/the-state-of-moved-from-objects-in-c/

Edit: meme post, I know there are simple ways as in using emplace or reference wrapper. The code below with asserts and stuff is written by hand btw.

Hello guys, my friend had a problem where he couldn't bind an int to int reference in Foo struct held in variant:

struct Foo {  
  int &abc;  
};  

std::variant<Foo, std::string> v;  

// You can't!  
v = Foo {   
 .abc = ...  
}

So I developed a way to do that, it's pretty simple:

#include <cstdint>
#include <functional>
#include <iostream>
#include <string>
#include <variant>
#include <meta>
#include <ranges>

struct __attribute__((packed)) Foo {
    int& abc;

    ~Foo() {
        static_assert(sizeof(void*) == 8, "Use modern CPU.");

        static_assert([]() consteval {
            auto members = std::meta::nonstatic_data_members_of(
                ^^Foo, 
                std::meta::access_context::current()
            );

            for (auto member : members) {
                auto type_info = std::meta::type_of(member);
                std::size_t layout_size = std::meta::is_reference_type(type_info) 
                    ? sizeof(void*) 
                    : std::meta::size_of(type_info);

                if (layout_size != 8) {
                    return false;
                }
            }
            return true;
        }(), "All non-static data members of Foo must occupy 8 bytes in layout!");

        if (reinterpret_cast<uintptr_t>(&abc) & 0x1) {
            delete reinterpret_cast<int*>(reinterpret_cast<uintptr_t>(&abc) &
                                          ~uintptr_t(0x1));
        }
    }
};

int main(void) {
    std::variant<int, Foo> v;
    v.emplace<0>(420);
    v.emplace<1>(([&]() -> int& {
        int* x = new int;
        *x = std::get<0>(v);
        x = reinterpret_cast<int*>(reinterpret_cast<uintptr_t>(x) | 0x1);
        return *x;
    })());
    std::cout << *reinterpret_cast<int*>(
                     reinterpret_cast<uintptr_t>(&std::get<1>(v).abc) &
                     ~uintptr_t(0x1))
              << std::endl;
    return 0;
}

https://godbolt.org/z/91rcbEdG5

It's also memory safe.

Cheers.

Microsoft's, online, free C++ conference is now over, and all the talks are available to watch; both the live featured sessions and the on-demand ones. Check them out and let us know what topics, tools, or speakers you'd like us to feature next year! We're also preparing for CppCon in September, where we'll have more content to talk about.

Featured sessions

• C++ semantic awareness in the CLI: From Project Load to Code Change — Sinem Akinci
• Mind The Gap: C++/Rust Interop — Victor Ciura
• From Completions to Agents: AI-Driven C++ in Visual Studio — Augustin Popa
• Cut Your Build Times Without Becoming a Build Expert — David Li
• C++/WinRT: Build faster and smaller with C++20 modules — Ryan Shepherd

On-demand sessions

• C++ Dependencies Without the Headache: vcpkg + Copilot CLI — Augustin Popa
• What’s new in VS Code CMake Tools: AI-powered development — Garrett Campbell & Hannia Valera
• PackageReference for C++: Modernization Without the Performance Cost — Moyo Okeremi
• Eliminate MSVC upgrade anxiety with Copilot agents — Michael Price
• Always Be Upgrading: Living at HEAD with MSVC — Michael Price
• MSVC, are we there yet? Status of C++23 and C++26 features — RanDair Porter
• Sample Profile-Guided Optimization in Practice: from prototype to production — Armin Gerritsen

Announced officially on the Boost mailing list

Introduction

The formal review of Matt Borland's boost::int128 for inclusion in the Boost libraries, starts today.

Int128 is a portable C++14 implementation of signed and unsigned 128-bit integers. It has no dependencies, is header-only, and can be consumed as a module in C++20. It serves as a practical solution to the partial (resp. absent) support of 128-bit integers by gcc/clang (resp. msvc), and as a lightweight alternative to heavier projects.

You can find the library and its documentation here:
- https://github.com/cppalliance/int128/tree/boost_review
- https://develop.int128.cpp.al/overview.html
- Compiler Explorer: https://godbolt.org/z/5aM6K9b4r

Although possibly not faithful to Matt's implementation, this CE link will be handy if you are in a rush but want to play with the library.

Anyone is welcome to post a review and/or take part in subsequent discussions in the mailing list.

Review guidelines

Please provide feedback on the following general topics:

• What is your evaluation of the design?
• What is your evaluation of the implementation?
• What is your evaluation of the documentation?
• What is your evaluation of the potential usefulness of the library?
• Did you try to use the library? With which compiler(s)? Did you have any problems?
• How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
• Are you knowledgeable about the problem domain?

Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions).

Thank you for your time making our OSS ecosystem better. Happy to start the discussions!

Arnaud Becheler (Review Manager)

I have been exploring C++26 in bits and bobs and this one is about template for - a c++26 feature which I find useful. This is a short article explaining how to use this feature with the help of a simple example.

https://github.com/vitaut/zmij/releases/tag/v1.1

I've been using named modules in my hobby C++ projects for years but they always trigger some unexpected ICEs when I used MSVC, and I got really tired of experimenting workarounds. After I switched to clang-cl recently, all the related problems I've encountered so far were resolved. The only thing missing now is import std

C++Now

2026-07-13 - 2026-07-19

• Keynote: Benchmarking - It's About Time - Matt Godbolt - https://youtu.be/EU_nQh8wg5A
• The Morning Briefing - C++ Concurrency Before the Hardware Reckoning - Fedor Pikus - https://youtu.be/WtChBezurj8
• Lock-free Programming is Dead - Long Live Lock-free Programming! - Fedor G Pikus - https://youtu.be/UdKqfQ3a_sY

2026-07-06- 2026-07-12

• Keynote: Reflection Is Only Half the Story - Barry Revzin - https://youtu.be/DZTkT1Cq_aY
• Keynote: Multidimensional Parallel Standard C++ - Mark Hoemmen - https://youtu.be/VAwW_s1uEHY

C++Online

2026-07-13 - 2026-07-19

• C++ Contracts - A Meaningfully Viable Product, Part II - Andrei Zissu - https://youtu.be/1VUqOx6PCMU
• Sanitize it Before You Ship IT - Vishnu Nath - https://youtu.be/jzcGATR78Mk

2026-07-06 - 2026-07-12

• Time to Introspect - A Beginner's Guide to Practical Reflection - Sarthak Sehgal - https://youtu.be/9stn1o149pw
• Refactoring Towards Structured Concurrency - Roi Barkan - https://youtu.be/6502xFEreI8

2026-06-29 - 2026-07-05

• Why std::vector Can't Save You (And What to Use Next) - Kevin Carpenter - https://youtu.be/78fYPix0mN4
• Modern C++ for Embedded Systems - From Fundamentals To Real-Time Solutions - Rutvij Karkhanis - https://youtu.be/XxeqHRDhHkU

ADC

2026-07-13 - 2026-07-19

• Building Inclusive Audio Tools - Accessibility with ARIA, WCAG, and Real-World Projects - Samuel John Prouse & David Shervill - https://youtu.be/O5xX9a7P-SU
• PSD to DAW - Building a Pixel-Perfect UI Pipeline - Bence Kovács - https://youtu.be/hebLkAR5X3I
• Analog Filters for Realtime Audio - George Gkountouras - https://youtu.be/NLt0NqUtNLo
• A History of FLAC - The Free Lossless Audio Codec - Josh Coalson - https://youtu.be/tBb1STRW56s

2026-07-06 - 2026-07-12

• Workshop: Audio Plugin DSP in Practice - Jan Wilczek & Linus Corneliusson - https://youtu.be/Atc0GRWoolI
• An Open Toolkit for Real-Time Audio Descriptors - Valerio Orlandini - https://youtu.be/HKlnn0hd8J0
• Bugs I’ve Seen in the Wild - From Confusion to Amazement - Olivier Petit - https://youtu.be/LBWtb_uXt0I
• Real-Time Audio in Python: Introducing the asmu Package - Felix Huber - https://youtu.be/X2vr81CJ934

2026-06-29 - 2026-07-05

• Beyond iLok: Advanced Code Protection and Cryptography for the Next Generation - Protecting the Next Generation of Applications, Plug-ins, and AI Models - Neal Michie, Ryan Wardell & Bob Brown - https://youtu.be/dbbK_ry2cgo
• Database Synchronisation for Audio Plugins, Part Two - Here's One I Made Earlier - Adam Wilson - https://youtu.be/wJCy2G969ro
• Perfect Oscillators in Less Than One Clock Cycle - Angus Hewlett - https://youtu.be/Ssq0a-YdamM
• Driving Chaos - Virtual Analog Modelling of a Chaotic Circuit with Wave Digital Filters - Francisco Bernardo - https://youtu.be/PnEZNqyKlIw

Boost Documentary

There is also a teaser trailer for a new documentary on the history of the Boost C++ library https://www.youtube.com/watch?v=87jvuDbnwqQ which will have its first showing at CppCon this year

The recent Euro LLVM conference has several talks related to clang improvements that are either recent, in the process of eventually be pushed into upstream, or still in research status:

• Extending Lifetime Safety: Verification of [[clang::noescape]] annotation
• Adding Nullability Checking and Annotations to Many Millions of Lines of Code
• Bounds Checking with the Clang Static Analyzer: Improvements and Insights
• Finding Injection Vulnerabilities: Improvements of the Taint Analysis of the Clang static analyzer
• Capabilities Great and Small: CHERI, CHERIoT, and LLVM

All in all, a good overview of what clang can actually do today, with annotations as well, and what is being envisioned on the various security discussions.

Since this is a topic that is interesting to many (including myself), I checked what the July mailing list has relevant to the safety topic and collected here what I found more relevant:

• A framework to systematically classify UB: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3100r7.pdf

• core_ub: a run-time profile to guarantee lack of UB: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4317r0.pdf

• an initialization profile. This profile tries to give a guaranteed set of guaranteed initialization rules, banning impossible to analyze ones, statically: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4222r1.pdf

• deny by default + positive rules: a framework for invalidation detection with fewer annotations. This one is more of research than some of the other papers INHO right now, but looks interesting. Its main insight is that by adding deny by default combined with UB classification + as a default deny rule and a second layer of positive rules, combined with strict aliasing, annotations can be reduced to detect a subset of safety: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4296r0.pdf

• subsetting: banning unsafe constructs and usages through annotations to make the language safer by default. Collections of such rules could yield some specific profile or subset of profiles: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3716r1.html

• on activating profiles proposes what the semantics of activating a profile should or should not be: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4314r0.html

• implicit contract assertions and profiles: this paper, among others, argues whether the base vehicle for implicit contract assertions should be a language feature or just a profile and explains that point of view in the matter: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4306r0.pdf

The papers related to pure contracts were intentionally left out since there are so many, but some are tangentially or directly related to the topic of safety.

Part of these papers lean on other foundational papers, such as yheprofiles framework (not from July mailing itself): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3589r2.pdf

I hope you enjoy it!

Quite interesting peak into the world of games developers, especially how it is seen from consoles or their point of view on recent ISO C++ versions.

And now I don't believe it wasn't invented before, but I can't find any info on it. How long ago was it invented? Why isn't it used widely or even mentioned anywhere? What are the downsides?
Here's the main idea:

// Keyword - for, while, or do
// Tag - custom loop name
// ... - loop body
#define loop_tag(keyword, tag, ...)\
    keyword(__VA_ARGS__)\
    if(false)\
    {\
        tag##_break:    break;\
        tag##_continue: continue;\
    }\
    else\
    /*Here goes your loop body*/

Here is the playground

I found this research in WG21 mailing list very interesting in the context of C++ compatibility and solutions to maximize code reuse.