Why is `import std` still experimental ??? Hey guys, I recently started going through *Professional C++ (6th Edition)*. The book teaches C++23, and in the very first chapter we're introduced to modules. I'm not a complete newbie to C++, but I'm also definitely not very confident in my knowledge yet. I wanted to get this simple example compiled: import std; int main() { std::println("Hello World"); return 0; } And gosh, it took **way longer than I expected**. First, I tried getting it to work natively on my Mac and eventually gave up (both Claude and I 😅). Then I installed Ubuntu ARM 26 and finally managed to get it compiling. But now Clang/IntelliSense is complaining about the \`import std\` This is what my `CMakeLists.txt` currently looks like: cmake_minimum_required(VERSION 4.0) # set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD ON) set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "d0edc3af-4c50-42ea-a356-e2862fe7a444") project(CppProject LANGUAGES CXX) set(CMAKE_CXX_STANDARD 26) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_EXPORT_COMPILE_COMMANDS ON) add_executable(exec main.cpp) set_property(TARGET exec PROPERTY CXX_MODULE_STD ON) The code **does compile successfully**, but CMake still gives me a warning that `import std` support is experimental. So I'm genuinely curious: **Why is** `import std` **still considered experimental?** I understand that C++ modules themselves have been around for a while, but `import std` feels like something that should be much more straightforward by now. Is there any solution of this now ?

People say C++ is hard to learn. No. C++ is easy to start. It's knowing what the compiler is actually doing that gets hard.

RT @straceX: People say C++ is hard to learn. No. C++ is easy to start. It's knowing what the compiler is actually doing that gets hard.

What if your C++ code could ask: “Are you a number?” “Are you a floating-point type?” “Can this conversion narrow?” That's the power of C++20 Concepts. Bjarne Stroustrup breaks it down in this short from Using std::cpp 2026. ▶️youtube.com/shorts/n3hjnZP… #CPP #Cpp20 #Programming

You’re a nerd if these weird letters make sense to you c cc gcc cxx clang cpp c++ cmake msvc

About char8_t I hate to be dramatic, but as it stands char8_t is quite literally more painful than useful. Besides the obvious incompatibility with C23 and libraries using unsigned char for UTF-8, I want you to consider the following: Projects that assume that 'char' represents UTF-8 will obviously not benefit from char8_t at all, but projects that cannot assume the format of char types don't benefit from it either as char8_t simply introduces a new edge case to cover. Now such projects have to deal with char, signed char, unsigned char, wchar_t, char16_t, char32_t and char8_t. Or, you could do what the standard library does and simply ignore most of these character types. Which is the solution most libraries went with, supporting only char or char and unsigned char. Managing one implementation is already hard, managing two requires constant maintenance, managing 7 is just impossible. char8_t should have just been a typedef for unsigned char. The [compatibility fix](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2513r4.html) only raises more questions as `const char* arr = u8"a"` does not work, but `const char arr[] = u8"a"` does. I do wonder if a potential change of minds for C++29 is still possible. Yes, it would be an ABI break or whatever, but considering the woeful support for char8_t I don't think it would affect much besides small hobby projects. Contrary to popular belief, C++ has broken the ABI in subtle ways before.

Compile-Time Improvements in LLVM 23

C++ has a type system so powerful that you can write code where the compiler knows exactly what you meant. Unfortunately, you might not. https://t.co/XM4sbefMkf

C++ puzzle of the week. What's the result of compiling and running this piece of code? https://t.co/cnva7zRYie

C++20 Concepts let you ask questions about types at compile time. In this highlight from Using std::cpp 2026, Bjarne Stroustrup explains concepts, arithmetic types, and how C++ can detect narrowing conversions. 🎥 youtube.com/shorts/n3hjnZP… #CPP #ModernCpp #Cpp20

C++23 https://t.co/LRnCuX5Zo3

C++26 Contracts: What Do They Add Beyond Manual Checks and Assertions? This post is a part of my C++26 exploration series where I take a new feature and try to understand and explain with a simple example in hand. Today’s topic is Contracts. First we will simply try to understand what is the problem it is solving then try doing some assessment on the value addition.

First, you work for C++ Then C++ works for you. https://t.co/Ok9DFdUTwU

Reducing C++ template bloat by factoring out the type-dependent portions of the function

Why do people try to add even more features to STL? It is well known that STL underperforms compared to specialised third party libraries, why do people try to stuff features like networking and json into STL? Most STL implementations don't even have full C++23 coverage yet, and we are at 2026. Why do these people try to do stuff like that, when the same thing will play out over and over. Don't they have anything better to do? Examples include, nlohmann json, graph.v3 .... They don't really belong in STL, is it really that hard to just package your third party lib normally? There is no doubt they are great libraries(graph.v3 in particular) but this doesn't mandate their place

Compile-Time Borrow Checker with Stateful Metaprogramming

C++ developers will tell you RAII solved resource management. then you open a serious C++ codebase and find: https://t.co/mp2eybFurf

How to write the perfect function

I wrote some C++ today. It was a good day.

RT @straceX: C++ has std::move. which doesn't actually move anything. great language.

The C++ input iterator pitfall · hmpc

You need a Voronoi diagram from a million points, or you need to clip, union, and difference polygons for a PCB layout tool Standard C++ has nothing. CGAL is 40 MB. You just want the geometry operations 🧵👇

AI-generated C++ passes tests. It also uses nearly 2x the loops and drives up memory growth AI-coding tools have swept through organizations because of their speed: you type in a prompt, and it spits out code far faster than a human ever could. However, a year-long study of 3.52 million changes inside a large unnamed technology company suggests that saving time at the keyboard can create costs elsewhere.

C++ has std::move. which doesn't actually move anything. great language.

