alt.hn

4/23/2025 at 7:13:03 PM

C++26: more constexpr in the core language

 https://www.sandordargo.com/blog/2025/04/23/cpp26-constexpr-language-changes

by jandeboevrie

4/24/2025 at 12:37:42 AM

Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future?

https://en.cppreference.com/w/cpp/compiler_support

by mcdeltat

4/24/2025 at 6:54:40 AM

FWIW, I can’t ever remember a time when the most widely used compilers in practice weren’t around 5-10 years behind changes in the standard. Part of the issue is that adoption takes time, and always will. A lot of people using C++ professionally don’t want to be on the bleeding edge of language changes. Some do, but a lot don’t, for good reasons.

When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.

by dahart

4/26/2025 at 12:35:27 AM

Perhaps you are right, and I had rose tinted glasses. I seem to remember C++17 being completed (all major features) around 2018 on at least one or two major compilers. Meanwhile C++20 still doesn't have modules properly implemented, which is such a huge feature IMO that I count it as a major deficit. But maybe C++17 was the exception rather than the rule.

I think what annoys me most is when a standard is implemented except for an important feature. E.g. ranges was unusable for ages on Clang. And modules is still not quite there. I want to use the latest standard to get these cool features so I can write code like it's 2025, not 1980. If the biggest features are unimplemented then why upgrade? My concern is the trend continues, and we get cool things like reflection, but it takes 10 years to be implemented properly.

by mcdeltat

4/24/2025 at 6:47:35 AM

Yes, it changed my point of view that it is about time WG21 goes back to the old ways of only standardising existing practice, or at very least proposals without preview implementations shouldn't even get discussed in first place.

The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only.

And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.

by pjmlp

4/24/2025 at 11:11:57 AM

The other side of that coin is that if you required "technical implementation merit", then only people or groups who have strong experience with C++ compilers would be able to propose things.

I'm not saying that the existing situation is ideal and it's certainly not a dichotomy, but you have to consider the detriments as well as the benefits.

by einpoklum

4/24/2025 at 1:11:21 PM

You could have a two-stage process. Stage 1 would be the proposal, where you have the discussion on whether the feature is desirable or not, which can then be provisionally accepted. At this point it is not in the standard.

Then you have Stage 2, which would require an actual working implementation, so it can be properly tested and such. Acceptance in Stage 2 would result in the feature being in the standard.

by Measter

4/24/2025 at 4:06:35 PM

Great, languages like C++ relevance on the industry, should have a "you should be this high to play" entrance price.

Also I should add this is no different on wannabe C and C++ replacements, or most other programming languages with similar market share.

Go try to do a drive by pull request for a new language feature on those ecosystems.

by pjmlp

4/24/2025 at 3:31:40 AM

It is worth noting that one of the main reasons why C++ standard evolution is faster nowadays is because the "bare minimum" for consideration of acceptance in the standard is working examples on a fully functioned compiler. This tends to make it a lot easier for other compilers to implement those features as there is at minimum a working reference to compare against (vs older still unimplemented features like modules where nobody really ironed out how to properly implement them until after they were shoehorned into the standard)

by OneDeuxTriSeiGo

4/24/2025 at 12:48:14 AM

Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.

by Pet_Ant

4/24/2025 at 7:38:38 AM

Yeah, I've been very worried about this. C++23 is basically unimplemented as far as I'm concerned. Working on C++26 makes no sense to me. They gotta space it out more than 3 years, if nothing else.

by dataflow

4/24/2025 at 11:17:26 AM

I cannot believe how, after all these years, we don't even have `restrict` in the language, nor uniform function call syntax (i.e. x.foo(y) being interchangeable with foo(x, y) ); but we do get the ultimate bells-and-whistles in the form of reflection and reflection-based code generation; and the half-baked coroutines mechanism.

uniform function call syntax and a `restrict` mechanism have not made it in to the standard after so many years

by einpoklum

4/24/2025 at 1:23:32 PM

You might like D.

by srean

4/24/2025 at 6:18:08 AM

That is more on the fact that less investment is made in C++ compilers nowadays. Companies are migrating away from C++ and it shows in compiler development.

by whatagreatboy

4/24/2025 at 4:42:57 AM

the only people that complain about this don't actually write C++

by almostgotcaught

4/24/2025 at 6:42:35 AM

I write C++, and complain about still not having a portable C++17 implemenation that fully supports parallel STL, not having a full compliant C++20 compiler, embedded compilers kind of still catching up with C++14, and I could rant on.

by pjmlp

4/24/2025 at 9:55:22 AM

Are there any embedded compilers left that try to implement their own C++ frontend? To me it looks like everyone gave up on that and uses the clang/gcc/EDG frontends.

