Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26: Std:Is_within_lifetime

sandordargo.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: C++26: Std:Is_within_lifetime

#51

Post by jeffbee »

anematode wrote: post #50
PaulDavisThe1st wrote: post #41

Earlier quoted context omitted.

Yeah, I had an opportunity to use it for more or less precisely this case (avoiding a branch) a couple of years ago, and it was a delight to find. template void method () { .... if (condition) /* constexpr */ { extra_code; } .... } Which then allows method and method without a runtime branch.

The cardinal question: is the benefit of removing that branch worth the increase in i-cache footprint? I think it depends quite a bit... but also, the speed increases IME from doing this kind of thing can result not merely from the branch removal, but from the code duplication itself. Even if the contents of the branch doesn't directly mention the condition, duplication allows the surrounding code to be separated in…

I work on a codebase where I am slowly detangling all of the tens of thousands of lines of `if constexpr` templates that were written by a guy who doesn't know how a modern CPU works. It's a bad meme with a very narrow field of beneficial applications. People who think a mispredicted branch is costly are never gonna believe the cost of a page table walk caused by an iTLB miss.

Re: C++26: Std:Is_within_lifetime

#52

Post by jcranmer »

alphazard wrote: post #16
worldsavior wrote: post #10

Mature lanagues like CPP should stop adding more features to the language/std. Adding features to the language just makes it more complex, and adding to the std library just adds more overhead, and maybe even security issues.

What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Unless you have a system that says "no" a lot, and occasionally removes features, programming la…

> What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory.

Dear lord that is not the case. The C++ standardization process is extremely different from Rust's specification process, and the resulting pathologies are extremely dissimilar. Hell, C is fairly close to C++ in terms of process, and yet it still has its own set of pathologies.

The C++ committee is dominated not by experts on compiler implementation, but by people looking to get their own proposals incorporated into the standard, and is structurally organized in such a way that it can be difficult for any group to feel empowered to actually reject a feature. It should be noted that in the most recent batch of C++ papers, there was effectively an implementers' revolt: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p39....

The Rust proposal process is much more ponderous, and when you take into account the lag between an accepted RFC and implementation and stabilization (and the fact that some accepted RFCs turn out to be unworkable and effectively get backed out without ever being stabilized), it's pretty clear that the actual development process is night-and-day different. For example, the Try trait in Rust still has yet to be stabilized, despite the RFC proposing it being introduced over nine years ago and a v2 RFC being accepted five years ago.

Re: C++26: Std:Is_within_lifetime

#53

Post by DaiPlusPlus »

IsTom wrote: post #13
matthewkayin wrote: post #4

The problem pointed out in the article seems a little silly. We're adding an entire language feature because someone wanted an optional bool class? Why not just create a uint8_t with three values: OPTIONAL_BOOL_FASLE, OPTIONAL_BOOL_TRUE, OPTIONAL_BOOL_UNDEFINED? Doing so takes the same space as a bool, and could be wrapped in a class if desired to provide a nicer interface.

Ah, the good old True, False, FileNotFound.

...huh, TDWTF is not-only still online, but it even has recent updates.