More fuel to AI discussion. An article on code bloat and duplication I think code duplication is honestly the only reason LLMs manage any of this. Idea, architecture, implementation -- that's basically the chain, and LLMs are fine at the first and last, it's the middle that falls apart. Get it to actually structure things, kill the duplication and something you changed in one spot breaks another spot that has nothing to do with it. Duplicated code just sidesteps the whole issue, because then it only needs a tiny bit of local context to make a local edit

POV: When you can’t fix a segfault in C++ code https://t.co/AhpxHIlpC3

You should use any unfair advantage life gives you. My unfair advantage is that I can watch the best C++ course available only in my native language.

C++26: std::polymorphic

Critique of contracts: excerpt See page 2 of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4334r0.pdf > The current objections can be summarized. The P2900 contracts are: > • Unimplemented > • Incomplete > • Untried at scale [P3460R0, P3506R0] > • Not tried in major application domains > • Violates foundational principles of C++ > • Violates fundamental principles of language design > • Hasn’t been tried in major libraries (e.g., the C++ standards library [P3506R0, P3878R0]) > • Isn’t integrated with or appropriate for hardened libraries [P3878R0] > • Doesn’t offer safety guarantees [P3573R0, P3362R0] > • Includes a completely untried inheritance model > • Offer new ways of making errors through inconsistent application in TUs > • Leads to new forms of UB, detrimental to safety and security > • Narrows the choices of error handling > • Doesn’t protect against logical errors, misuses, and incoherent uses > • Hasn’t been used to support static analysis > • Hasn’t been demonstrated to be easily teachable [P3261R0, P3281R0] > How could such a bloated and incomplete design be voted into a draft standard?

Incredible things are happening in the C++ community https://t.co/kutgX5xcyB

RT @CPPAlliance: C++17 gave us parallel algorithms: std::sort(std::execution::par, v.begin(), v.end()) C++20 gave us ranges: std::ranges::…

RT @straceX: Modern C++ is at its best when you can forget you're writing C++. RAII, strong types, ranges, standard containers. The langu…

A complete floating-point to_chars in 18 kB

Everyone is panicking about AI alignment. Meanwhile, C++ has had std::hardware_destructive_interference_size and std::hardware_constructive_interference_size forever. Checkmate, doomers.

Modern C++ is at its best when you can forget you're writing C++. RAII, strong types, ranges, standard containers. The language gets interesting when it removes problems instead of adding cleverness.