by ynik

4/24/2025 at 10:40:49 AM

Yes, and even those that have compiler forks aren't on vLatest.

Interesting you mention EDG, as it is now famously know as being the root cause why Visual Studio development experience lags behind cl.exe, pointing out errors that compile just fine, especially if using anything related to C++20 modules.

Apparently since the modules support introduced in VS 2019, there have been other priorities on their roadmap.

by pjmlp

4/24/2025 at 9:39:53 AM

Yes to all that, but oneapi::dpl has been out for a while.

by nurettin

4/24/2025 at 10:43:04 AM

And how much does that help anyone in systems that can't make use of it?

by pjmlp

4/24/2025 at 4:20:27 PM

As much as C helps on TinyOS with a MICaz board I guess.

by nurettin

4/24/2025 at 7:06:34 PM

And what has that to do with ISO C++ compliance for portable code?

by pjmlp

4/24/2025 at 7:39:18 PM

It has to do with how ridiculous it is to complain about where the afromentioned very portable library is not supported.

by nurettin

4/23/2025 at 9:41:44 PM

I always like these new comile time features getting into the C++ spec.

I'm actually looking forward to the related reflection features that I think are currently in scope for C++26. I've run into a number of places where the combination of reflection and constexpr could be really valuable... the current workarounds often involving macros, runtime tricks, or both.

by veilrap

4/23/2025 at 10:10:21 PM

> I'm actually looking forward to the related reflection features that I think are currently in scope for C++26.

The core of reflection should be in C++26, yes. In my understanding, there's more to do after that as well. We'll see when the final meeting is done.

by steveklabnik

4/23/2025 at 8:29:15 PM

It would be cool to have the entire language and runtime available at compile-time like in Lisp

by Quitschquat

4/23/2025 at 9:51:02 PM

The D language basically does that. You can write D programs that evaluate D code at compile time to generate strings of new D code which you can then basically compile-time eval into your code as needed. Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages and it's easier to read than Rust macros or C++ template metaprogramming.

by MrRadar

4/23/2025 at 11:43:23 PM

Every time I hear about D it sounds awesome. I actually used it to prototype an image collage-composing algorithm which I then rewrote in Scala[1], and the D version might have been nicer to write.

The only reason I didn't write more stuff in D was that the stack traces from my programs were pretty much useless. Maybe I was supposed to set a --better-stack-traces flag when I compiled it or something idk.

[1] One of the algorithms used by https://github.com/TOGoS/PicGrid

by TOGoS

4/24/2025 at 1:39:21 AM

> Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages ...

Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2].

Not comparing Scala to D, just identifying a language with similar functionality.

0 - https://docs.scala-lang.org/scala3/reference/metaprogramming...

1 - https://scalameta.org/

2 - https://github.com/milessabin/shapeless

by AdieuToLogic

4/24/2025 at 3:48:13 AM

D is really, really good. I hope it gets more love soon. D's focus on just getting shit done, lightning builds, QOL improvements all over the place, actually good modules, templates and metaprogramming that work, simpler more regular syntax, any memory management paradigm you want, being fully batteries included, being super easy to cross compile, being able to span all the way from Python/C# slop all the way down to tight-as-you-like C code... It's an amazing language and is getting better all the time. A real C++ successor. It has become my secret weapon! Maybe I actually don't want it to blow up soon, since it gives me a huge edge on anyone stuck with C++, which gets worse every release (how slow do builds have to get before people lose it completely?).

by sfpotter

4/24/2025 at 5:27:01 AM

Last time I tried D, the standard library required garbage collection. Has that changed ? Can I plugin my custom allocators for the stdlib ?

by lenkite

4/24/2025 at 12:19:26 PM

Many of the functions in Phobos are not `@nogc` compatible, yes.

That being said, I can't think of many scenarios in which an application where user-code is all `@nogc` would be hindered by occasional GC'ed stdlib methods.

One standout example of viability is the "dplug" library for realtime audio processing plugins and the commercial AuburnSounds VST's written by the author.

by gavinray

4/24/2025 at 9:38:32 AM

> way from Python/C# slop

That's one of the craziest things I've heard here. These two languages sit at opposite ends of abstraction.

by neonsunset

4/25/2025 at 2:15:58 AM

Sorry, let me clarify:

In D, you can write Python-style slop code and/or C#-style slop code. Two very different styles of slop code, both of which can be written in D. Or even mixed and matched.

by sfpotter

4/23/2025 at 8:34:06 PM

It would be cool, except for the entire language that is available at compile-time being C++, and thus entirely unsuitable for manipulating C++ programs.

