r/cpp • u/boostlibs • 1h ago

CppCon Anyone Can Contribute to Boost: Demystifying C++ Maintainership | Arnaud Becheler - CppCon 2026

Thumbnail youtu.be
• Upvotes
0 comments

r/cpp • u/misuo • 1h ago

Billion-query-per-second lookup tables in C++

Thumbnail lemire.me
• Upvotes
2 comments

r/cpp • u/benjoffe • 7h ago

A faster way to compute signed 64-bit floor division by constants

Thumbnail benjoffe.com
54 Upvotes
2 comments

r/cpp • u/ProgrammingArchive • 1d ago

New C++ Conference Videos Released This Month - October 2026 (Updated To Include Videos Released 2026-10-19 - 2026-10-25)

22 Upvotes

C++Day

2026-10-19 - 2026-10-25

C++Now

2026-10-19 - 2026-10-25

2026-10-12 - 2026-10-18

2026-10-05 - 2026-10-11

2026-09-28 - 2026-10-04

ACCU

2026-10-19 - 2026-10-25

2026-10-12 - 2026-10-18

2026-10-05 - 2026-10-11

2026-09-28 - 2026-10-04

ADC

2026-10-19 - 2026-10-25

2026-10-12 - 2026-10-18

2026-10-05 - 2026-10-11

2026-09-28 - 2026-10-04

0 comments

r/cpp • u/VinnieFalco • 1d ago

Is "Democracy" Best For A 40 Year Old Language With Over 16 Million Users?

0 Upvotes

I've been researching what "consensus" means in the C++ committee, and it seems there are two definitions that are similar, but I suspect result in different languages. In the first definition, you count hands on a poll, and if it clears the bar it moves forward. SD-4 says a proposal normally advances when more than twice as many are in favor as against:

https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures

In the second definition, the chair looks for the largest piece of the design that nobody has a sustained objection to, moves that forward, and keeps working on the rest. (Disclosure: I'm involved in some of the contracts papers).

What is different with these definitions? A poll tally picks among the designs as written, so the one with the most hands wins, even if a third of the room is strongly against it. The second definition might pick something else, which is the biggest subset everyone can live with. For example, EWG forwarded contracts (P2900) at 25/17/0/3/12. That's 42 for, 15 against, and 12 of those strongly against. Under the first reading of consensus that's a clear pass. Under the second, the question becomes what part of it those 12 could accept, and whether the rest should wait. Am I wrong that these ship different things?

The culture of WG21 for as far back as I can tell has used the first definition. A poll count determines the design. There's another word that describes this: "Democracy."

The ISO wording seems to lean toward the second definition of consensus. Clause 2.5.7 defines consensus as "general agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments."

https://www.iso.org/sites/directives/current/consolidated/

It says this "need not imply unanimity" and that sustained opposition "is not akin to a right to veto", so I don't read it as a one-person blockade. ISO's own guide for participants says "decisions within working groups are consistently reached through consensus, meaning there are no formal votes involved".

https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100037.pdf

Its convenor toolkit says the convenor "is responsible to determine when consensus is reached":

https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100416.pdf

I couldn't find a ratio for working groups anywhere in the Directives, and the 2:1 looks like a WG21 addition. Is a straw poll a "formal vote"? Maybe not, but is it consensus? Should it be?

Every ISO working group runs under that same text, so I'm curious how the other groups interpret it. I've heard secondhand that some deliberate the objections until they're resolved instead of counting. I can't verify that, and I'd love corrections from people who attend those other groups. The sibling group WG14 (C) publishes its minutes, and it uses straw polls too, so the answer clearly isn't simply "no polls". However, C does not seem to be evolving large features the way that WG21 does.

In March 2026, WG14 polled pieces of one proposal separately:

https://www.open-std.org/jtc1/sc22/WG14/www/docs/n3954.htm

A universal function pointer type got 21-2-2, the predefined macros got 6-9-6 against, and the integer typedefs got 10-2-11. That looks to me like finding the part people agree with, but I wasn't there and can't say for sure. If you're interested in the bigger picture, comparing how different ISO groups handle strong objections seems like a worthwhile research project.

Why might it matter more for C++? It's over 40 years old, and adding is easy while removing is nearly impossible. A committee paper called `vector<bool>` a mistake in 2007 and it's still there. Releases come every three years, so a deferred piece gets another shot soon, while a shipped one is permanent. The fair counterpoints are that the chair's call is hidden power, "the largest thing everyone accepts" could be watered down, and RFC7282 admits one intransigent person can "stop the process cold":

https://www.rfc-editor.org/rfc/rfc7282.html

The frequency of contested features is going up over time, as the committee grows in size and faces significant challenges such as memory safety and evolution (networking when?) In my opinion, if we use democracy to design C++, then there will be a growing divide between the winners of the vote and the losers of the vote, creating adverse social consequences.

Would it be better for the language if we prioritize general agreement over majority rule?

82 comments

r/cpp • u/tartaruga232 • 1d ago

Do not remove Contracts from C++26

Thumbnail open-std.org
80 Upvotes

Document #: P4433R0

Quotes:

It has come to our attention that during the DIS ballot, a small number of individuals have actively lobbied NBs against approving the C++26 DIS due to their own sustained opposition to contract assertions, a new language feature added in C++26. These lobbying activities have been accompanied by a public petition [Falco26] addressing NBs directly, a paper [P4334R0] that describes "fundamental flaws" in contract assertions, and other papers 2 published around the same time by the same authors or a subset thereof.

The petition [Falco26] and the papers accompanying it contain a number of claims, including that C++26 contract assertions lack genuine consensus in WG21; that the design is hasty; that technical objections were not given a proper hearing; and/or that alternative designs were not considered. These claims are not true.

In addition, the description of C++26 contract assertions given in [P4334R0] contains a number of inaccuracies. It misrepresents the specification itself, 3 the amount of wording it consists of, 4 its design intent, 5 how it relates to hardening 6 and static analysis, 7 its existing implementations, 8 existing practice, 9 teachability, 10 and proposed extensions. 11 None of the listed concerns are new; they have all been previously published by those authors (or a subset thereof), presented to WG21, and extensively discussed there. 12

Related post: https://www.reddit.com/r/cpp/comments/1xeeevt/balloting_has_completed_for_c26_unfortunately_it/

Note that I have no opinion on the topic myself. I'm just trying to understand what happened.

185 comments

r/cpp • u/trigodil • 2d ago

Pain of making a native GUI in cpp

0 Upvotes

So I just wanted to vent about the absolute pain of making a working gui in cpp, I am working on a scientific project to make an openFOAM gui and browse openFOAM code to add TENO schemes to it from scientific papers such as Fu et al and working through the binaries.

I have not used AI in this project because CFD is very delicate and quite frankly, AI is not ready for such complexity - especially numerical schemes such as TENO, I ended up writing the meshing, topological code and mathematics myself and by far, the hardest part was the gui coordinates and memory management. I wanted to PULL MY HAIR OUT because of managing segfaults, crashes because of a random pointer hidden inside a 2000 line function, I had to also manage internal functions of openfoam(and you know how that goes), boundary conditions, and mesh topology, it was driving me nuts. I generally regard myself as fluent in programming languages such as cpp, python, rust etc, but this is a whole nother of level data management.

in the end it turned out to be a pretty good contribution to the openFOAM community, hopefully the project will mature further and I will be able to write a paper on it.

46 comments

r/cpp • u/HarrierDuBoisX • 2d ago

Cpp dispatch benchmark

4 Upvotes

A few months ago, I came across this article on this subreddit:

Four Ways to Dispatch a Runtime-Selected Strategy in C++

Most articles on this topic discuss dispatching methods in isolation, focusing heavily on the implementation details of a single approach. However, I wanted to see the bigger picture—not just pitting virtual functions against switch statements, but measuring the actual performance footprint of each strategy in real-world scenarios.

This benchmark does not claim to be academic or to represent absolute truth; I was simply curious to compare fundamentally different approaches. That is why I included not only standard comparisons like virtual functions vs. CRTP, but also deeply nested virtual calls that deliberately stress the instruction cache and branch predictor.

The project is still a work in progress. Living in Ukraine, frequent power outages caused by shelling have significantly limited my available development time.

AI Disclosure: Did I use AI for this project? Yes. Benchmarks starting from #12 were suggested by an LLM, which also helped refine the AVX2 search routine and proofread my English.

You can read about Eytzinger’s binary search here: https://algorithmica.org/en/eytzinger

The benchmark results are here: https://github.com/HarrierDuBoisX/Cpp-dispatch-benchmark/blob/main/result.md

You can find the code itself here: https://github.com/HarrierDuBoisX/Cpp-dispatch-benchmark

8 comments

r/cpp • u/germandiago • 2d ago

C++ profiles for initialization and invalidation: WIP implementation prototypes already exist in GCC/Clang

Thumbnail open-std.org
17 Upvotes

In this paper it can be seen some interesting profiles progress for prototypes in Gcc and Clang.

29 comments

r/cpp • u/eisenwave • 2d ago

Balloting has completed for C++26. Unfortunately it was Disapproved

Thumbnail linkedin.com
210 Upvotes

Since the C++26 DIS has been disapproved, the next step is going to be taken in Buzios during the 2026-11 meeting. The committee will have to decide what changes to make (if any) and submit an FDIS (Final Draft of International Standard) for Balloting.

381 comments

r/cpp • u/FlyingRhenquest • 2d ago

Fun With C++26 Reflection - Building a Library for Old-Timey C

Thumbnail github.com
36 Upvotes
1 comment

r/cpp • u/_a4z • 2d ago

0x41: Intro, NB Body + DIS voting new, and the Quiz

Thumbnail youtu.be
11 Upvotes

The introduction to StockholmCpp 0x41, with a few words from our host, news from international and national C++ standardization bodies, and, of course, the quiz!

0 comments

r/cpp • u/hanickadot • 3d ago

Pre-Búzios WG21 mailing

Thumbnail open-std.org
58 Upvotes
197 comments

r/cpp • u/hrco159753 • 4d ago

Are containerized development enviroments the right way to go?

37 Upvotes

I feel like I have a pretty usual context, I have a couple of interdependent C++ projects that target various targets that primarily use cmake as their build system but various compilers. I work in a team of under 7 people and each of us has their own local machine and we also have configured a pipeline that configures/builds/tests the projects.

To minimize the differences between our local machines we reached out to providing containerized images as development environments per each target. This works ok from a reproducibility perspective however it always seems limiting and clucky to me. I'm always asking myself why wouldn't I try to use the native tooling on my machine and why wouldn't I use a package manager to provide me native tooling/dependencies?

In my mind something more similar to python's venv would be much more appropriate to encapsulate the development environment, right? I was looking for similar technologies and stumbled upon nix which has a downside of only running on unix systems(so no windows)... I'm curious how others are looking at this, because from my current perspective it seems that native environment encapsulation and sharing became too hard and containerization seems to be a sign of giving up managing our dev envs natively, am I wrong?

I still see the benefit of having containerized builds but it seems to me that the development environment should be provided by something else rather than being baked into a container image. I see containers as primarily a deployment technology and I feel that somewhere along the way we pushed it to be encapsulation of the whole development environment.

73 comments

r/cpp • u/New-Bet1597 • 4d ago

Designing a Lightweight Closure for coost: Performance, Generality, and a Few Clever Tricks

7 Upvotes

In coost, you can create coroutines using go in a way similar to Golang. The go function could initially be designed as:

cpp void go(void (*f)()); void go(void (*f)(void*), void* param);

However, this design only accepts two fixed function types and cannot support class member functions or other callable objects, making it insufficiently flexible.

If go were designed as:

cpp void go(const std::function<void()>&);

it would be more general, but constructing a std::function is relatively expensive, and its internal heap memory allocation is uncontrollable. This is unacceptable for coost, which pursues performance.

Therefore, to balance performance and usability, coost needs to implement its own closure class. In earlier versions, coost used an implementation based on virtual functions and inheritance, but it was not general enough and was limited to internal use.

Recently, I happened to have some free time. After thinking deeply about it, I redesigned the closure class. The design goals were as follows:

  1. Do not use virtual functions or inheritance;
  2. It should not be a template class;
  3. sizeof(closure) == sizeof(void*), i.e. it contains only one ordinary pointer member, making it easy to pass to the coroutine scheduler through go;
  4. Support arbitrary functions with no return value (including non-static member functions of classes), with any number of parameters;
  5. Optimize simple no-argument functions such as void f() as much as possible to avoid dynamic memory allocation.

According to goals 2, 3, and 5 above, closure can initially be designed as:

```cpp struct closure { closure(void (f)()) noexcept : _p((void)f) {}

void* _p;

}; ```

The class contains only one pointer member _p. For function pointers of type void(*)(), the pointer is stored directly in _p; for other function types with parameters, a block of memory needs to be allocated to store the function address and parameters, and _p points to that memory.

The problem is how to distinguish which of the above cases is stored in closure. Ordinary function addresses are not necessarily 4-byte or 8-byte aligned, so tagged-pointer techniques cannot be used (i.e. writing a tag into the spare low bits of a pointer).

For the second kind of function, the one with parameters, closure calls co::alloc from coost's built-in memory allocator, and small memory blocks allocated by co::alloc are always 16-byte aligned. Therefore, if _p is not 16-byte aligned, it must store an ordinary no-argument function address. But if _p is 16-byte aligned, it is still impossible to distinguish the two cases.

It seems that some unconventional trick is required to solve this problem. Based on the discussion above, _p is either an ordinary no-argument function pointer or points to a dynamically allocated block of 16-byte aligned memory. If a specific marker (for example, a uint32 integer) is written at the beginning of that dynamically allocated memory, then when _p is 16-byte aligned, we only need to read the first 4 bytes of the memory pointed to by _p to determine the type of the closure. Even if _p is an ordinary no-argument function pointer and happens to be 16-byte aligned, reading the first 4 bytes of the memory it points to should be safe.

This of course goes beyond the scope of the C++ standard. But for performance and a better user experience, coost still adopted this approach. For functions with parameters, the corresponding constructor of closure is as follows:

```cpp template<typename F, typename = std::enable_if_t< !std::is_convertible_v<std::decay_t<F>, void()()>>, typename ... A> closure(F&& f, A&& ... a) { struct S { S(F&& f, A&& ... a) : _f(std::forward<F>(f)), _a(std::forward<A>(a)...) { static_assert(offsetof(Header, magic) == 0); _header.magic = 0xdeadbeef; _header.off = offsetof(Header, fp); _header.fp = [](void* p) { S const s = (S*) ((size_t)p & ~(size_t)1); if (((size_t)p & 1) == 0) { std::apply(s->_f, s->_a); } else { s->~S(); co::free(s, sizeof(S)); } }; }

    ~S() = default;

    struct Header {
        uint32 magic;
        uint32 off;
        void (*fp)(void*);
    } _header;
    std::decay_t<F> _f;
    std::tuple<std::decay_t<A>...> _a;
};

_p = co::alloc(sizeof(S), alignof(S));
runtime_assert(_p);
new (_p) S(std::forward<F>(f), std::forward<A>(a)...);

} ```

Key points:

  • The !std::is_convertible_v in the template parameters ensures that simple lambda expressions such as [](){...} match the constructor for ordinary no-argument functions;
  • _header.magic is always set to 0xdeadbeef, which is used to distinguish the type of closure;
  • _header.fp is the type-erased function pointer, and its parameter p is the _p in closure. Here, a tagged-pointer trick is used to distinguish between "calling the function" and "destroying the closure object", thereby eliminating the need for an additional function pointer to store the destructor and saving memory.

The implementation of operator() is as follows:

cpp void operator()() { void* const p = _p; if (p) { if (((size_t)p & 15) != 0 || *(uint32*)p != 0xdeadbeef) { ((_F)p)(); } else { (*(_FP*)((char*)p + ((uint32*)p)[1]))(p); } } }

  • If _p is not 16-byte aligned, or the first 4 bytes of the memory pointed to by _p are not 0xdeadbeef, then _p is cast to an ordinary no-argument function pointer and executed directly;
  • Otherwise, the _header.fp described in the previous code is obtained according to the memory layout and executed.

An example usage of closure is as follows:

```cpp

include "co/print.h"

include "co/closure.h"

void f() { co::println("f()"); }

int main(int argc, char** argv) { co::closure c(f); c();

co::closure d([]() {
    co::println("[]() {}");
});
d();

co::closure e([](int v) {
    co::println("e called: ", v);
}, 8);
e();

return 0;

} ```

The complete code implementation can be found in co/closure.h. The code in this article is for research and reference only. Discussion is welcome.

11 comments

r/cpp • u/tjroberti • 5d ago

Revisit Safe C++

28 Upvotes

Everyone is aware of the deluge of vulnerabilities now hitting critical software. It even makes the mainstream news, so software safety is coming onto politician's radars.

If this gets worse, I think it is not inconceivable that at some point memory safe software becomes mandatory. Or at least for software that is "reachable" from the internet.

So is it time to revisit Sean Baxter's Safe C++? Start out with a safe context ("safeexpr") and expand from there, just like constexpr.

146 comments

r/cpp • u/pavel_v • 5d ago

These Bees Make the Wrong C++

Thumbnail dalerank.github.io
66 Upvotes
15 comments

r/cpp • u/pavel_v • 5d ago

CppCon Microsoft CppCon 2026 Trip Report

Thumbnail devblogs.microsoft.com
31 Upvotes
2 comments

r/cpp • u/NooneAtAll3 • 6d ago

What's the difference between cppreference .com and .net?

12 Upvotes

My duckduckgo googling started giving me both, I don't understand the difference and don't remember which one is the original

They both look exactly the same
.com has en. at the beginning
.net doesn't have accounts

.net has the picture, .com doesn't

Is it a typosquash, is one of them fake, what's going on?

12 comments

r/cpp • u/pjf_cpp • 6d ago

Valgrind 3.28 RC1

34 Upvotes

An RC1 tarball for 3.28.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.28.0.RC1.tar.bz2
https://sourceware.org/pub/valgrind/valgrind-3.28.0.RC1.tar.bz2.asc

Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

Please give it a try in configurations that are important for you and report any problems you have via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind

See the NEWS file for a list of changes and bugfixes https://sourceware.org/git/?p=valgrind.git;a=blob;f=NEWS;h=be8b91b474e71535f272e8f11f1f6d1d35826ed3;hb=HEAD

Unless showstopper bugs are found (and cannot be easily fixed) the final 3.28.0 release is scheduled for this Fri Oct 23.

Note that our mailinglists at sourceforge.net seem to currently be unavailable. Not a great time to have that problem...

3 comments

r/cpp • u/meetingcpp • 6d ago

Meeting C++ The public prerecordings for Meeting C++ 2026 are starting!

Thumbnail meetingcpp.com
17 Upvotes
2 comments

r/cpp • u/VinnieFalco • 6d ago

What is Modern C++ to you?

123 Upvotes

I keep hearing "modern C++." I've even used the term myself. And now I find I am questioning my use of the term.

  1. What does "modern C++" really mean, specifically?
  2. How many more years need to pass before it becomes just "C++?"
  3. If "modern C++" is a thing then what is the other thing. Is it "old C++," or "legacy C++?"
  4. Is C++ the only language that has a "modern" version?
  5. If the answer to 4 is yes, why is C++ unique?
153 comments

r/cpp • u/mropert • 7d ago

What makes a game tick? Part 9.5 - The Curse of the Scheduler Latency · Mathieu Ropert

Thumbnail mropert.github.io
48 Upvotes
17 comments

r/cpp • u/cristianadam • 7d ago

Qt Creator 21 - CMake Changes

32 Upvotes

Qt Creator 21 - CMake Changes

10 comments

r/cpp • u/ProgrammingArchive • 8d ago

New C++ Conference Videos Released This Month - October 2026 (Updated To Include Videos Released 2026-10-12 - 2026-10-18)

32 Upvotes

C++Now

2026-10-12 - 2026-10-18

2026-10-05 - 2026-10-11

2026-09-28 - 2026-10-04

ACCU

2026-10-12 - 2026-10-18

2026-10-05 - 2026-10-11

2026-09-28 - 2026-10-04

ADC

2026-10-12 - 2026-10-18

2026-10-05 - 2026-10-11

2026-09-28 - 2026-10-04

0 comments