5 ms·

All I took away from this is how more and more complicated C++ as a language becomes to make the syntax slightly more convenient.

twoodfin 1y ago
It’s less about convenient syntax and more about simplifying the construction of abstractions. You could argue that the latter is the core drive to evolve the standard.
immibis 1y ago
It's not slightly, it's substantially more complicated to become substantially more convenient. The leap from C to C++ is similar to the leap from assembly code to C. As you add features, the language becomes more complex. That's just how it is. Most languages deal with this by limiting the features they have - but not C++! (or Scala, which is like Java's C++)
- bri3d 1y ago
  This is a perfect summary of C++: substantially more complicated for substantial convenience. 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.
  - ranger_danger 1y ago
    You don't have to use all the fancy new features though. Personally I just stick to C++98 for the most part, unless I really want to use auto or lambdas for some reason, then I might use 11, but I won't go higher.
    - bdhcuidbebe 1y ago
      Ah yea, why not settle with the 14 year old version? The MAGA version.
    - whizzter 1y ago
      C++ 11 with lambdas is so much nicer than 98, but even if 14, 17, 20 and 23 have been minor in comparison the accumulated changes have been radical in making what was introduced in 11 into something really useful. 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).
      - jeffbee 1y ago
        The horrendous hacks went away with concepts. SFINAE is dead. Spaceship operator, while perhaps not ideal from every perspective, radically simplifies the workload of implementing comparators.
        saagarjha 1y ago
        Assuming the thing you want actually has a concept, sure.
        majoe 1y ago
        You can define your own concepts. What is your point? I haven't seen an example yet, where concepts weren't simpler and easier to read/understand than SFINAE shenanigans.
        jeffbee 1y ago
  - tialaramex 1y ago
    If we make the underlying mistake in Rust (actually I did last week for unrelated code) by defining an operator implementation as simply calling itself rather than calling some concrete implementation, the compiler warns us, this is infinite recursion which probably wasn't what you wanted. 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"
    - jcelerier 1y ago
      C++ compilers had warnings about infinite recursion for years now (since at least 2015 for clang)
      - tialaramex 1y ago
        Fair. That's actually crazy - I dug into this more and found the chosen Boost package fails tests on the chosen compiler, and so if they'd done even a cursory check to see if what they're doing could make sense there'd be red flags everywhere. So the overall story is mostly "Our QA is garbage".
        saalweachter 1y ago
        If it's at the "we never compile with -Wall -Werror" level of non-existent QA, I feel like that's an insult to garbage.
        tialaramex 1y ago
        -Wall -Werror means that instead of being able to be used as a ratchet the set of "all" warnings in C and C++ became rusted in place. I sympathise with the instinct to write this in your compiler flags, but alas thanks to Hyrum's law this makes the future worse and so today people ask that you -Wextra and no doubt I'll eventually read of how C is fine so long as you -Wall -Wextra -Wevenmore -Wyetmore -Wandthese
  - userbinator 1y ago
    It becomes substantial inconvenience as soon as you need to try to figure out why something doesn't work the way you thought it should.
- wavemode 1y ago
  Scala has the advantage (and disadvantage) of not caring one lick about backwards compatibility. They were perfectly happy to burn it all to the ground and redo the language's syntax in v3. And even point releases of Scala frequently have breaking changes.
  - seanhunter 1y ago
    I respect that, but kind of lost patience with it when a new version of the compiler decided that my types were no longer decidable in code that hadn’t been touched for years. I tried for about 5 mins to fix it and then just thought “It’s not me, it’s you” and put scala down never to pick it up again.
- vlovich123 1y ago
  I have observed significantly better useful features from Rust or Swift (or Scala) without horribly complicating the language like C++ does. More importantly, they migrate existing codebases and have migration tools instead of breaking old versions of syntax. Rust’s is the most ambitious here letting you mix match editions of the language within a single binary.
mgaunard 1y ago
Every new version of C++ (and sometimes even new versions of C++ compilers) can break code in subtle ways. You should always do extensive testing before upgrading.
- reactordev 1y ago
  That’s the crux of the issue. People fear upgrading because of the bugs introduced by more complexity for more terse syntax. How much longer will you suffer?
  - mgaunard 1y ago
    The same is true for any software. If you care about reliability, you pin, and carefully test before upgrading.
- vlovich123 1y ago
  I have not observed the same with other languages, whether that’s Java, Rust, or Swift. 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.
saghm 1y ago
I get as exasperated at C++ as anyone else, but IMO there's another takeaway here, which is that smart contracts are an absolutely terrible idea. Relying on code as the source of truth for a transaction just completely disregards the reality that code is always going to be buggy. For those who might not be aware, this is the same smart contract framework where someone accidentally killed $300 million of transactions because a function in a library for setting the wallet associated with a private key was defined as public instead of private: https://medium.com/cybermiles/i-accidentally-killed-it-and-evaporated-300-million-6b975dc1f76b https://medium.com/cybermiles/i-accidentally-killed-it-and-e... 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?
- usmannk 1y ago
  This is about a language compiler bug. There are no takeaways about smart contracts here.
  - tsujamin 1y ago
    So long as you’re writing your smart contracts with a chisel, into a stone tablet, with no compilers or assemblers in sight!
    - tkz1312 1y ago
      The bug was a simple segfault and did not result in the production of invalid or incorrect code.
      - saghm 1y ago
        Segfaults are the lucky case when you run into undefined behavior. The unlucky case is that you just get a program doing something different than what you intended without any clear indication that something went wrong.
DokDidhuAd 1y ago
Yeah, C++ is just batshit insane. > 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.
- maccard 1y ago
  > You will never find this crap in actual math Sure you do. What’s 6/2(1+2)

