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

Three new utility functions in C++23

mariusbancila.ro

Post reply on HN
Print view View original

21–30 of 196 posts

Re: Three new utility functions in C++23

#21

Post by fluoridation »

actionfromafar wrote: post #13
CJefferson wrote: post #11

I understand why it's there, but I do find it fun that when many people are trying to reduce undefined behaviour in their code, std::unreachable is literally defined as "this is undefined behaviour, use that to optimise". I suspect 99.9% of uses of std::unreachable would be better replaced by abort. (There will be those times when the code is correct and the optimisation gains are worth it -- but they will be rare).

+100 I felt physically ill when I read: It’s intended to be used when you know you have an execution path in your code that cannot be reached but the compiler cannot figure that out. It felt like saying to the compiler, "please, find a way to make my program break even more easily". Exactly not what I need.

If a code path that's supposed to be unreachable is reached then the program is already broken. Unless it has a bug, a compiler will not make a program more broken. At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

Re: Three new utility functions in C++23

#22

Post by apaprocki »

Karellen wrote: post #15
yrro wrote: post #6

Hmm. How often do people actaully want to std::byteswap as opposed to "convert this value from native byte order to big-endian" or "convert this value from little-endian to native byte order"? i.e., the functions documented in https://man7.org/linux/man-pages/man3/endian.3.html (why oh why are they not also documented in the GNU C Library Manual...)

Yeah, for portable code you also need a function to tell you if you're on an architecture where you need to do a byteswap for the data you have. e.g. you know you have data in little-endian format - do you need to swap it to work with it natively? That depends. Maybe having something like convert_be() and convert_le(), one of which is a no-op and the other does the byteswap (depending on your arch) would be better. I…

I view it more as a platform-independent building block to be used by library authors. For instance, here's our suite of byte order macros that this will not simply replace:

https://bloomberg.github.io/bde-resources/doxygen/bde_api_pr...

Re: Three new utility functions in C++23

#23

Post by actionfromafar »

fluoridation wrote: post #21
actionfromafar wrote: post #13

Earlier quoted context omitted.

+100 I felt physically ill when I read: It’s intended to be used when you know you have an execution path in your code that cannot be reached but the compiler cannot figure that out. It felt like saying to the compiler, "please, find a way to make my program break even more easily". Exactly not what I need.

If a code path that's supposed to be unreachable is reached then the program is already broken. Unless it has a bug, a compiler will not make a program more broken. At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

Yes, but what was unreachable may get reachable as I do changes to the program. I see the utility when doing highly optimized library code.

But for my purposes I much prefer to stick something which flags me (exception or logging or whatever) of "this should never happen" instead of crashing. (Undefined.)

Re: Three new utility functions in C++23

#25

Post by assbuttbuttass »

fluoridation wrote: post #21
actionfromafar wrote: post #13

Earlier quoted context omitted.

+100 I felt physically ill when I read: It’s intended to be used when you know you have an execution path in your code that cannot be reached but the compiler cannot figure that out. It felt like saying to the compiler, "please, find a way to make my program break even more easily". Exactly not what I need.

If a code path that's supposed to be unreachable is reached then the program is already broken. Unless it has a bug, a compiler will not make a program more broken. At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

It's undefined behavior. The compiler is free to do whatever, including making your program more broken.

Re: Three new utility functions in C++23

#26

Post by apaprocki »

actionfromafar wrote: post #13
CJefferson wrote: post #11

I understand why it's there, but I do find it fun that when many people are trying to reduce undefined behaviour in their code, std::unreachable is literally defined as "this is undefined behaviour, use that to optimise". I suspect 99.9% of uses of std::unreachable would be better replaced by abort. (There will be those times when the code is correct and the optimisation gains are worth it -- but they will be rare).

+100 I felt physically ill when I read: It’s intended to be used when you know you have an execution path in your code that cannot be reached but the compiler cannot figure that out. It felt like saying to the compiler, "please, find a way to make my program break even more easily". Exactly not what I need.

One thing people are missing is that you may need to use this to satisfy conditions that the compiler might encounter to emit a warning (or error if equivalent of -Werror is enabled). If you have strict warnings on, but no way to tell the compiler that a location should not be reachable, you wind up in situations where you are doing something like `assert(!"not reached!")` and it won't be enabled in all build types. This is similar to how `__attribute__((noreturn))` is used in a "fatal" function that isn't always enabled but needs to convey its intention to static analyzers so that they stop evaluating branches past that call.

Re: Three new utility functions in C++23

#27

Post by unnah »

dontlaugh wrote: post #8
halayli wrote: post #7

Earlier quoted context omitted.

That's not a good advice. Only if the sender and receiver are guaranteed to be running on little endian architecture you can make such a claim. A better advice is to always consider the endian-ness when designing protocols and have a strategy to handle it.

I think they mean for any new protocol, defining it as little-endian.

You could call it the krowten byte order.

Re: Three new utility functions in C++23

#28

Post by fluoridation »

assbuttbuttass wrote: post #25
fluoridation wrote: post #21

Earlier quoted context omitted.

If a code path that's supposed to be unreachable is reached then the program is already broken. Unless it has a bug, a compiler will not make a program more broken. At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

It's undefined behavior. The compiler is free to do whatever, including making your program more broken.

If you have undefined behavior, your program is already broken. No such thing as "more broken"; there's already no theoretical limit to what might happen if it gets triggered.

Re: Three new utility functions in C++23

#29

Post by apaprocki »

suyjuris wrote: post #20
CJefferson wrote: post #11

I understand why it's there, but I do find it fun that when many people are trying to reduce undefined behaviour in their code, std::unreachable is literally defined as "this is undefined behaviour, use that to optimise". I suspect 99.9% of uses of std::unreachable would be better replaced by abort. (There will be those times when the code is correct and the optimisation gains are worth it -- but they will be rare).

You can compromise by using abort in debug builds and std::unreachable in release builds.

The point of this is that you can control that behavior at the compiler level using different flags instead of changing the code itself (via preprocessor defines).

Re: Three new utility functions in C++23

#30

Post by JonChesterfield »

suyjuris wrote: post #20
CJefferson wrote: post #11

I understand why it's there, but I do find it fun that when many people are trying to reduce undefined behaviour in their code, std::unreachable is literally defined as "this is undefined behaviour, use that to optimise". I suspect 99.9% of uses of std::unreachable would be better replaced by abort. (There will be those times when the code is correct and the optimisation gains are worth it -- but they will be rare).

You can compromise by using abort in debug builds and std::unreachable in release builds.

I love it when switching debug mode on changes the control flow graph of my program. Keeps life interesting.
Post reply on HN