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

121–130 of 196 posts

Re: Three new utility functions in C++23

#121

Post by addaon »

flohofwoe wrote: post #42
a2800276 wrote: post #36

My first impression is that all three of these are clutter to an already very cluttered language ... 1.) Coming from embedded programming, I can see the utility of `std::unreachable`. But shouldn't this be a compiler directive? Or a standardized #pragma? Can someone more knowledgeable in C++ say whether using functions as markers is a common mechanism in std:: ? 2.)Maybe the example is bad here, as it doesn't even sa…

> ...`std::unreachable`. But shouldn't this be a compiler directive? Probably "committee pragmatism", a stdlib change might be easier to get approved than a language change, and compilers already have builtins for this, they're just not compatible (but the differences can be wrapped in a macro, and since C++ doesn't like to expose macros, it's probably still a macro, but hidden inside a stdlib template). FWIW it look…

std::unreachable() feels like it's what std::assert(false) should be, except that std::assert(false) is bizarrely defined (as a no-op) when NDEBUG is defined. This is one of those strange cases where the spec defines behavior that I'd strongly expect to be undefined.

Re: Three new utility functions in C++23

#122

Post by s28l »

addaon wrote: post #119
s28l wrote: post #111

Earlier quoted context omitted.

I meant that they are processed before any syntactical analysis, so they're not particularly useful for this kind of thing. For example, these are all wrong usages of our hypothetical `#pragma unreachable`: void foo(); #pragma unreachable class bar { #pragma unreachable }; namespace foobar { #pragma unreachable } But pragmas can generally be used anywhere, barring tokenization issues. The end result is that `pragma u…

This is the intent and purpose of _Pragma; it provides a way to use existing #pragmas that are tokenized and handled a bit later, so they can e.g. be included in macro expansions.

I think the only benefit of `_Pragma` is that it enables defining a macro that expands into a `#pragma` definition. I don't think there's any other use case beyond that.

Re: Three new utility functions in C++23

#123

Post by legends2k »

einpoklum wrote: post #31
gpderetta wrote: post #9

Earlier quoted context omitted.

I always worry as much as anyone else on each new release for the additional complexity ("the committee is out of control!!!!1!!eleven!"), but on each compiler upgrade when I actually get to use the new versions of the standard I'm always pleasantly surprised about all the little low-key quality of life improvements.

While that's true, when you get to a point where you have to write a small library - so that you need to cater to all of the language and standard additions - that's when you start experiencing pain. How do I expose the right iterators and sentinels? What do I have to specialize? Do I need to define concepts? Do I need to use concepts from elsewhere? I am often at a loss...

While this is true to some extent, trying to be overly generic and solving for all cases is the root of the analysis-parslysis. I end up solving just the part that's needed for the problem in hand but accepting meaningful compromises and trade offs when faced with this issue.

Re: Three new utility functions in C++23

#124

Post by eco »

dahfizz wrote: post #71
actionfromafar wrote: post #23

Earlier quoted context omitted.

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.)

In a real codebase, this would be wrapped by a macro to abort in a debug build but gain the optimizations in a release build.

cppreference suggests this as an implementation for std::unreachable but as near as I can tell neither clang nor MSVC does that (yet?).

Re: Three new utility functions in C++23

#125

Post by fooker »

agluszak wrote: post #72

> A typical use case for this function are switch statements on a variable that can take only a limited set of values from its domain. For instance, an integer that can only be between 0 – 9. Here is a simple example with a switch that checks a char value and executes operations. Only a limited number of commands are supported but the argument is checked before invoking the function so it shouldn’t be possible to rec…

Okay, what about when you are writing the parser?

Re: Three new utility functions in C++23

#126

Post by simplotek »

s28l wrote: post #47
a2800276 wrote: post #36

My first impression is that all three of these are clutter to an already very cluttered language ... 1.) Coming from embedded programming, I can see the utility of `std::unreachable`. But shouldn't this be a compiler directive? Or a standardized #pragma? Can someone more knowledgeable in C++ say whether using functions as markers is a common mechanism in std:: ? 2.)Maybe the example is bad here, as it doesn't even sa…

1. It is a compiler defined function (`__builtin_unreachable()`), but the issue is that MSVC doesn't have it, so you need a different implementation per compiler [0]. Plus, if a new compiler shows up (besides MSVC/GCC/LLVM), you'd need to investigate what the correct way to express `__builtin_unreachable` is. From a compiler perspective, using a function makes the most sense, since that fits into the existing control…

> Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.

I don't thing this is remotely true. C++ pragmas were designed with the express purpose of providing additional information to compilers.

Re: Three new utility functions in C++23

#127

Post by actionfromafar »

dahfizz wrote: post #71
actionfromafar wrote: post #23

Earlier quoted context omitted.

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.)

In a real codebase, this would be wrapped by a macro to abort in a debug build but gain the optimizations in a release build.

Can't help but feel offended that my codebase isn't real. Thanks for the laugh though :-D

I'd rather have solid logging and/or abort handling than some extra yak hairs shaved off the speed on my release builds. I'm weird that way.

Re: Three new utility functions in C++23

#128

Post by cesarb »

s28l wrote: post #47
a2800276 wrote: post #36

My first impression is that all three of these are clutter to an already very cluttered language ... 1.) Coming from embedded programming, I can see the utility of `std::unreachable`. But shouldn't this be a compiler directive? Or a standardized #pragma? Can someone more knowledgeable in C++ say whether using functions as markers is a common mechanism in std:: ? 2.)Maybe the example is bad here, as it doesn't even sa…

1. It is a compiler defined function (`__builtin_unreachable()`), but the issue is that MSVC doesn't have it, so you need a different implementation per compiler [0]. Plus, if a new compiler shows up (besides MSVC/GCC/LLVM), you'd need to investigate what the correct way to express `__builtin_unreachable` is. From a compiler perspective, using a function makes the most sense, since that fits into the existing control…

> `htonl` are not standardized

They are: https://pubs.opengroup.org/onlinepubs/9699919799/functions/h...

Re: Three new utility functions in C++23

#129

Post by ogoffart »

cesarb wrote: post #128
s28l wrote: post #47

Earlier quoted context omitted.

1. It is a compiler defined function (`__builtin_unreachable()`), but the issue is that MSVC doesn't have it, so you need a different implementation per compiler [0]. Plus, if a new compiler shows up (besides MSVC/GCC/LLVM), you'd need to investigate what the correct way to express `__builtin_unreachable` is. From a compiler perspective, using a function makes the most sense, since that fits into the existing control…

> `htonl` are not standardized They are: https://pubs.opengroup.org/onlinepubs/9699919799/functions/h...

Yeah, but that's platform-specific. It's not part of the C or the C++ standard library.

Re: Three new utility functions in C++23

#130

Post by addaon »

patrec wrote: post #10
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.

How is that "better advice"? Big endian architectures are pretty much dead (x86, ARM and RiscV are all little endian; some ARM chips are bi-endian, but not Apple's) and there's no discernible compelling advantage that would allow a comeback. You absolutely want to specify the byte order in new protocols as little endian.

There are still big-endian-only ARM chips out there, and some of them are basically the only processors in their class (TMS570 in particular); while I wish they were bi-endian, big endian platforms are still alive and well.
Post reply on HN