by kazinator

4/23/2025 at 10:15:01 PM

Yes. It is not like C++ compilers are written in C++.

by gpderetta

4/23/2025 at 9:06:16 PM

Circle C++ does that

by klipt

4/23/2025 at 10:16:04 PM

Could you show some examples?

by dataflow

4/23/2025 at 9:37:02 PM

...isn't that what templates were made for? Template metaprogramming in C++ is Turing-complete.

by chrisrodrigue

4/23/2025 at 9:55:28 PM

Not at all, originally template metaprogramming was discovered by accident.

Cannot recall any longer if the original article on the matter appeared on The C/C++ Users Journal or Dr. Dobbs.

Eventually it started to get abused and the Turing completeness has been discovered.

Since C++11, the approach to a more sane way to do metaprogramming with templates has been improving.

Instead of tag dispatch, ADL and SFINAE, we can make use of concepts, if constexpr/eval/init, type traits, and eventually reflection, instead of the old clunky ways.

by pjmlp

4/23/2025 at 11:42:15 PM

Templates are semi-accidentally Turing-complete. They were intended for writing compile-time-generic, run-time-concrete functions and types - but it turned out you could use them, along with the overload resolution mechanisms, to compute things. The Turing-completeness involves recursive use.

Computing things using templates is not intuitive. Many of us have gotten used to it - but that's because that's all we had for many years. It's a different sub-language within C++. As constexpr capabilities widen, we can avoid "tortuted" templates and can just write our compile-time checks and figurings in plain C++ - more or less.

Sometimes, enhanced language features in C++ allow us to actually throw away and forget about other existing features, or at least - complex and brittle idioms using existing features. Like SFINAE :-)

by einpoklum

4/23/2025 at 9:49:49 PM

This already exists with macros, templates, and compiler extensions, if you want completely unusable/unreadable code that takes forever to build.

by jjmarr

4/23/2025 at 9:57:03 PM

Depends on the C++ version.

With C++23 can be made relatively readable, and with the right compiler, builds within sensible timeframe.

by pjmlp

4/23/2025 at 10:15:31 PM

C++23 doesn't have full reflection yet. That's coming in C++26.

I've seen the vast majority of build time in a very large C++23 project be taken up by reflection in fmtlib and magic_enum because both have to use templates (I think).

by jjmarr

4/24/2025 at 5:02:29 AM

I didn't said it has, rather that template metaprogramming can be both readable, and with the right compiler relatively fast.

by pjmlp

4/24/2025 at 5:26:35 AM

Recent C++ changes seem like polishing your firewood before burning it. Yes, they make perfect sense, but often they are a fix to a problem that committee introduced by cutting down previous proposals (e.g. forcing lambdas to be single return statement, then relaxing it).

Half of new features feel like "how to make STL implementation less embarassing".

Meanwhile there still is no language support for e.g. debugging constexpr, or printing internal private state of objects in 3rd party code.

by 112233

4/24/2025 at 11:24:24 AM

> "how to make STL implementation less embarassing".

The "STL" part of the standard library - containers especially but not just that - has an outdated interface, and suffers from ABI being stuck:

https://cor3ntin.github.io/posts/abi/

so it's embarrassing regardless.

> there still is no language support for e.g. debugging constexpr, or printing internal private state of objects in 3rd party code.

Actually, reflection might make it easier to do that. Supposedly, you should be able to get a member pointer to the private member you're interested in (or even do it dynamically by iterating over all members, and figuring out which one you like), from that and an actual object obtain a regular pointer, and finally dereference it.

by einpoklum

4/24/2025 at 8:38:01 AM

How could a debugger make sense of "internal private state of objects in 3rd party code"? Only a portion of the stack frames of linked functions (input parameters coming from known code, maybe expected return values) has a presumable type.

by HelloNurse

4/24/2025 at 9:19:54 AM

> forcing lambdas to be single return statement, then relaxing it

At no point were lambdas single return statement. You might be confusing it with some other language feature. Or language.

by gpderetta

4/24/2025 at 5:33:26 AM

Compile time debugging? Is #warning not good enough?

by greesil

4/24/2025 at 6:41:16 AM

> printing internal private state of objects in 3rd party code

That is more a dynamic monkey patching programming language kind of thing.

by pjmlp

4/23/2025 at 8:02:28 PM

That’s super cool; c++ is always the sharpest tool in the drawer (and by virtue the funnest!)..

It’s too bad you still can’t cast a char to a uint8_t though in a constexpr expression.

by psyclobe

4/23/2025 at 9:02:50 PM

