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

41–50 of 75 posts

Re: C++26: Std:Is_within_lifetime

#41

Post by PaulDavisThe1st »

Blackthorn wrote: post #33
estimator7292 wrote: post #26

The more I interact with consteval and the whole template metaprogramming and codegen paradigm, the more I think it's completely inappropriate to shovel into stdlib. I don't think this should even be part of the language itself, but something more like a linter on top of the C++ language. For most of us it seems you can get good at C++ or metaprogramming. But unless you want to make it your entire career you can't re…

We find constexpr (and associated templates) essential for when we need to avoid branch penalties. It makes the code so much simpler and cleaner than the alternative. I'm glad the language caters to the needs of everyone, even if any individual person (self included) only uses a little bit of it.

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.

Re: C++26: Std:Is_within_lifetime

#42

Post by ksherlock »

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?

Maybe that's why AI images have all those extra fingers and toes!

Re: C++26: Std:Is_within_lifetime

#43

Post by taminka »

raincole wrote: post #14
dzdt wrote: post #12

This continues the trend that the C++ language spec is too large for any person to understand, full of opaquely named things for obscure use cases. Maybe when most code is written by LLMs this kind of extension will be appreciated? Because the LLM can manage to get its large head around all of these obscure functionalities and apply them in the appropriate situations?

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.

this is silly, we already have an algorithm for generating very efficient assembly/machine code from source code, this is like saying maybe one day llms will be able to replace sin() or an os kernel (vaguely remember someone prominent claiming this absurdity), like yes, maybe it could, but it will be super slow and inefficient, we already know a very (most?) efficient algorithm, what are we doing?

Re: C++26: Std:Is_within_lifetime

#44

Post by swiftcoder »

yearolinuxdsktp wrote: post #28
tialaramex wrote: post #21

Earlier quoted context omitted.

Well, here's Barry's actual proposal paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p26... The language is the problem, and WG21 hates fixing the language. The really bone headed stuff like "UB? in my Lexer?" got through as a language change and Barry has also had some success with "just fix it" language changes, that's what happened so that C++ can attempt what Rust's MaybeUninit does, but mostly WG…

What do you think the programming language fix would be?

The whole problem only arises because accessing the union member as a character is allowed at runtime, but disallowed in constexpr. If that restriction were relaxed to be the same in both cases, the entire motivating problem would disappear...

Re: C++26: Std:Is_within_lifetime

#45

Post by PaulDavisThe1st »

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.

This particular feature impacts only compiler writers, unless you choose to use it. You can write C++ till the end of time and never use std::is_within_lifetime and it will have zero impact on you or your code. If it gets used in stdlib, there's presumably a reason, and if there isn't, then that's worth criticizing. But adding the feature has no impact on 99% or more of all developers.

Re: C++26: Std:Is_within_lifetime

#46

Post by swiftcoder »

ethin wrote: post #27
tw1984 wrote: post #11

you really need to hate yourself to still pay attention to such horrible stuff in 2026. 41 years after its invention, C++ still doesn't have networking support in its stdlib. excuses after excuses, they have millions justifications on why the stdlib doesn't need networking. but in the same time, some bureaucratic "committee members" struggling with their midlife crisis want you to waste your life on stuff like Std:Is…

Oh here we go again, someone demanding networking (of all things) in the standard library. Are you next going to demand a GUI toolkit too? Maybe an entire game engine and Vulkan/WebGPU implementation too while we're at it? Just because other languages do it does not mean it is a wise idea for C++ to follow suit. I mean, do I really need to point you to std::regex as an example of what happens when we try to add extra…

> someone demanding networking (of all things) in the standard library

Networking is defacto in the standard library, because C++ standard library is almost always supplemented by whatever C functionality is lying around, and POSIX networking exists.

That they haven't felt the need to provide a more useful abstraction on top of the POSIX layer (and hey, maybe abstract over Microsoft's variant in the process) in the past 3 decades does seem like a miss

Re: C++26: Std:Is_within_lifetime

#47

Post by ksherlock »

ethin wrote: post #27
tw1984 wrote: post #11

you really need to hate yourself to still pay attention to such horrible stuff in 2026. 41 years after its invention, C++ still doesn't have networking support in its stdlib. excuses after excuses, they have millions justifications on why the stdlib doesn't need networking. but in the same time, some bureaucratic "committee members" struggling with their midlife crisis want you to waste your life on stuff like Std:Is…

Oh here we go again, someone demanding networking (of all things) in the standard library. Are you next going to demand a GUI toolkit too? Maybe an entire game engine and Vulkan/WebGPU implementation too while we're at it? Just because other languages do it does not mean it is a wise idea for C++ to follow suit. I mean, do I really need to point you to std::regex as an example of what happens when we try to add extra…

There was a 2d graphics proposal back in 2014 that (fortunately) went nowhere - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n38...

Re: C++26: Std:Is_within_lifetime

#48

Post by tialaramex »

yearolinuxdsktp wrote: post #28
tialaramex wrote: post #21

Earlier quoted context omitted.

Well, here's Barry's actual proposal paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p26... The language is the problem, and WG21 hates fixing the language. The really bone headed stuff like "UB? in my Lexer?" got through as a language change and Barry has also had some success with "just fix it" language changes, that's what happened so that C++ can attempt what Rust's MaybeUninit does, but mostly WG…

What do you think the programming language fix would be?

Barry even explains, the transmutation is outlawed during compile time in C++. They could remove this prohibition but they did not.

Notice that e.g. Rust doesn't prohibit compile time transmutation, the provided core::mem::transmute literally does this operation, and it's const. The result is - as with similar situations in C++ - that if at compile time that's a 2 the compilation fails, 2 is not a boolean. You don't need all this bother because Rust's type system is better so Option already does have the same size as bool, but that's beside the point.

Re: C++26: Std:Is_within_lifetime

#49

Post by anematode »

MountainTheme12 wrote: post #5

In my C++ all members of a union are always active.

Right? The cited use case is undefined behavior.

Actually I can't think of a single realistic use case for this; despite the constant trumpeting of C++ folks on how constexpr will save C++, constant expressions are just too limited for this to matter.

Re: C++26: Std:Is_within_lifetime

#50

Post by anematode »

PaulDavisThe1st wrote: post #41
Blackthorn wrote: post #33

Earlier quoted context omitted.

We find constexpr (and associated templates) essential for when we need to avoid branch penalties. It makes the code so much simpler and cleaner than the alternative. I'm glad the language caters to the needs of everyone, even if any individual person (self included) only uses a little bit of it.

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 the branch predictor, and it's quite common that these conditions will correlate with different branch frequencies in the surrounding. code.
Post reply on HN