All I took away from this is how more and more complicated C++ as a language becomes to make the syntax slightly more convenient.
Yes, you can fix issues like this with a "hard fork" if you have a large enough consensus, but at that point, does the system of having smart contracts actually improve anything over the one where the software is downstream rather than the source of truth, or are you just replacing one form of "human intervention required" with a different but worse one?
You can usually pick the jurisdiction (e.g. many contracts are under jurisdiction of England & Wales/Switzerland/Singapore despite neither party being based there, or doing business there).
I think in general judges are quite considered, and the answers you get from courts tend to make quite a lot of sense, especially if you are aware of general legal principles and precedent.
You could argue that the latter is the core drive to evolve the standard.
You should always do extensive testing before upgrading.
How much longer will you suffer?
And note this is about an older compiler version using an older library with a “newer” language spec (ie been around 5 years). If you use up to date toolchains there’s less of an issue. This is yet another perennial weakness in the c++ ecosystem that isn’t present in other languages because the standard committee continues to abrogate their duties here.
Most languages deal with this by limiting the features they have - but not C++! (or Scala, which is like Java's C++)
Add Boost to the mix, as in this bug, and C++ becomes quite ludicrous really, but it can also combine efficiency, interoperability, and performance in a way that's quite difficult to achieve in other languages.
IMO, starting a good C++ project is an exercise in defining a specific language based on a subset of C++ more than anything else: done right, it can be a big lever, done wrong, it can be a big foot-gun.
Making anything remotely useful out of templates was deeply into hideous SFINAE-land (substitution-failure-is-not-an-error) leading to horrible unreadable templates during 98 (and the variable-number templates in 11 while being useful only made it explode in horrendeous hacks).
"if constexpr" from C++ 17 and forward actually makes template-expansions not too horrid. you can do template expansions that reads mostly like regular if-elseif-else clauses (and I think that was perhaps part of the impetus for Zig's comptime, starting from this point with a clean slate instead of going through regular template evolution hell).
I haven't seen an example yet, where concepts weren't simpler and easier to read/understand than SFINAE shenanigans.
But also, since the referenced bug involves Boost... I also haven't used Boost in years, since most everything I was using got pulled into modern C++ versions/STLs.
So if you're using C++98 and Boost, do yourself a favor and just switch to C++17 or 20 or whatever.
The MAGA version.
G++ has to emit code here to recurse infinitely, so it's not as though there's no opportunity to say "Huh, that probably won't be what they meant"
So the overall story is mostly "Our QA is garbage".
> In C++, when you write an expression like a == b, the compiler chooses among available operator== implementations by comparing their match quality. A member function like a.operator==(b) usually has higher priority than a non-member function like operator==(a, b) — unless the types differ too much or are ambiguous.
This is the largest foot-bazooka ever. The point of operator overloading is that the operator in a given expression look natural, feel natural, and behave naturally (= function intuitively). If you have multiple possible operators that could apply, for the same syntax, then you're in a worse position than you originally were -- where an operator either did one particular thing, or didn't apply at all. What operator overloading does in practice is introduce ambiguity. Which is self-defeating. You are better off with C-style, named, non-overloaded functions.
You will never find this crap in actual math. "match quality" my ass.
Sure you do. What’s 6/2(1+2)