This compiles in clang 21.1.2 with c++26.

    #include <cstdint>
    #include <print>

    constexpr uint8_t f(char ch) {
     return static_cast<uint8_t>(ch);
    }

    int main() {
     constexpr uint8_t r = f('a');
     std::print("{}", r);
    }

by lbhdc

4/24/2025 at 2:48:38 AM

Try consteval , constexpr is a hint. No static casts allowed in constexpr scopes that evaluate as constexpr in c++17 and above (works in c11).

Could be wrong I am no expert…

by psyclobe

4/24/2025 at 6:52:26 AM

It works perfectly fine with consteval, https://godbolt.org/z/sjGcsh3KP

What is possible in constexpr contexts has been improving in each revision, the end goal is to support the whole language, eventually.

Naturally introducing everything at once would be too hard in a language with such a big ecosystem like C++.

by pjmlp

4/24/2025 at 2:16:16 PM

Good to know thanks for the correction

by psyclobe

4/23/2025 at 8:19:44 PM

> It’s too bad you still can’t cast a char to a uint8_t though in a constexpr expression.

Uh, what? That has worked fine since the introduction of constexpr in C++11.

by vinkelhake

4/23/2025 at 10:45:47 PM

Maybe they meant reinterpret_cast from/to char to u8, which in this case isn't possible in constexpr.

by TuxSH

4/24/2025 at 12:19:59 AM

Why would you need to do that though if you can static_cast?

by epcoa

4/24/2025 at 8:01:55 AM

You can't static_cast in this case; https://godbolt.org/z/a1bMbPcaj

by TuxSH

4/24/2025 at 2:01:16 PM

You can use `std::bit_cast` to do that in constexpr contexts.

    constexpr auto f(uint8_t *x) {
      return std::bit_cast<char *>(x);
    }
https://godbolt.org/z/K3f9b9GGs

by lbhdc

4/24/2025 at 3:28:32 PM

No, you can't do that either: https://godbolt.org/z/vzdTMazx7 : error: '__builtin_bit_cast' is not a constant expression because 'char' is a pointer type

Here the `constexpr` keyword means the function might be called in a constant-evaluated context. f doesn't need to have all its statements be able to be evaluated in constexpr, only those which are actually used are. You need to explicitly instantiate a constexpr variable to test this.

cppreference is very clear* about this, regarding bit_cast: https://en.cppreference.com/w/cpp/numeric/bit_cast

by TuxSH

4/24/2025 at 3:56:15 PM

Good catch. Its weird that it compiles without error as a consteval func.

by lbhdc

4/25/2025 at 6:06:46 PM

Hmm, looking at cppreference:

The consteval specifier declares a function or function template to be an immediate function, that is, every potentially-evaluated call to the function must (directly or indirectly) produce a compile time constant expression.

It's possible that the compiler just doesn't bother as long as you aren't actually calling the function.

by TuxSH

4/24/2025 at 2:17:31 PM

Ah this was my case! Was trying to constexpr a uint8_t ptr to char * in a constexpr constructor for a string class.

Ah that’s what bitcast is for, neat!

by psyclobe

4/24/2025 at 7:08:23 AM

every release adding more constexpr stuff honestly helps me - been burned by old template hacks enough lol. you think we ever get to a real point where all this new power just makes stuff easier, or is it always tradeoffs?

by gitroom

4/24/2025 at 12:55:13 AM

[dead]

by waltercool

4/23/2025 at 9:51:30 PM

Are they flogging a dead horse?

C++ is, should be, like COBOL. A very important language because of the installed base. But why the continual enhancements? Surely there are better uses of all those resources?

by worik

4/24/2025 at 1:06:42 AM

The resources here are amplified elsewhere.

As a specific example, expanding constexpr means a codebase I recently worked on can move away from template metaprogramming magic to something that is more idiomatic. That means iterating on that code will be easier, faster, and less error-prone. I've already done static dispatch using constexpr and type traits that would have taken longer to do with templates.

Currently constexpr programming needs you to know the specifics of what is supported - ideally you'll be able to infer that from first principles of the invariants that are available at compile time. That leads to faster, more confident development.

It's a similar story for reflection: we were using custom scripts and soon won't have to. The changes usually come out of the problems people are already finding solutions for in the real world, rather than gilding a lily.

by devnullbrain

4/24/2025 at 4:08:56 AM

I think it'd genuinely boggle some people's minds just how much new c++ code is written everyday. It's not a dead horse at all.

by jsphweid

4/24/2025 at 8:48:46 AM

I'm afraid plenty of programmers decided to break up with C++ and turn to easier languages after having enough of it, usually forever and in anger.

