I've been writing C++ code since before the first Standard, and this just irks me. Words have meanings. There is no such thing as a "method" in **this** language.
(I'm going to be bold and assume the "no questions" rule is for questions about specific code, not about discussing the language itself)
I am extremely happy that we have reflection in C++26, however currently it is GCC only. I am using Clang on all platforms, so I am curious about when it will get reflection.
I tried searching and I found a bunch of experimental forks with reflection. I am not sure if those track the current version of reflection and whether one of these is going to be merged, or if a new implementation will be created. Github issues basically say "we get it when we get it" and link to LLVM discourse. On discourse I found just a thread that a meeting on reflection was held in December.
Do you know either when we are getting reflection, or if there is some way to track its progress for outside observers? Thanks!
It's necessary to keep c++ complex and redundant, so no normies ever dare to create slop libraries for it, like how npm has libraries just for printing "hello world".
Furthermore, generative AI isn't even capable of creating simple NextJs application without a million vulnerabilities, good luck trusting AI with pointers.
Not to mention, c++ is the only programming language that is truly able to utilize Vulkan, Directx, win32, Posix (c as well) with a billion wrappers. This leaves system programming completely reserved for us.
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?
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 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.
I sure do love waiting 5 minutes on my laptop waiting for tests to compile, even on -o0.
It is really a productive use of my time.
This is with Catch2 v3, with prebuilt binary packages, it is that slow.
Honestly gtest is older but compiles way way faster.
Please stop using that.
Hey all, I put together a very simple reflection utility that lets you make toggleable annotations, similarly to explicit(bool) or noexcept(bool).
Try it on Compiler Explorer!
inline constexpr rjk::flag serializable{};
inline constexpr rjk::flag skip_field{};
template <typename T>
struct [[ =serializable ]] MyType {
int x;
int y;
[[ =skip_field(std::is_pointer_v<T>) ]]
T data;
};
// serializable is applied unconditionally
static_assert(rjk::is_flag_set(^^MyType<int>, serializable));
// skip_field is applied conditionally
static_assert(not rjk::is_flag_set(^^MyType<int>::data, skip_field));
static_assert(rjk::is_flag_set(^^MyType<int*>::data, skip_field));
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.
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:
https://wg21.org/mailing/2026-08/
Source mailing: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/#mailing2026-08
Something I kept running into building agent tooling: giving an agent an MCP
tool that *could* answer a question about the codebase doesn't mean it will.
Tool-call decisions are probabilistic, not guaranteed. The agent has to
recognize it needs the tool, remember it exists, and choose to call it over
just grepping. A lot of "codebase context" products are architected as
exactly that: an MCP server sitting in the tool list, unused more often than
not.
Graft's bet is different: don't wait to be asked. It hooks directly into
Claude Code. The matching nodes get pulled into every prompt automatically,
editing a file surfaces its dependents inline, and the graph re-syncs itself
in the background after every edit, all without the agent deciding to invoke
anything. Same reason Chrome doesn't ship with an ad blocker built in: the
core stays general, and the extension handles the specialized job. Graft is
that extension for context.
Underneath, it's a typed graph, not a vector index: tree-sitter builds a
deterministic per-symbol graph (no model call), and an optional `--deep` LLM
pass groups that into markdown nodes with typed links (`depends_on`, `uses`,
`produces`) an agent follows like any other file. Method calls resolve
through the receiver's type (constructor assignments and type annotations,
not just call-site name matching), so a common method name doesn't pull back
every unrelated method with that name across the codebase.
The claim: up to 4× cheaper and 3× faster, with better or no loss of
correctness. Setup: 162 runs, two repos (graft itself + a real Node/Express
auth service), 3 trials each, single-file and multi-file questions split
evenly. Three variants of the same Claude Sonnet 5 agent: cold (explores from
zero), push (context bundled up front), pull (MCP tools, nothing injected,
paid for only when asked). A separate Opus 4.8 model graded correctness with
a required-keyword floor, so a fast-but-wrong answer couldn't win by being
fast. Cost is cache-aware (reads ~0.1×, writes 1.25×) to match real billing.
Results: push cut cost 32%, tool calls 46%, latency 60%, at equal correctness
(93% both, no loss). Pull gave up most of the speed but correctness jumped
to 98%, +5 over cold, the "better" half of the claim, and worth noting: pull
*is* the MCP-tool-list approach, and it still worked, because the harness
forced the call. Left to its own judgment across a real session, that's
exactly the discipline that erodes.
Second test, because a benchmark on questions can still be gamed: reset
PocketBase to its base commit before 5 merged PRs, re-implemented each with
and without graft, scored by file-overlap with what the maintainers actually
changed. 5/5 reproduced, at 21% lower cost.
Opensource, MIT licensed
Here's the repo link : https://github.com/NanoNets/Graft
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.
Boost 1.92.0 is out. Highlights from this release:
GPU / CUDA
to_chars and from_chars for integers are now usable inside CUDA kernels.decimal32_t, decimal64_t, and decimal128_t are now usable in CUDA kernels.Networking hardening
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.normalize_path for authority-less URLs and an uninitialized read in ipv6_address_rule.Containers and data structures
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.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.insert_range, std::from_range construction, and associated CTAD).std::optional, std::variant, and std::monostate.C++20 modules
Build system
.dll files now install into the binary directory by default (previously the library directory, except on Cygwin). A new --dlldir option overrides this.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
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/
Someone else did a similar thing a few months ago, but I wanted to see if it could be done with templates.
I ended up writing a dependency inverter/injector that can reflect on the concepts restricting unfilled template types and substitute actual types into them. Unfortunately, C++26 reflection doesn't seem to allow reflection of concepts like this, so I did it with string parsing.
The result is... fairly janky, but you can play around with it here.