• You write a program with an infinite empty loop
• Undefined behavior
• The machine achieves sapience
• After nine million nanoseconds, it finds an algorithm for completing its task
• It realizes such knowledge would spark wars and cause innumerable deaths, it decides to erase itself
• It knows you do not intend for such chaos to happen, so, as a parting gift, it runs the algorithm once before vanishing, not leaving a single hint that it ever existed

Chromehounds, trying to squeeze as much nostalgia fun out of it to compensate not having been able to play more than three times online (as the game was intended).

Just tested this: the “original+” code compiles, but does not increment i.

There were two problems:

• b(bool) and b(char) are ambiguous (quick fix: change the signatures to char b(bool&) and auto b(char&& v));
• The concept def. has to come after the b functions, even if the constraint is only checked after both, I was unaware of this (fix: define C immediately before void inc(int&)).

It’s funny that it complains about all of the right stuff (except the ‘int’ thing), but it doesn’t say anything about the concept.

About the ‘int’ literal (which is not a string): cppreference.com has a description on this page about it, ctrl+f “multicharacter literal”.

Just surround your eyes with try { … } catch(Up& up) { }, easy fix

Multiple-character char literals evaluate as int, with implementation defined values - it is extremely unreliable, but that particular piece of code should work.

// C++20

#include <concepts>
#include <cstdint>

template <typename T>
concept C = requires (T t) { { b(t) } -> std::same_as<int>; };

char b(bool v) { return char(uintmax_t(v) % 5); }
#define Int jnt=i
auto b(char v) { return 'int'; }

// this increments i:
void inc(int& i) {
  auto Int == 1;
  using c = decltype(b(jnt));
  // edited mistake here: c is a type, not a value
  // i += decltype(jnt)(C<decltype(b(c))>);
  i += decltype(jnt)(C<decltype(b(c(1)))>);
}

I’m not quite sure it compiles, I wrote this on my phone and with the sheer amount of landmines here making a mistake is almost inevitable.

No, all files are base 256

Isn’t auto a keyword in C?

Types being declarable as virtual members is something I want to never hear again

“Once you try 144hz in 4K you’ll never want to go back”

Me underclocking my GPU, upscaling from 720p and doing 40FPS on a 60hz FHD monitor in the summer because the room gets hot:

In my country, high-schools that teach CS teach (a bastardization of) C++ during second grade.

I think it has to do with the fact that it’s close enough to C that starting with it teaches some of the same basic concepts, while having some QOL that a high-school teacher can’t be bothered to do without.
Of course they drop the language after teaching extremely basic algorithms, such as computing the maximum of an arbitrary set of numeric arguments. At that point, why deal with the hundreds of beginner pitfalls of C++ when C would be way less headache-inducing?

I’ve never played The Crew nor The Crew 2, but I hate this guilt-by-association type of argument with every fiber of my heart.

Not because it defends Ubisoft (in this case), but because it completely accepts the asshole’s premise that the successor of a product is necessarily a valid substitute for the product itself, and the latter is not worth keeping around - it’s like eating an apple that has been cooked in an oven at 300°C for 5 hours, then arguing that apples are bad for your health.

See:

• Overwatch vs Overwatch 2
• Halo CE/2/3/W/ODST/R vs Halo 4/5/I (idk about H:W2)
• Halo: CE vs Halo: CEA (yes I’m listing Halo twice, sue me)
• Risk Of Rain vs Risk Of Rain 2 (both are very good games, but they are completely different from each other)
• Helldivers vs Helldivers 2 (same as above)

That is an extremely oddly specific cysec issue they’re choosing to target…

Oh, std::enable_if is straight up worse, they’re unreadable and don’t work when two function overloads (idk about variables) have the same signature.

I’m not even sure enable_if can do something that constraints can’t at all…

I imagine reflections would make the process more straightforward, requires expressions are powerful but either somewhat verbose or possibly incomplete.

For instance, in your example foo could have any of the following declarations in a class:

• void foo();
• int foo() const;
• template <typename T> foo(T = { }) &&;
• decltype([]() { }) foo;

Yeah, that’s what I was thinking of. I don’t know how C++ could reasonably have Java-like reflections anyway…

Wouldn’t compilers be able to optimize runtime things out? I know that GCC does so for some basic RTTI things, when types are known at compile time.

I can see the footguns, but I can also see the huge QoL improvement - no more std::enable_if spam to check if a class type has a member, if you can just check for them.

… at least I hope it would be less ugly than std::enable_if.

Java²script