This doesn't make C++ dead, even if it is dead to them; see Aesop's fable about the Fox and the Grapes for an in-depth analysis.

by HelloNurse

4/23/2025 at 10:12:40 PM

Although there are excellent alternatives to C++ such as Rust, C++ is still widely used as many open-source and commercial codebases are built with it.

Adding features to a language that is still actively used does not seem like a bad thing.

by arjonagelhout

4/24/2025 at 4:43:38 AM

The amount of C++ written at my company every day is… a lot. We are slowly fighting away from it towards memory safety, but it is hard. It will take a decade.

by bitexploder

4/24/2025 at 11:39:43 AM

At the company I currently work for we also use C++, and I am quite proficient in it. But the amount of times I have slowed myself down by simple lifetime issues makes me want to switch to a more memory safe language. Whether that is C++ with profiles or a whole new language such as Rust.

For example, a week back I lost a few hours finding a segfault bug in C++ code, which ended up being a trivial lifetime error: I used a reference after it was invalidated due to a std::vector resize.

These kind of errors should be compile time errors, rather than hard to trace runtime errors.

How does your company go about changing to memory safety? Are new projects / libraries written in Rust for example? Do projects / libraries get (partially) rewritten?

by arjonagelhout

4/24/2025 at 7:24:29 PM

It is very hard to reason about lifetimes and they can eat you. We have a lot of guidelines and strategies to simplify it, but it still just isn’t amazing.

by bitexploder

4/23/2025 at 9:54:37 PM

COBOL is being actively developed as a language, the latest standard was published in 2023.

by MrRadar

4/23/2025 at 10:13:46 PM

> Are they flogging a dead horse?

Not exactly. There's a lot of C++ code that still can't be rewritten into cool languages overnight without risking correctness, performance and readability.

I'm always happy to see C++ pushing itself and the compiler backends as it benefits the victims of lame codebases and also the cool kids using the improved compiler backends.

by dietr1ch

4/23/2025 at 10:58:19 PM

from which other language can I make a GUI with Qt while doing low-level graphics and DSP?

by jcelerier

4/24/2025 at 1:47:43 AM

Why is Qt the only option? Rust has plenty of suitable options. Slint is used in production and works on tiny embedded devices.

by dralley

4/24/2025 at 3:31:15 AM

I definitely had my eyes on slint for quite some time (pretty much since it was announced - I highly value the technical skill of their team) but it's still quite far from the whole QWidget offering. I don't know anything else that is even remotely in the same ballpark - certainly not Tauri or egui for instance. Anything that is GPU based is blacklisted from the get go (including QtQuick) - people who preach gpu based GUI have definitely never tried to have a quick debug feedback loop with an app built using AddressSanitizer where just opening the simplest GL or Vulkan context takes up to 20 seconds on a good day.

by jcelerier

4/24/2025 at 4:49:35 AM

Slint is not a replacement for Qt. Slint only provides a tiny fraction of what Qt has to offer https://doc.qt.io/qt-6/modules-cpp.html

by 5d41402abc4b

4/24/2025 at 7:20:16 AM

Only the GUI part is relevant for this discussion as this is what Qt is know for. Other modules also have different Rust crates equivalent, or are really niche and nobody uses them.

by jenadine

4/24/2025 at 3:00:29 PM

that's really not true. There are thousands of projects using e.g.

QtSerialPort (https://github.com/search?q=include+QSerialPort&type=code)

Qt3D (https://github.com/search?q=include+Qt3D&type=code)

QtWebSockets (https://github.com/search?q=include+Qt3D&type=code)

QtSensors (https://github.com/search?q=include+qtsensors&type=code)

Qt SCXML (https://github.com/search?q=include+qstatemachine&type=code)

etc etc..

Qt's value is as an app framework where you can assume interoperation across the same async runtime and enjoy a cohesive set of APIs for all your app's needs.

by jcelerier

4/24/2025 at 2:27:57 AM

Name one of those plenty suitable options rust have to replace something like Qt.

by vhantz

4/24/2025 at 3:54:52 AM

https://www.egui.rs/ is not a million miles away.

As far as I can tell it requires Gl or WebGl though.

by emmelaich

4/24/2025 at 4:50:51 AM

Qt is more than a GUI framework. https://doc.qt.io/qt-6/modules-cpp.html

by 5d41402abc4b

4/25/2025 at 12:41:39 AM

Sure, but the topic is the GUI or so I thought.

by emmelaich

4/24/2025 at 3:57:41 AM

Ask yourself why any programming language gets any changes once there's an arbitrary number of users.

by mystified5016

4/24/2025 at 1:50:41 AM

Do you like using a fast web browser?

by moshegramovsky