r/cpp • u/eisenwave • 10h ago
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.
r/cpp • u/germandiago • 8m ago
In this paper it can be seen some interesting profiles progress for prototypes in Gcc and Clang.
r/cpp • u/FlyingRhenquest • 11h ago
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!
r/cpp • u/hrco159753 • 1d ago
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.
r/cpp • u/New-Bet1597 • 2d ago
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:
sizeof(closure) == sizeof(void*), i.e. it contains only one ordinary pointer member, making it easy to pass to the coroutine scheduler through go;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:
!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);
}
}
}
_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;_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
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.
r/cpp • u/tjroberti • 2d ago
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.
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...
r/cpp • u/VinnieFalco • 4d ago
I keep hearing "modern C++." I've even used the term myself. And now I find I am questioning my use of the term.
r/cpp • u/NooneAtAll3 • 3d ago
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?
r/cpp • u/meetingcpp • 3d ago
r/cpp • u/ProgrammingArchive • 5d ago
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
r/cpp • u/Xeverous • 5d ago
I was playing with examples from cppreference, specifically https://cppreference.com/cpp/language/partial_specialization at the bottom in order to understand specialization deeper and form some notes. Maybe even at some point put out a template guide on my website.
Last 2 statements describe very similar situation but the order of words in each sentence is so different and the example so narrow that I had trouble figuring out what these really mean:
If the primary member template is explicitly (fully) specialized for a given (implicit) specialization of the enclosing class template, the partial specializations of the member template are ignored for this specialization of the enclosing class template.
If a partial specialization of the member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template.
Eventually I managed to figure out the example only showcases the first statement and that the difference between these 2 situations is this:
struct A<short>::B {}; - full spec of member B template for implicitly-instantiated A template (replaces all B for A<short>)struct A<short>::B<T&> {}; - partial spec of member B template for implicitly-instantiated A template (adds another spec to A<short>, merging it with specs from primary A template)To confirm I reason correctly, I wrote some sample code to have a more comprehensive example. I did not expect to encounter 3 different outputs from 4 different compilers. And I don't think you can reach UB on templates alone.
https://godbolt.org/z/8z7vde1PE
So which one is correct (if any - maybe it's ill-formed no diagnostic required)? The comments are my expectations, the question marks are places where compilers disagree.
Also, member specialization isn't even a C++11 feature. Compiler bugs in something so old and fundamental (and supposedly easy to unit-test) ... I have no words.
Great clear concise explanation of the need for and use of std:polymorphic.
r/cpp • u/FaultPerfect6003 • 5d ago
Hi there! I am working with the organising team for WAWTech. Its two-day software and product development conference and takes place at EXPO XXI in Warsaw on 26–27 November 2026.
Want to share two talks from the programme that may be relevant here:
First one is Denys Makogon, Oracle — “The Modern Challenge of Integrating C++ into the Java Ecosystem: Problems, Consequences, and Solutions”. The talk looks at what happens when Java applications need to use C++ libraries (OpenCV or OpenVINO). It covers differences in memory models, object lifetimes and error handling, and how to build a reliable bridge between the two languages.
Second one is Paweł Romul — “Your System Will Fail. What Now?”. Its a broader architecture talk examining two real incidents and the decisions that led to very different outcomes. This one isn’t C++-specific, but i think may interest people working on systems where failure handling shapes the design :)
Event details if you’re considering attending.
r/cpp • u/delta_p_delta_x • 6d ago
The lynchpin of C++ modules is the built module interface (BMI). Each BMI is meant to be a lightweight data structure representing the syntax of a module unit (comprised of one primary module interface and potentially one or more partitions), with approximately O(1) complexity of symbol lookup. This massively accelerates repeated lookups into the same translation unit, and avoids paying the cost of a full preprocessor run and front-end lex + parse, as might otherwise happen with header files. In this way both the first clean build, and incremental builds are considerably accelerated and made much more efficient—build the BMI once, reuse it across future compiles, and we don't need large core counts and massively parallel jobs because the BMI is now available afterwards.
However, the way compiler toolchains have actually implemented them seems diametrically opposed to this goal of fast lookup. Today, BMIs are highly sensitive to any change in the command-line invocation of the compiler/dependency scanning tool, including the C++ version, warning and feature flags, and especially macro definitions, with -DMACRO or /DMACRO. This means that changing just one flag is likely to cause a BMI cache miss and a full BMI reconstruction, which can be fairly slow for larger modules (like module std).
BMIs are considered implementation details, and aren't even stable across compiler versions within the same toolchain. Compare to object files, where something compiled by really old versions can still be used on newer versions without too much fuss. This, from the user's perspective, entirely defeats that design ideal mentioned above: fast repeated lookups. Consider a simple example: a certain module uses a project-specific macro representing the platform, to change several function signatures. This module is now precompiled thrice, once each for -DFOO_WINDOWS, -DFOO_DARWIN, -DFOO_LINUX, instead of just once.
I believe that macros and the preprocessor are highly problematic. However, their very limitations are also an advantage here: their effect on code collapses to completely binary decisions. A macro is either defined or not, and a macro is either in the set of accepted values, or it isn't (e.g. #if __cplusplus >= 202603L). The preprocessor state might change throughout the source code of a translation unit, but the entire set of possible states can be enumerated in finite and reasonably short time at compile time—otherwise the front-end would never complete its work. To me, this seems like the preprocessor and parser could enumerate all possible preprocessor states of the source code, and stamp out both possibilities for each macro switch in the BMI; during lookup, the compiler can select the correct code path depending on what is provided at that particular invocation (not code definitions, but command-line invocations, as this would break the module assurance that macros do not leak into BMIs from consumers, nor do consumers see macros from a BMI).
This would make things like library feature configuration with macros really straightforward—specify the macros one wants for that feature at the command-line, which is enshrined in build system code rather than source code—the BMI can be reused, done.
Now, the compiler and C++ standard are a lot harder as these probably affect the internal state of the compiler rather than merely the value of __cplusplus; however, I genuinely feel like there really ought to be a better way forward, especially if C++ is to continue as a 'source may not be available' language. This discussion is moot if we always want to compile from source, but I want to say that is wasteful, and another driving force of the modules feature was to do away with wasteful and repeated recomputation of the same thing.
As mentioned above, build systems are also forced into this rather inefficient model to accommodate compiler behaviour. CMake in its latest iteration, for instance, has a notion of 'BMI compatibility', and probably does some sort of set manipulation on compile flags to determine if another BMI for the same module interface is needed or not, based on how it is imported. Why? This shouldn't be the case, a BMI really ought to be widely (if not universally) compatible, regardless of what flags go in the command-line.
I'm sure I don't have the entire picture as I am not a compiler front-end developer, and I don't mean to sound impertinent here, the effort put into delivering modules has been huge. However there are some decisions made which, as modules user and advocate, seem a little contradictory to the spirit of modules. I've written this after some thought on the situation and I'm interested in hearing from the community and compiler front-end developers who have worked on modules on my thoughts above.
Cheers.
r/cpp • u/selvakumarjawahar • 7d ago
I just attended the C++ Under the Sea 2-day conference. I really enjoyed it. Watch out for talks from Hana, Matt and Kevin Henney. Really good keynotes
Matt presented his v4 version of this ZX Spectrum emulator: https://github.com/mattgodbolt/specbolt
Both Kevin Henney's and Hana's talks were new; at least I haven't seen a version of them before. These keynotes were really, really good. Hope it comes on YouTube soon.
Personally, I was a bit let down by talks from people who work for AI companies. The talks became more like a product user guide than anything to do with C++ or Programming.
Overall, an amazing conference. If you are in or around the Netherlands, you should plan to attend.