P4444: std::big_int Hey folks! Matt Borland, Christopher Kormanyos, and I are working on bringing infinite-precision integers to C++29. We now have a D4444R0 draft of a paper that should be in the next mailing. We could really use some feedback so that the published R0 is as polished as possible. Any thoughts on the paper and on the [reference implementation](https://github.com/eisenwave/std-big-int/) are greatly appreciated. It would also be very helpful if you tested out whether our `big_int` implementation works for you. We're in need of some real deployment experience. If you're currently using Boost.Multiprecision, the library should be a drop-in replacement for `cpp_int` for the most part.

Show HN: Openleetcode – Local LeetCode runner where tests live in the repo

Suppose that you want to write a C++ that prints a series of values, but also their type. E.g., given print_all(1.2, "abc", 3, std::vector ({2,3})); You want... double = 1.2 const char* = abc int = 3 std::vector = [2, 3] You can do it in C++26 with little code. 1. Use 'template for' to do a compile-time iteration. 2. Call display_string_of on the reflection of the types. (Don't forget the rabbit ears ^^)

C++ has enough features to let you solve the same problem five different ways. that’s useful. It’s also why code review matters so much more in C++.

I’ve been playing a guitar for 18 years and I barely can play a single Metallica song. After 1 year of C++, I’m already an expert. I’ll stick to programming.

std::transform and other standard algorithms need a range of same type elements, so they can't work on a std::tuple C++26 adds reflection and template for, which let you loop over a struct's fields, but there's still no built in way to transform, filter, or combine them 🧵👇

Break MSVC and Clang with this one weird trick! - Braden Ganetsky

C++26 Reflection Annotations: Automated Member Validation C++26 annotations are another powerful feature that, when combined with reflection, can help us write cleaner and safer code without repeating manual validation checks for every member. In this post, I have explored how we can utilise C++26 annotations along with reflection to validate configuration parameters in a class constructor.

Faster algorithms to compute weekday for date libraries

The Two Factions of C++ (2024)

The WG21 2026-08 mailing is now available The 2026-08 WG21 mailing has been published. You can browse and search the full set of papers, organized by working group, at [wg21.org](http://wg21.org): [https://wg21.org/mailing/2026-08/](https://wg21.org/mailing/2026-08/) Source mailing: [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/#mailing2026-08](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/#mailing2026-08)

Best C++ advice

I just discovered, there’s a 2nd playlist with Advanced C++ https://t.co/w2hpbl66iI

C++26: std::indirect

Every time I commute or eat, I don't watch Netflix. I watch C++ lectures. It's only 20 minutes a day. But after 6 months, I finished watching 38+ hours of C++ content. https://t.co/SXk8TzxJA3

You need to strip every #ifdef _WIN32 block from a codebase, expand macros to audit what the compiler actually sees, or build a source-to-source transform Standard C++ has no API for its own preprocessor 🧵👇

Boost 1.92.0 released Boost 1.92.0 is out. Highlights from this release: **GPU / CUDA** * Charconv: `to_chars` and `from_chars` for integers are now usable inside CUDA kernels. * Decimal: `decimal32_t`, `decimal64_t`, and `decimal128_t` are now usable in CUDA kernels. * Math: fixed CUDA compilation where host functions were incorrectly marked as device. **Networking hardening** * Beast: stricter HTTP parsing. It now rejects `Content-Length` combined with `Transfer-Encoding` regardless of field order, rejects chunked encoding in HTTP/1.0 requests, validates quoted strings in chunk extensions, and drops framing and connection fields carried in trailers. The dependency on Boost.Functional was also removed. * URL: third round security review fixes, including a heap buffer overflow in `normalize_path` for authority-less URLs and an uninitialized read in `ipv6_address_rule`. **Containers and data structures** * Container: new `hub` container designed by Joaquín M. López Muñoz. Also adds `unchecked_emplace_back` and `unchecked_push_back` to `vector`, `static_vector`, and `small_vector`. * Lockfree: two new queues, `mpsc_weak_queue` (MPSC) and `bounded_ticket_queue` (ringbuffer based bounded MPMC). Both have explicit progress caveats: neither is strictly lock free under all configurations. * Unordered: C++20 ranges interop across all containers (`insert_range`, `std::from_range` construction, and associated CTAD). * Graph: Louvain community detection for modularity based clustering. * Hash2: built in support for `std::optional`, `std::variant`, and `std::monostate`. **C++20 modules** * New module support in Conversion, DLL, LexicalCast, PFR, Stacktrace, and TypeIndex. **Build system** * Windows `.dll` files now install into the binary directory by default (previously the library directory, except on Cygwin). A new `--dlldir` option overrides this. * The CMake config installed by `b2 install` now supports header only libraries as `find_package` components, so `find_package(Boost REQUIRED COMPONENTS mp11)` works and defines `Boost::mp11`. **Deprecations and breaking changes** * Heap and Lockfree: this is the last release to support C++14. Future releases require C++17. * MSM (backmp11) has several breaking changes, notably that events in `process_event` are no longer enqueued automatically. Use `enqueue_event` in actions instead. Full notes and downloads: [https://www.boost.org/releases/1.92.0/](https://www.boost.org/releases/1.92.0/)

[CPP Epiphany Rant] - Programming is no joke Hi CPP Community, This is just a rant. I'm a 24 yr old data analytics in telecommunication trying to pivot into C++ development for finance. I'm 1 month into C++ and I have come to conclusion C++ is a behemoth. I'm enrolled in Baruch College's C++ for Financial Engineering, but I'm using Bjarne Stroustrup's Programming: Principles and Practice Using C++, 3rd Edition to learn and watching C++20 Fundamentals with Paul Deitel, Course, by Paul J. Deitel as supplementary resources. It took me 2 days to get through all the drills, exercises, and try\_this section for chapter 2 for Programming Principles! I'm reflecting if I made a mistake choosing C++ over Python. But, tbh, I have been enjoying programming more learning C++ than Python. You can tell I'm weird, but IDK. I would love to heard about your experience in learning C++ for laughs.

Most C++ zero-cost abstractions are only zero-cost if you have an omniscient compiler, an infinite instruction cache, and never actually need to step through a debugger in your life.

From Self Taught to Committee Member’s First Accepted Paper - Waffl3x CppCast 410 / C++Weekly 545 youtu.be/4jx7ZsRh6dc https://t.co/8fsazcQPbx

Understanding std::counting_semaphore and std::binary_semaphore from C++20 An article on types introduced in C++20.

A failure to separate concerns I've been taking a look at an extremely popular, 50K+ stars, C++ library which I won't name as I'm going to criticise it as an example of a wider problem. This is going to be a rant and there may even be sarcasm. Feel free to skip it if that upsets you. This library is sponsored by a long list of companies. It's incredibly widely used. It has 100% test coverage, builds with several different build systems, works on several platform, complies with all the standards, linters and clang-tidy you can imagine. It's clearly aiming to be part of the future C++ standard and it might even make it. In short it's brilliantly written with a massive amount of effort put into it. One of the highest quality C++ libraries out there, that isn't actually part of Boost or the standard itself. In terms of how robust, well tested and well supported it is. So what's the problem? This library has one job, to deal with a particular text format. To parse that data into useful objects and transform those objects back into text. That's it, that's all anyone will ever use it for and if it does that it achieves 100% of its design goals. The 'useful objects' part of that sentence is doing some heavy lifting here as what is a useful object to one client might not be to another. So some flexibility in what objects are generated and what access methods they have is a reasonable extension point. In such a library we'd expect to find a parser to get us from text to in memory objects. A generator to get from the in memory objects back to a text representation. We might also expect some Unicode adaptation to deal with what a 'text representation' means. All these things are indeed present, although barely distinguishable from the vast sea of code in which they sit. I think we get 5 parsers for different dialects of the format. It's completely unclear how much code they share or if jamming them into one library is even a good idea. I literally can't find the generator so I don't know whether we get 1 or 5, or if it's possible to choose which dialect is output. Seems like basic stuff but why do basic stuff when there is so much more complicated stuff to do. There are custom data structures. Useful but clearly belonging in their own library. An internal binary representation type, exposed at the root of the include directory as if this was something you'd want to include. Custom string concatenation because clearly concatenating strings is not a solved problem. Code for integrating with Google libraries because that apparently belongs here. Pre-processor macro blocks across hundreds of files for dealing with at least 4 different variants of C++. No physical separation of the C++20 code I can use from the no longer needed C++11, 14 & 17 code work arounds so I can ditch the dead code that isn't going in the binary anyway but remains all over my screen. No way to exclude experimental C++23 code except to find the right macro to nobble and the blocks of greyed out code that my compiler can't even read, remain in my way. Of course this library does it's own compiler detection, poorly, and uses custom pre-processor macros, spread through the whole codebase, to determine if a long list of features are switched on or off. Some of these are probably options I could set at compile time. Some are there to cope with old Clang versions that no one uses anymore. There's no list to say which is which, or which combinations of switches actually work. I expect massive effort has gone into testing thousands of combinations, that almost no one will ever know they are, or are not, using. There's custom hashing because every library needs its own copy of a hashing algorithm, just in case the one they copied it from breaks I suppose. Lots of custom exception classes, even though exceptions are apparently optional, so you'd think they might only be optionally in the project. There are macros for the namespaces. Why not, it's got every chance of working if you turn those off, lol, No. std::filesystem is apparently either experimental or in some way optional and there's a separate macro to turn I/O support on and off. No explanation as to why there's any file I/O at all in a library to transform text to objects and back again. I happen to like to use async I/O so I guess I'd build with I/O support off and then hack in my own. No thanks. Everything is of course wrapped in a massive amount of template meta programming so that almost nothing in this header only library exists as a concrete type, until you instantiate it in your code. You literally can't definitively reason about the code without first writing something that uses it. Yet despite this apparently total flexibility it manages to bake in a whole set of assumptions I don't want. std::allocator use is mandatory despite there being no reason, in principle, why this library should even do memory allocation. Why not externalise it and make it somebody else's problem? There are only the known container types from the standard library. If you want to parse the data into any of those you're golden but anything else, like the very same custom ordered map type that the library itself relies on, and you're overloading meta templates until the middle of next week. Did I mention that this entire mess is header only. Easy to include and all that. This also means of course that every type, every constant, every function, every template and every macro from these many, many thousands of lines of code ends up in every TU where you include the header. Including all the compiler mitigation macros that are never going to clash with the ones in that other library you want to use. That sort of thing has never been known to cause any issues or slow down builds or anything like that. It's quietly admitted in the comments that it shouldn't be header only. Warnings have to be supressed to get away with being so. It doesn't need to be header only of course to have a single inclusion header in order to be 'easy to use'. They are NOT the same thing but why build your own binary when you can bloat thousands of others instead, right. In summary there are thousands of lines of code in this library that don't belong here. This code, that does every job other than parse the target text format and regenerate it from in memory objects, should be in dependent libraries or just shouldn't exist. There are no dependent libraries of course because it's header only. This saves a single addition to the link line in clients while injecting many thousands of lines into every TU where one type from this library is needed. Thousands of lines that get parsed, generated and then mostly thrown away on every build. The author, who clearly has brain power going spare, has made their job orders of magnitude more difficult than it needs to be by putting everything in their library on the actual API and having to support a lot more code than they need to. A ::detail namespace has never stopped anyone before and putting almost everything in it anyway is just a sign you've got too many details. They've also made testing vastly more complex and support probably a full time job. Fine if you're being sponsored I suppose. I know a little about writing large projects that do many things. This is not one of those. This is a single purpose library that aims to do one thing and do it well. Noble goals. It succeeds at the later while being an unmitigated disaster at the former. The absolute failure to separate concerns is not a flaw in any way specific to this library though. It's almost completely ubiquitous. Pick any top rated C++ library you like on GitHub from HTTP Servers to graphics libraries and try assessing how much of it is actually doing what the library is about and how much is not. What assumptions about types and memory handling it's baking into the API and, crucially, the implementation. I will repeat at this point for both irony and emphasis that this is an absolutely top quality library, written by someone far cleverer than me, that passes every metric our industry has. It is lauded as a great thing and used by thousands of other projects. Projects which are wasting hundreds of trillions of CPU cycles building code that probably isn't what they think it is, because they've no idea which bits are turned on or turned off in their build. Much of it isn't needed anyway and it's so complex that it's not worth anyone's time to ask difficult questions. For a trivial use case this approach presents essentially no issues but really, is your use case trivial? I hope not. I expect your use case is pretty serious. You're building something larger and more important than a simple tool to read and write files in a particular format. I'm looking at this library for potential integration into a larger project. It's the industry standard and it's simply unusable. This is apparently not only the best we can do but what's much, much worse, the best we expect to do. Houston we have a problem...

🎬 BOOST.DOCUMENTARY TEASER TRAILER IS NOW LIVE In 1998, a small group of programmers started a project that would help shape modern C++. Now, hear the story behind the Boost C++ Libraries — the people, debates, friendships, and ideas behind the code. 🎥 Watch the trailer: youtu.be/myQRC4f9jTE #Boost #CPP #OpenSource

Proof that C and C++ are different languages: https://t.co/lIlpLIhCmi

Bjarne Stroustrup, creator of C++, joins Susquehanna

C++ is the only language where "delete this;" is perfectly valid code. And yes, this actually works. https://t.co/g3r8Tctkef

I'm pleasantly surprised that tech and C++ content manage to get so much engagement. If you continue supporting this style of content, I might actually start posting more useful C++ and DSA tips more often. Hard to believe, but I might even start putting some effort into it.

The things people do to avoid writing C++

GCC 16.2.0 Released I'm pretty excited about this maintenance release. I think this will be the first version of gcc which can compile my project.

Let me sum up where I think we are on jobs and AI. 1. AI is capital. Like trade, capital substitutes for labor. Historically it destroys some jobs and creates others. 2. There is still no clear evidence that AI is causing net job losses. Look at the aggregate data. No strong signal yet. 3. There is no evidence of an intelligence explosion that renders human beings obsolete. None. Yes, AI can write C++26 faster than I ever could and prove theorems better than I can. Sympy already does algebra faster and more accurately than any human. My car moves faster than I ever could without a motor. None of this makes people obsolete. 4. There is evidence that AI is making us slightly richer. It acts like other capital investments: it raises productivity. That is good. 5. AI is a breakthrough technology that will require us to reshape institutions. Simply bolting it onto existing processes produces only small gains. The real payoff comes when we redesign processes from the ground up. We should expect larger gains later, even if the underlying models stagnate. 6. Globalization made the West richer overall, but at the expense of parts of the working class. Those workers stayed financially viable largely through increased government transfers. Over the longer term the arrangement mostly benefited China while we deskilled our own population. 7. There will be disruptions. Some people in the laptop class will be displaced. We have no reason to expect a job apocalypse; that claim is pure speculation. A healthy society tolerates a fair amount of creative destruction. 8. Handouts are a poor solution. We should not have relied on them for the working class, and doing the same today for financial advisors or translators is bad policy. We need to favor and protect activities that give people real autonomy and skills. The West lost ground to China during globalization because it decided that where things are made does not matter. It does. The West should have invested far more in capital. Canada is the poster child of the opposite choice: decades of trade focus with little capital formation. What we should do in the AI era is the same thing we should have done for the last few decades. Encourage entrepreneurs. Ensure cheap and abundant power. Make AI itself cheap and abundant. People in the West do not need more university degrees. They need more entrepreneurial spirit. We need to value actual skills. We need to put builders and entrepreneurs at the top of our hierarchy. Look at the historical evidence, though its current ideological fixations are hurtful Germany treated manufacturing as a core competence rather than something to offload, and they did better than most in the 1990s when China came in. Switzerland and the Netherlands focused on high-value manufacturing and did well. As AI comes in, we must not make the mistake to stop working. « Well, it is over, AI is replacing us but that's ok because we have money » is just like « Well, it is over, China is replacing us but that's ok because we have money ». The lesson should be that money is not our primary concern. Making stuff people want is. To help the people who will unavoidably be displaced in the next 10 to 20 years, we should encourage growth. Cheap electricity. More data centers. More innovation. Don't be fooled and let China win the second round once more.

static_cast<int>(4294967295.0) is undefined behavior. static_cast<short>(40000) silently wraps. Standard C++ gives you zero protection when converting between numeric types Every cast is a silent data bomb 🧵👇

C++26: #embed

Boost.Int128 has been accepted Boost.Int128 from Matt Borland has been accepted into Boost. Arnaud Becheler managed the review. * [Announcement](https://lists.boost.org/archives/list/boost@lists.boost.org/thread/MVOZZ7WKF5Q5BWI6LDMY4RMAABOZ6KCD/) * [Repo](https://github.com/cppalliance/int128) * [Docs](https://develop.int128.cpp.al/overview.html)

C++ has templates C++ has RAII C++ has the STL C++ has amazing optimisations C++ has memory layout control C++ has allocators Rust has borrow checker Rust has traits Rust has Cargo Rust has ADTs Rust has pattern matching C has?

C++20 coroutines are stackless. They can only suspend from the coroutine function itself, never from a nested call. If your generator calls a helper that needs to yield, you’re out of luck Stackful coroutines do not have this limitation 🧵👇

C++26 Reflection: Simplifying JSON Serialization I have been exploring the new additions in C++26, and I have been discussing the reflection feature that has come with **C++26**. In the last post, I discussed **what is reflection and how to use it** and how to use it with a simple example, particularly with an enum class. Since then, there have been suggestions to provide an example which is more than a toy :). In this post, I have discussed how to use reflection for JSON serialization, which is something we often have to do. This example is somewhat taken from real-world code but has been stripped down significantly. Suggestions are always welcome.

Faster Than Ninja

Parsing a CSV line correctly in standard C++ means handling quoted fields, escaped quotes inside quotes, empty fields, and different delimiters That’s 47 lines of fragile loop and state machine code for one row of data 🧵👇

There is a C++ news aggregator by @mariusbancila Note: Currently the top article on the aggregator is how to migrate to Rust. cppdashboard.dev https://t.co/Nhx1FY9qEA

Common Problems I see with Public Libraries Build Scripts Hi, I'm an early user of Common Package Specification and C++ modules. I package and port libraries for my own use frequently. I want to talk about issues I see constantly. \- Having specific options for sanitizers, exceptions etc, this is a toolchain problem, if I wanna build your library with sanitizers I can just add the flags to my cmake toolchain file same as allocators. \- Not separating build options to a separate file, meson already does this, it ain't that hard to do in cmake, just cache variables in a separate file at project dir which you include before subdirs \- Making tests separate cmake projects rather than just executables, just why? \- Vendoring dependencies, copy pasting files from other projects rather than just consuming these external libs via packages. \- Using unnecessary helper functions that really makes the cmake script unreadable. Build scripts don't need to be over engineered, they are just basic scripts in which you define very basic information. I could go on but I'm tired.

C++ is the only language where your friends can access your private members.

std::invoke_result tells you what comes back when you invoke a callable with a particular set of arguments. That's it Want the callable's parameter types? The arity? Whether it is noexcept? Whether it is a member function pointer? Standard C++ says write your own template specializations 🧵👇

How fast is C++26's std::hive?

The gist of my findings is that if you find yourself needing a std::list in C++, then std::hive might be for you. It is quite reasonable in this respect. You probably never want to replace an std::vector by an std::hive.

Thoroughly Understanding C++ ABI (2024)

"We don't need pattern matching in C++, we have pattern matching at home." Pattern matching at home: https://t.co/XSjPuKBnIU

C++ devs when they finally can write []{} instead of [](){} https://t.co/HHdp35QWPp

"C++ Ranges change everything." Hear Bjarne Stroustrup explain as part of his keynote at Using std::cpp 2026 why modern C++ is becoming more expressive, readable, and powerful than ever. 🎥 Watch the short: youtube.com/shorts/OzVMlfT… #cpp #cplusplus #programming #cpp20

C++ leaves it to you too because the one we standardized was over specified and thus has horrible contemporary performance.

std::hive is my new favourite data structure in C++26. Aka a linked list of fixed-size arrays. It provides better cache locality than std::list but faster insert and erase than std::vector. https://t.co/WSoZdCg64F

Why we write our own C and C++ inference engines

C++ float-to-int conversion can be undefined behavior

I teach programming. And I NEVER feed raw AI output to people. I needed to write a C++ chapter. So I asked Claude Code to generate the content. And then I rewrote EVERY SINGLE CHARACTER. Somehow this was easier than writing from scratch. I’m a refactor guy.

This is gonna make Rust programmers angry. Reflection is one of the most powerful concepts in Computer Science. Unfortunately, not every programming language is blessed enough to have it. Timestamps: 00:00 Powerful Computers have No Security 03:07 Reverse Engineering is Program Surgery 04:55 The first .COM in History 06:56 The Least Private OS Ever Created 09:33 Rebooting, Never? 12:41 Reflection Tier List Ranking 16:13 C++ is getting COOL 18:22 Rust is…Rough 20:13 God-Tier Reflection 22:27 Blessing C++ with…Metadata? 26:44 Rebelling against the Machine

Building a compiler that works at compile-time so you can compile your program while you compile your program. In short, I wanted to build a compiler of some C subset that would work at compile-time. It compiles into a custom byte-code for a runtime VM. I've once tried to write a compile-time C compiler, but I abandoned that project, because I made it overly complex (one-pass compiler right into x86). No clear separation between parser, lexer, etc. Why would I even want this? Idk. But how can it be useful? - The code of the compiler doesn't go to the resulting binary, - No need to waste time for compilation at runtime too, - Guaranteed type-safety. There can't be such thing as "oh, I changed the function signature, but forgot to update the bindings and it crashed at runtime" And I shouldn't forget about cons: - No optimisations. Real compilers spent decades on them and I'm definitely not going to implement LLVM at runtime. Although we could make a compile-time x86 VM, so we can run it at compile time... no, thank you, it's a topic for another fever dream article. - Hot-reload! I mean, no hot-reload. I won't even mention it anymore, considering that the script is compiled at compile-time and is builtin right into the binary file. I could implement it with hot memory patching or smth, but who really needs it. Let's start. ## Bypassing constexpr limitations C++ 20 lets us to dynamically allocate memory at compile-time and even use `std::vector` that really expands our borders. But there's one very important note - you can't declare a compile-time vector and extract it into the runtime. No `constexpr std::vector data = makeData();`, it won't compile. So we need to hack it. ### Passing strings in templates Sadly, the C++ Committee made a lot of cool compile-time features, but not enough (at least for me). We still can't use strings in templates without hacks. But we can easily bypass it with a well-known trick. ```cpp template struct const_string { constexpr const_string() = default; // implicit-constructor that lets us to do bad things constexpr const_string(const char (&str)[N]) { std::copy_n(str, N, value); } constexpr operator std::string_view() const { return {value, value + N - 1}; } char value[N]{}; const std::size_t length = N; }; // using it template auto very_smart_function(...) { /* ... */ } ``` ### Extracting vectors from compile time It turned out to be not really that hard, but I didn't really find any ready examples on Internet, unlike with `const_string`. To extract `std::vector ` from constexpr we need to make it `std::array ` somehow. The main problem is that we can't write `std::array `, because `myVector.size()` won't be a constant value. So we must to make it constant somehow. I thought of passing vector as a template parameter, but we can't do it legally. C++ 20 allows us to pass only the structs with all-public members. After deeply thinking a bit (not really), I discovered that I could simply pass the lambda that returns our vector (I didn't think I could just pass a pointer actually). ```C++ // data_getter is our lambda template constexpr auto to_array() { using value_type = typename decltype(data_getter())::value_type; constexpr static std::size_t size = data_getter().size(); // Create a static array with a "dynamic" size and copy all data std::array out; auto in = data_getter(); for (std::size_t i = 0; i constexpr auto lex() { constexpr static auto data_getter = [] constexpr { // .lex() returns the vector of tokens return lexer{static_cast (str)}.lex(); }; // All our data are available for runtime now =D return to_array (); } ``` ### Printing errors For nice errors C++ has `static_assert` that allows us to even print our custom message! But it must be always a literal (until C++ 26) ```cpp constexpr auto parse() { // Allowed static_assert(false, "Expected ';'"); // Not allowed :( (until C++ 26) std::size_t line = 5; static_assert(false, "Expected ';' at line " + to_string(line)); } ``` I didn't want my project to require C++ 26, so I used another trick. The formatted string gets turned into a static array just like a vector (into `const_string` actually) and then it's passed into `ErrorMessage ` that triggers compilation error. So we force the compiler to print the full type name that includes our error. But sadly the type name has a limit about 100 symbols. I think I could solve it with splitting the message into several ErrorMessages... God, I don't want to read this in my console. ```c++ template struct ErrorMessage { static_assert(false, "Check the template parameter for details"); }; template consteval auto report_error() -> void { // C++ 26 support #ifdef KORKA_FEATURE_FORMATTED_STATIC_ASSERT static_assert(false, to_string(err_getter())); #else constexpr auto msg = const_string_from_string_view (); std::ignore = ErrorMessage {}; #endif } ``` I don't want you to see it, so I'll just show C++ 26 version. ``` error: static assertion failed: Lexer Error: Unterminated string at line 12 ``` ### Mapping signatures to names. And vice versa In our little runtime C++ we are used to `std::unordered_map ` and other standard or non-standard (hello, Boost!) containers. But I needed a table where a key is a string and the value is a TYPE. And in C++ I can't treat types as values, I can't just put them into a dict... :( So, welcome another hack! ```c++ template struct signature_mapper; // function_info_getter takes an index to our mapped function, // and Is... holds all indices template struct signature_mapper > { // hash func consteval static auto hash(auto &&v) -> std::size_t { return frozen::elsa {}(v, 0); } // Our function overloaded with many unique types based on hash of the mapped function constexpr static auto _overloaded = overloaded{ ( [](unique_type ) -> const_function_info_to_signature_t * { return nullptr; } )... }; // Extracting the type by name template using get_signature_t = std::remove_pointer_t {} ) )>; }; ``` We use well-known function overload (~~but for evil things~~). Basically, one type inherits a lot of lambdas that take an empty `unique_type ` that serves as our key and returns the pointer to our type. ```cpp // How our mapper looks after expanding our params struct overloaded : lambda1, lambda2, lambda3 { using lambda1::operator(); using lambda2::operator(); using lambda3::operator(); }; // And every lambda looks like this auto lambda_fib = [](unique_type ) -> signature_of_fib* { return nullptr; }; ``` When we call `_overloaded(unique_type ())` our poor compiler has to resolve the overload. And he looks for right one through all `()` operators. And then we just take that it returns (our `T*`) and get the `T`. I use this "mechanism" to extract script functions into the native C++. ```cpp constexpr auto script_fib = compile_result.function (); ``` ### Bindings from C++ to our script lang This was the most exhausting part. Well, how "exhausting" exactly... I was thinking for a few evenings and then made it work one morning. The problem was with me. I wanted to make a pretty API that was impossible in the current standard (maybe it's possible in C++ 26, but I didn't check it). I wanted it to look like this: ```cpp auto func() -> void; auto foo(int) -> int; // Примерно так constexpr auto bindings = korka::make_bindings (); // Или так constexpr auto bindings = korka::make_bindings( "func", func, "foo", foo ); ``` But why couldn't I make it work? In C++ you can't pass a string into `template `. We need `const_string`. We can't mix types in the one stream of variadic args and make compiler guess it right. Templates require explicitness and it's impossible to write a universal parser. Variant #2 works, but you can't extract the function into the runtime. You just can't. Functions may have different signatures, but you need to make them all the same type, and create a FFI wrapper along the way. Compile-time doesn't allow `reinterpretet_cast (&func)`. So I designed this: ```cpp constexpr auto bindings = korka::make_bindings( korka::wrap ("cpp_fib"), korka::wrap ("print_n") ); ``` Not so elegant, but still not bad. `wrap` is very simple ```cpp // our FFI signature using vm_external_function_type = void(vm::context_base &context); // info for our compiler template struct wrapped_function { using signature_t = Signature; vm_external_function_type &external_func; std::string_view name; }; template consteval auto wrap(std::string_view name) { return wrapped_function >{ binding_wrapper , name }; } ``` The most interesting part is inside `binding_wrapper `. I won't show the full code here, because I still didn't tell about the VM architecture that will execute it. But in short binding_wrapper just checks the signature, generates some code that extracts arguments from VM, calls native functions and then puts the result back. Simple. ## The compiler and the VM Maybe the most interesting part of the article. I have never written any compilers before (the thing I mentioned in the beginning of the article doesn't count), so I made it according to the first articles I found in Google. Compiler has 3 modules: - the lexer - splitting the code into tokens, - the parser - building a tree from the tokens, - the compiler itself - making the tree into byte-code. And doing semantic analysis at the same time (I was too lazy to make another module) I think I could compose everything into one class via composition or smth, but it's too late already. ### Lexer Primitive. We just look for tokens in a loop until we reach EOF. ```cpp constexpr auto scan_token() -> std::optional > { char c = advance(); switch (c) { case '{': return make_token(lex_kind::kOpenBrace); case '}': return make_token(lex_kind::kCloseBrace); case '(': return make_token(lex_kind::kOpenParenthesis); case ')': // ... case ' ': case '\r': case '\t': // Ignore whitespace return std::nullopt; // ... default: if (is_digit(c)) { return scan_number(); } else if (is_alpha(c)) { return scan_identifier(); } } } ``` ### Parser More interesting. We need to build the AST (abstract syntax tree). And we need to store this tree somehow. The usual way with `Node` that keeps pointers to other nodes won't do, because we're at compile-time. I mean, we can write it this way, it will work, but extracting this tree into compile time? No. We would need serialisation or something. So we can use simple trick with `std::vector ` and just make nodes store indices to each other. This approach also increases the cache locality of the data for the CPU, but I doubt the CPU will be even aware of our "smart" trick, since everything is executed at compile-time. The parser is recursive, while parsing one expression we parse another. Small fragment of the code: ```cpp constexpr auto parse_statement() -> parse_result { auto tok = peek(); if (!tok) return make_error("Unexpected end of input"); switch (tok->kind) { case lex_kind::kOpenBrace: return parse_compound_stmt(); // { ... } case lex_kind::kIf: return parse_if_statement(); // if (...) ... case lex_kind::kWhile: return parse_while_statement(); // while (...) ... case lex_kind::kReturn: return parse_return_statement(); // return ...; default: return parse_expression_stmt(); /// ...; } } constexpr auto parse_return_statement() -> parse_result { if (!match(lex_kind::kReturn)) return make_error("Expected 'return'"); index_t expr_idx = empty_node; // empty_node = -1 if (auto next = peek(); next && next->kind != lex_kind::kSemicolon) { auto expr = parse_expression(); // another recursive call if (!expr) return std::unexpected{expr.error()}; expr_idx = *expr; } if (!match(lex_kind::kSemicolon)) return make_error("Expected ';' after return"); return m_pool.add(stmt_return{expr_idx}); } ``` parse_return_statement goes into parse_expression, that goes into parse_assigment, that goes into parse_logical_or, that goes... Well, you got it. That's how operator priority works here. ### Their Majesty Compiler (and analyser) I may have cheated here a bit. Before we even write a compiler, we must know for what architecture we do it. x86, ARM or even JVM. Initially when I was working on a similar project, I planned to generate raw assembly for x86 (last versions of Clang and GCC support passing `constexpr std::string_view` into `asm(...)` statement), but honestly writing a compiler for a zoo of x86 instructions is the right way to madhouse. And even so, if we downgrade our compiler we won't have nice constexpr asm anymore. And we can't also generate raw machine instructions because of DEP (data execution prevention). We'll have to call non-crossplatform `mmap` or `VirtualAlloc` to allocate some memory, copy the code there... Good riddance cross platform build compler, hello Windows Defender that will kill our app for such tricks with memory. So where have I cheated? I made my own architecture that will execute inside a VM. A stack VM. Why stack it? It turned out to be incredibly easy to generate the bytecode for. If you are doing a register architecture (as in processors or Lua), then you will have to write register allocation algorithms (it is difficult). And in the stack everything is much simpler. If we need to sum A and B we just do this: 1. Put A into the stack. 2. Put B into the stack. 3. Execute sum instruction. It takes these two values and puts back their sum. So I had this set of instructions at the end: ```cpp enum class op_code : char { // Loads/saves locals to/from the stack (variables). lload, lsave, i64_const, // Puts a constant onto the stack // Math i64_add, i64_sub, i64_mul, i64_div, // Puts 1 if values are equal (i made ` (the one we're going to elegantly extract via `to_array`). And in the result we receive a ready, semantically-correct and absolute safe (let's pretend that I wrote the compiler bug-free, huh) byte-code that we feed to the VM. ## So what do we have? Let's look how the API of my poor lib looks (let's call it Korka). This example uses bindings (100% type safe, I swear on the standard): ```cpp // Our native C++ functions auto fib(std::int64_t n) -> std::int64_t { if (n == 0) return 0; if (n == 1) return 1; return fib(n - 1) + fib(n - 2); } auto print_n(std::int64_t n) -> void { std::cout ("cpp_fib"), korka::wrap ("print_n") ); // Compile at compile-time, yay constexpr auto compile_result = korka::compile (); // Extract function adressess + their types constexpr auto script_fib = compile_result.function (); constexpr auto script_print_fib = compile_result.function (); int main() { // Init VM korka::vm::context ctx{compile_result.bytes, bindings}; // Call fib that returns int64_t auto result = ctx.call(script_fib, 12L); std::cout << "fib(12) = " << result << '\n'; // prints 144 // Call print_fib ctx.call(script_print_fib, 16L); // prints 987 return 0; } ``` Ta da! It works. ## Small analysis Out of curiosity, I decided to compare Korka with other scripting languages. A pretty API is great, sure, but was it worth the effort performance-wise? So, let's pit Korka head-to-head against Python and Lua. For the benchmark, I used the recursive calculation of the $N$-th Fibonacci number, an excellent test to fairly evaluate overhead on function calls, stack management, and overall runtime efficiency (the first thing that came to my head). I tested everything on a franken-server put together from spare parts, powered by an Intel Xeon E5-2689 (3.6 GHz). I measured two stages: - **Initialization time** from runtime startup to being ready to execute the first instruction, - **Execution time** of the algorithm itself. ### Stage 1: Initialization |**Language / Library**|**Initialization time**| |---|---| |**Korka**|**1.5 µs**| |**Lua**|152.6 µs| |**Python**|25,097.0 µs| Korka takes the lead: it starts 100 times faster than Lua and over 15,000 times faster than Python. The explanation is simple: while Lua and Python are busy reading the script at startup, parsing it, compiling it into their byte-codes, and spinning up heavy infrastructure (including the GC), Korka does not. All the virtual machine has to do is grab the pre-compiled output (and allocate a tiny bit of memory). ### Stage 2: Runtime After a series of optimizations, the results turned out pretty solid (I know comparing statically typed and dynamic languages isn't entirely fair, but who's gonna stop me?): | **N** | **Iterations** | **Korka (ms)** | **Lua (ms)** | **Python (ms)** | **vs. Python** | | ------ | -------------- | -------------- | ------------ | --------------- | -------------- | | **10** | 100 000 | **1 055,67** | 1 534,98 | 1 591,10 | **1,51x** | | **15** | 50 000 | **5 492,40** | 8 149,17 | 8 753,77 | **1,59x** | | **20** | 20 000 | **24 263,39** | 36 268,86 | 38 459,88 | **1,59x** | | **23** | 10 000 | **51 367,20** | 76 494,22 | 82 257,71 | **1,60x** | | **25** | 5 000 | **67 441,69** | 100 850,20 | 108 836,54 | **1,61x** | | **28** | 2 000 | **114 341,21** | 169 626,06 | 184 869,57 | **1,62x** | | **30** | 1 000 | **149 190,02** | 223 229,86 | 241 838,28 | **1,62x** | ### Conclusion I built a (mostly) full-fledged C compiler that runs entirely in `constexpr`. Why? No idea. Especially considering it's been done before, you can check out [constexpr-8cc](https://github.com/keiichiw/constexpr-8cc). But that one lacks C++ bindings and cross-platform support. The source code is available on [GitHub](https://github.com/PyXiion/pxkorka) (warning: ugly code ahead!). Any feedback and comments are more than welcome. *P.S. This article is an English translation of a post I originally published on Habr a while ago. Keep in mind that some benchmarks and discussions here may be dated.*

const_cast: A Necessary Evil

C++26: Reducing undefined behaviour

I am one of the primary maintainers of the fast JSON library (simdjson). We have been doing a lot of hard work for months without a major release. Our last major release was version 4 last year. In particular, we have added top-notch support for C++26. We presented some of this work at cppcon last year in Denver. We were going to do a big simdjson release this year, when LLVM/clang would support C++26. But it is taking longer than I expected. Oddly enough, GCC seems to be moving much faster. That's good because it is a great and important compiler. So I am now thinking about a major release in the near future. simdjson.org

I don’t struggle with C++ C++ struggles with me.