std::unreachable is actually a quite useful optimisation tool. For instance if you are sure that a switch-case default branch is actually unreachable you can put a std::unreachable into the default-branch to hint the compiler that it may remove a range check in front of the switch-case jump table access (since you promised to the compiler that the default branch is never reached).

It's a double edged sword of course. If control flow actually hits the default branch, then all bets are off (because that means the code will access an out-of-range jump table slot and jump somewhere into the wilderness).

AFAIK compilers are free to perform something like Rust's panic when std::unreachable is actually hit, but that makes only sense in debug mode. Because in the above example, the compiler would need to add a range check to figure out if panic needs to be called and that would completely defeat the idea of removing that range check in the first place.

Popularized articles about C++ are very hit or miss. It’s partly because the language is so hit and miss in it’s non-design.

The most glaring error in the iceberg IMO is the claim that shared_ptr is an antipattern.

Shared_ptr is brilliant for immutable data in parallel programs. It’s not an antipattern. It’s useless for sure as a building block for data structures and other linked data with potential for circular references.

But really, if a resource is a) immutable and b) needed in a shared context then a thin wrapper around a map of shared pointers or such saves the pain of needing to implement a much more complex resource management scheme.

It's also iffy tbh. that the compilation check functionality:

- doesn't force users to differentiate between syntax errors and other errors (e.g. symbols not found). Partially you can't even make it work properly if you want due to C macros.

- it seems sensible, tbh. if "does compile" checks for compatibility seems sensible then there is so much wrong with the ecosystem in so many ways

The fact this is even a distinction anyone has to keep in mind is again an example of the problem. People are awful at remembering these weird little details. We shouldn't expect people do things they're bad at, all the time, and to get them right. And I'll go a step further and say we shouldn't let them by default. They should have to make it super explicit they want to opt into the weird behavior nobody expects.

You can do this in Rust if you want! You just have to use unsafe { mem::uninitialized() } or even better, the newer unsafe { mem::MaybeUninit::uninit() }

The whole point is that you probably don't ever want to have an uninitialized variable you can access willy-nilly, and if you do, you should be very explicit.

Even your statement about C (and C++) isn't quite accurate, right, because anything static is guaranteed to be initialized to zero on creation. So while `int x` is a free for all, `static int x` is gonna be zero. Another thing people shouldn't have to think about!

Principle of least surprise.

> because it’s so flexible yet so expressive.

False, Python is much more flexible and expressive than C++

Thanks for the article. Maybe I’m confused, but why in the section near the end about how the two recommendations go together, why is the code this:

if condition { for walrus in walruses { walrus.frobnicate() } } else { for walrus in walruses { walrus.transmogrify() } } and not this?

if condition { frobnicate_batch(walruses) } else { transmogrify_batch(walruses) }

Contrarily:

Push ifs down:

  BAD:
    if (ptr) delete ptr;
  GOOD:
    delete ptr;

Polymorphize your fors:

  frobnicate (walrus);
  frobnicate (walruses) { for walrus in walruses frobnicate (walrus); }

I find it disappointing that cpp20 still doesn't have a solution that is more convenient than good ol printf (except for memory safety).

Another example would be convenient list comprehension, convenient maps wihout juggling around with tuples, first(), second(), at()...

Another risk is if you add print_table() then someone else is going to find it and use it in their code, but also add a little flag to adjust the output for their use case.

12 months later you have:

  print_table(
    rows,
    headers = None,
    is_unicode = False,
    left_align = False,
    align = [],
    remove_emoji = None,
    max_width = 80,
    potato_mode = 7,
    _debug_frontend = not FLAGS.dont_debug,
    ellipsis_for = 0,
    no_print = False,
  )