(for those wanting context, it's from this post from 2005: https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth )

Re: C++26: Std:Is_within_lifetime

#54

Post by FuckButtons »

ainiriand wrote: post #15
raincole wrote: post #14

Earlier quoted context omitted.

Since the birth of ChatGPT, people have been talking about if one day LLMs will be trained to write bytecode or even machine code directly, making future code incomprehensible for humans. It'd be funny if it ends up being just C++35.

I would love to see the first LLM shot in the foot with C++. I mean it is not like human devs don't do that right?

I mean, you can see llms shooting themselves in the foot with c++ right now, just ask them to write it.

Re: C++26: Std:Is_within_lifetime

#55

Post by alphazard »

armchairhacker wrote: post #36
alphazard wrote: post #16

Earlier quoted context omitted.

What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Unless you have a system that says "no" a lot, and occasionally removes features, programming la…

Even Go is encountering the same fate, albeit slower. It’s nearly impossible to remove a feature once it has seen adoption, especially without an alternative; whereas there are always patterns that are greatly simplified by some new feature, and when a language becomes large, these patterns become common enough that the absence of said feature becomes annoying.

Yes agree, we are definitely past peak Go.

Suspiciously, after Rob Pike retired from the project, the amount of language and standard library changes skyrocketed. Many people now trying to get their thing into the language so they can add it to their list of accomplishments.

Clear evidence that you need someone saying "no" often.

Re: C++26: Std:Is_within_lifetime

#56

Post by dataflow »

anematode wrote: post #50
PaulDavisThe1st wrote: post #41

Earlier quoted context omitted.

Yeah, I had an opportunity to use it for more or less precisely this case (avoiding a branch) a couple of years ago, and it was a delight to find. template void method () { .... if (condition) /* constexpr */ { extra_code; } .... } Which then allows method and method without a runtime branch.

The cardinal question: is the benefit of removing that branch worth the increase in i-cache footprint? I think it depends quite a bit... but also, the speed increases IME from doing this kind of thing can result not merely from the branch removal, but from the code duplication itself. Even if the contents of the branch doesn't directly mention the condition, duplication allows the surrounding code to be separated in…

> is the benefit of removing that branch worth the increase in i-cache footprint?

Like everything else in the world, in general, it depends.

That said, among the limited number of times I've tried this, I don't recall a single case where I felt it would be worth it and it turned out to be detrimental.

Re: C++26: Std:Is_within_lifetime

#57

Post by PaulDavisThe1st »

anematode wrote: post #50
PaulDavisThe1st wrote: post #41

Earlier quoted context omitted.

Yeah, I had an opportunity to use it for more or less precisely this case (avoiding a branch) a couple of years ago, and it was a delight to find. template void method () { .... if (condition) /* constexpr */ { extra_code; } .... } Which then allows method and method without a runtime branch.

The cardinal question: is the benefit of removing that branch worth the increase in i-cache footprint? I think it depends quite a bit... but also, the speed increases IME from doing this kind of thing can result not merely from the branch removal, but from the code duplication itself. Even if the contents of the branch doesn't directly mention the condition, duplication allows the surrounding code to be separated in…

Yep, that was my thinking as well. Two things:

1. this is being used in a method that is widely used in both the and contexts, which I believe means that branch prediction would not be great if it was simply the same instruction sequence in both contexts. I could be wrong about that.

2. the major benefit that I saw was not duplicating the much more substantial code in the "..." sections (before and after the constexpr) and thus making maintainance and continued evolution of the code more reliable.

Re: C++26: Std:Is_within_lifetime

#58

Post by matthewkayin »

cataphract wrote: post #18
matthewkayin wrote: post #4

The problem pointed out in the article seems a little silly. We're adding an entire language feature because someone wanted an optional bool class? Why not just create a uint8_t with three values: OPTIONAL_BOOL_FASLE, OPTIONAL_BOOL_TRUE, OPTIONAL_BOOL_UNDEFINED? Doing so takes the same space as a bool, and could be wrapped in a class if desired to provide a nicer interface.

It was an example. The point was to make untagged unions usable in constant evaluation contexts. What I was surprised with was that their union code was valid. I thought accessing a union member that was not active was valid in C, but not in C++.

I would think it would have to work the same in both since otherwise C code using that behavior would not compile in C++, right?

I am not a C++ expert, but I'm surprised to hear that it is considered UB to access the other member since as far as I can tell a union is just a chunk of memory that can be interpreted differently depending on which union member you access?

So, if you had a union { bool b, char c }, and you set b = false, then I would think that accessing c would predictably give you a value of '\0'.

Granted, you probably shouldn't go around accessing an inactive union member like that, but when people say it's UB they make it sound like it's impossible to guarantee what data will be inside that byte, and it seems to me like that isn't true.

Re: C++26: Std:Is_within_lifetime

#59

Post by anematode »

jeffbee wrote: post #51
anematode wrote: post #50

Earlier quoted context omitted.

The cardinal question: is the benefit of removing that branch worth the increase in i-cache footprint? I think it depends quite a bit... but also, the speed increases IME from doing this kind of thing can result not merely from the branch removal, but from the code duplication itself. Even if the contents of the branch doesn't directly mention the condition, duplication allows the surrounding code to be separated in…

I work on a codebase where I am slowly detangling all of the tens of thousands of lines of `if constexpr` templates that were written by a guy who doesn't know how a modern CPU works. It's a bad meme with a very narrow field of beneficial applications. People who think a mispredicted branch is costly are never gonna believe the cost of a page table walk caused by an iTLB miss.

Narrow indeed. If the function is small enough for the i-cache pressure to not matter, it's probably going to get inlined and the condition gets optimized out anyway. If it's big enough, then it's unclear, but microbenchmarks will give you misleading results.

Re: C++26: Std:Is_within_lifetime

#60

Post by alphazard »

jcranmer wrote: post #52
alphazard wrote: post #16

Earlier quoted context omitted.

What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Unless you have a system that says "no" a lot, and occasionally removes features, programming la…

> What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Dear lord that is not the case. The C++ standardization process is extremely different from Ru…

This kind of "but for us it's different" thinking is a little amusing.

I don't care about the implementation process or the RFCs or what-have-you. If there is a democratic committee of humans that decides what goes in, and there is no bias for minimalism (e.g. 1/3 could strike down a proposal instead of 1/2) then the process will tend towards bloat.

Post reply on HN