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

131–140 of 196 posts

Re: Three new utility functions in C++23

#131

Post by addaon »

overgard wrote: post #37
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.

There are practically no big endian architectures anymore. Little endian is a sensible default. The weird architectures should bare the burden of complexity.

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.

Re: Three new utility functions in C++23

#132

Post by kevin_thibedeau »

simplotek wrote: post #126
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…

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

Attributes are better suited for that. #pragma has always just been a grandfathered in hack.

Re: Three new utility functions in C++23

#133

Post by [deleted] »

kevin_thibedeau wrote: post #132
simplotek wrote: post #126

Earlier quoted context omitted.

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

Attributes are better suited for that. #pragma has always just been a grandfathered in hack.

[deleted]

Re: Three new utility functions in C++23

#134

Post by gpderetta »

legends2k wrote: post #123
einpoklum wrote: post #31

Earlier quoted context omitted.

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.

Premature generalisation is the root of all evil.

According to Stepanov generalisation is something you are supposed to discover as you develop a program, not something you do from first principles.

Re: Three new utility functions in C++23

#135

Post by pjscott »

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…

I checked LLVM's libc++ source, and it's an inline void function defined in a header, which contains only a call to __builtin_unreachable() when available or std::abort() otherwise.

Re: Three new utility functions in C++23

#138

Post by DougBTX »

fluoridation wrote: post #39
DougBTX wrote: post #35

Earlier quoted context omitted.

> At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious. An abort would make them obvious, surely unreachable makes them less obvious?

The point is that you're telling the compiler "I don't care what happens if control reaches here. Assume it never will and use that information to better optimize the rest". It's not an alternative to abort() or throwing because the compiler still needs to generate code for them.

Yes, that’s what I mean, the compiler can completely remove a branch which is unreachable, along with any checks. If it was forced to keep the checks and report an error instead, any bug would be more obvious. If the compiler removes checks for bugs, then the application could silently continue, obscuring the bug.

So this is a “hide bugs but maybe improve performance” function.

Re: Three new utility functions in C++23

#139

Post by klyrs »

donatj wrote: post #43

Silly question from someone who hasn’t written C++ in 20 years and only very vaguely remembers it - if a code path is unreachable, why have the path at all? Is a default on a switch required? Is lack thereof a compiler warning or something? It’s been a very long time; I only ever seem to recall that kind of “all paths must be handled” from functional languages.

It comes up from time to time, for example sometimes you'll have a big enum where most of the values can be handled in a straightforward way, and things are weird and complex for the other values. So you write something like

    int process(my_enum x, state_t state) {
        if (x == my_enum::COMPLICATED) return do_stuff(state);
        switch (x) {
           case my_enum::SIMPLE0: return 0;
           case my_enum::SIMPLE1: return 1;
           case my_enum::SIMPLE2: return 2;
        }
    }
and your compiler complains that my_enum::COMPLICATED isn't handled, even though it clearly was. You generally like these warnings, because they do keep you safe, but in this case, you're smarter than the compiler, but it forces you to put something there. With std::unreachable, it will squelch the warning and not emit extra code. For example, you might be tempted to throw an error -- but if nothing else in the function throws, you end up emitting a bunch of unreachable error-handling code that the compiler can't remove.

Re: Three new utility functions in C++23

#140

Post by int_19h »

addaon wrote: post #121
flohofwoe wrote: post #42

Earlier quoted context omitted.

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

What's bizarre about asserts being disabled if you explicitly ask for it?
Post reply on HN