twoodfin 1y ago

It’s less about convenient syntax and more about simplifying the construction of abstractions. You could argue that the latter is the core drive to evolve the standard.

immibis 1y ago

It's not slightly, it's substantially more complicated to become substantially more convenient. The leap from C to C++ is similar to the leap from assembly code to C. As you add features, the language becomes more complex. That's just how it is. Most languages deal with this by limiting the features they have - but not C++! (or Scala, which is like Java's C++)

bri3d 1y ago
This is a perfect summary of C++: substantially more complicated for substantial convenience. 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.
- ranger_danger 1y ago
  You don't have to use all the fancy new features though. Personally I just stick to C++98 for the most part, unless I really want to use auto or lambdas for some reason, then I might use 11, but I won't go higher.
  - bdhcuidbebe 1y ago
    Ah yea, why not settle with the 14 year old version? The MAGA version.
  - whizzter 1y ago
    C++ 11 with lambdas is so much nicer than 98, but even if 14, 17, 20 and 23 have been minor in comparison the accumulated changes have been radical in making what was introduced in 11 into something really useful. 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).
    - jeffbee 1y ago
      The horrendous hacks went away with concepts. SFINAE is dead. Spaceship operator, while perhaps not ideal from every perspective, radically simplifies the workload of implementing comparators.
      - saagarjha 1y ago
        Assuming the thing you want actually has a concept, sure.
        majoe 1y ago
        You can define your own concepts. What is your point? I haven't seen an example yet, where concepts weren't simpler and easier to read/understand than SFINAE shenanigans.
        jeffbee 1y ago
- tialaramex 1y ago
  If we make the underlying mistake in Rust (actually I did last week for unrelated code) by defining an operator implementation as simply calling itself rather than calling some concrete implementation, the compiler warns us, this is infinite recursion which probably wasn't what you wanted. 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"
  - jcelerier 1y ago
    C++ compilers had warnings about infinite recursion for years now (since at least 2015 for clang)
    - tialaramex 1y ago
      Fair. That's actually crazy - I dug into this more and found the chosen Boost package fails tests on the chosen compiler, and so if they'd done even a cursory check to see if what they're doing could make sense there'd be red flags everywhere. So the overall story is mostly "Our QA is garbage".
      - saalweachter 1y ago
        If it's at the "we never compile with -Wall -Werror" level of non-existent QA, I feel like that's an insult to garbage.
        tialaramex 1y ago
        -Wall -Werror means that instead of being able to be used as a ratchet the set of "all" warnings in C and C++ became rusted in place. I sympathise with the instinct to write this in your compiler flags, but alas thanks to Hyrum's law this makes the future worse and so today people ask that you -Wextra and no doubt I'll eventually read of how C is fine so long as you -Wall -Wextra -Wevenmore -Wyetmore -Wandthese
- userbinator 1y ago
  It becomes substantial inconvenience as soon as you need to try to figure out why something doesn't work the way you thought it should.
wavemode 1y ago
Scala has the advantage (and disadvantage) of not caring one lick about backwards compatibility. They were perfectly happy to burn it all to the ground and redo the language's syntax in v3. And even point releases of Scala frequently have breaking changes.
- seanhunter 1y ago
  I respect that, but kind of lost patience with it when a new version of the compiler decided that my types were no longer decidable in code that hadn’t been touched for years. I tried for about 5 mins to fix it and then just thought “It’s not me, it’s you” and put scala down never to pick it up again.
vlovich123 1y ago
I have observed significantly better useful features from Rust or Swift (or Scala) without horribly complicating the language like C++ does. More importantly, they migrate existing codebases and have migration tools instead of breaking old versions of syntax. Rust’s is the most ambitious here letting you mix match editions of the language within a single binary.

mgaunard 1y ago

Every new version of C++ (and sometimes even new versions of C++ compilers) can break code in subtle ways. You should always do extensive testing before upgrading.

reactordev 1y ago
That’s the crux of the issue. People fear upgrading because of the bugs introduced by more complexity for more terse syntax. How much longer will you suffer?
- mgaunard 1y ago
  The same is true for any software. If you care about reliability, you pin, and carefully test before upgrading.
vlovich123 1y ago
I have not observed the same with other languages, whether that’s Java, Rust, or Swift. 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.

saghm 1y ago

I get as exasperated at C++ as anyone else, but IMO there's another takeaway here, which is that smart contracts are an absolutely terrible idea. Relying on code as the source of truth for a transaction just completely disregards the reality that code is always going to be buggy. For those who might not be aware, this is the same smart contract framework where someone accidentally killed $300 million of transactions because a function in a library for setting the wallet associated with a private key was defined as public instead of private: https://medium.com/cybermiles/i-accidentally-killed-it-and-evaporated-300-million-6b975dc1f76b https://medium.com/cybermiles/i-accidentally-killed-it-and-e... 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?

usmannk 1y ago
This is about a language compiler bug. There are no takeaways about smart contracts here.
- tsujamin 1y ago
  So long as you’re writing your smart contracts with a chisel, into a stone tablet, with no compilers or assemblers in sight!
  - tkz1312 1y ago
    The bug was a simple segfault and did not result in the production of invalid or incorrect code.
    - saghm 1y ago
      Segfaults are the lucky case when you run into undefined behavior. The unlucky case is that you just get a program doing something different than what you intended without any clear indication that something went wrong.

DokDidhuAd 1y ago

Yeah, C++ is just batshit insane. > 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.

maccard 1y ago
> You will never find this crap in actual math Sure you do. What’s 6/2(1+2)