[pmarin]

auto, constexpr: Kill them with fire.

unreachable. No when the optimizer compiler can f*#k up my code if you combine it with unintended undefined behaviur. I just use asser(0) in debug builds. Not kidding.

[flohofwoe]

Unreachable is a quite important optimization hint (note how the 'blub()' function removes a range check because of the unreachable in the default branch):

https://www.godbolt.org/z/Ph8PY1drc

[pmarin]

I know it, but if you have a bug that reach the Unreachable path the compiler can't tell you anything. that is why I use assert(0) in debug builds.

[dzaima]

And you can easily do a macro check and define a custom thing that's either assert(0) or unreachable() depending on the build type. But you still need unreachable() to exist to do that. (and under -fsanitize=undefined you get an error for unreachable() too)

[peterfirefly]

And you can effectively do both:

    #ifdef NDEBUG
    #  define UNREACHABLE()   unreachable()
    #else
    #  define UNREACHABLE()   assert(0)
    #endif

That's what I have been doing for years, except with __builtin_unreachable()... and __assume(0) if I bothered to make it work under MSVC.

[pmarin]

And why this is not the default behaviur?

I am pretty sure many users are going to think it is correctness check an not an optimization attribute.

[dzaima]

I'd rather not have a basic feature be put behind needing to define an arbitrary NDEBUG; having to define your debugging setup around NDEBUG would not fit some things - e.g. in my case I'd end up having to always define NDEBUG, and continue with my own wrapper around things. (with <assert.h> you have the option of writing your own thing if you don't like its NDEBUG check, which is what I do; with unreachable(), if you literally cannot get its functionality other than NDEBUG, you're stuck with NDEBUG).

[peterfirefly]

Because C is a "do exactly as I say" language.

[astrange]

It can, just turn on UBSan.

[peterfirefly]

unreachable() is just the standardized form of __builtin_unreachable() (gcc/clang) and __assume(0) (MSVC).

I often have a macro called UNREACHABLE() that evaluates to assert(0) or __builtin_unreachable() depending on NDEBUG.

It improves the generated code a bit.

One trick one can use is to define ASSERT() as a wrapper around assert() or something like

    do { if (!x) unreachable(); } while (0)

This is a really nice way to tell the compiler about invariants -- and generate better code (and better warnings!).

There are no fuck ups involved. None.

constexpr is great because it reduces the need for macros. There are three features that make almost all macro use unnecessary. They are enums, inline, and constexpr. Good enough inline support has only really been available for a few years -- by "good enough", I mean "doesn't slow down CPU emulator code".

Things are really looking up for C, in my view.

[dale_glass]

What's wrong with constexpr?

[pmarin]

Its a crippled form of code generator in an era where compile time execution is suported by many modern system languages.

But I don't like any of them. I prefer to write my own code generators.

[klodolph]

C doesn't have that version of constexpr. In C2x, constexpr is just a way to define constants, like

  constexpr unsigned long long kMyBigNum = 0x1234123412341234ull;

Previously, you had to #define. Using enum causes problems when it doesn't fit in an int. And const doesn't mean the right thing:

  const int kArraySize = 5;

  void MyFunction(void) {
    int array[kArraySize]; // NO!
  }

The above function will work if you have VLAs enabled, or if your compiler specifically allows for it. It's nice to have a standardized version that works everywhere (VLAs don't work everywhere).

[flohofwoe]

Constexpr in C is essentially what const should have been, it's not as "powerful" as the C++ version.