Most active commenters

    ←back to thread

    In Defense of C++

    (dayvster.com)
    185 points todsacerdoti | 17 comments | 16 Sep 25 19:40 UTC | HN request time: 0s | source | bottom
    Show context
    loeg ◴[16 Sep 25 21:54 UTC] No.45268662[source]▶
    > in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language.

    This... doesn't really hold water. You have to learn about what the insane move semantics are (and the syntax for move ctors/operators) to do fairly basic things with the language. Overloaded operators like operator*() and operator<<() are widely used in the standard library so you're forced to understand what craziness they're doing under the hood. Basic standard library datatypes like std::vector use templates, so you're debugging template instantiation issues whether you write your own templated code or not.

    replies(7): >>45268759 #>>45268766 #>>45269024 #>>45272274 #>>45272736 #>>45274243 #>>45274785 #
    butterisgood ◴[16 Sep 25 22:01 UTC] No.45268759[source]▶
    Overloaded operators were a terrible mistake in every programming language I've encountered them in. (Yes, sorry Haskell, you too!)

    I don't think move semantics are really that bad personally, and some languages move by default (isn't that Rust's whole thing?).

    What I don't like is the implicit ambiguous nature of "What does this line of code mean out of context" in C++. Good luck!

    I have hope for C++front/Cpp2. https://github.com/hsutter/cppfront

    (oh and I think you can write a whole book on the different ways to initialize variables in C++).

    The result is you might be able to use C++ to write something new, and stick to a style that's readable... to you! But it might not make everyone else who "knows C++" instantly able to work on your code.

    replies(5): >>45268857 #>>45268992 #>>45269102 #>>45271097 #>>45275305 #
    wvenable ◴[16 Sep 25 22:31 UTC] No.45269102[source]▶
    Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an add in your custom numeric data type is good. But using << for output is bad.
    replies(6): >>45270528 #>>45270621 #>>45272783 #>>45274942 #>>45279942 #>>45297713 #
    1. LexiMax ◴[17 Sep 25 01:49 UTC] No.45270621[source]▶
    I will die on the hill that string concatenation should have its own operator, and overloading + for the operation is a mistake.

    Languages that get it right: SQL, Lua, ML, Perl, PHP, Visual Basic.

    replies(8): >>45270894 #>>45271124 #>>45272157 #>>45272324 #>>45272547 #>>45273713 #>>45273792 #>>45273877 #
    2. zevets ◴[17 Sep 25 02:28 UTC] No.45270894[source]▶
    Alternatively, any implementation of operator+ should have a notional identity element, an inverse element and be commutative.
    replies(1): >>45272328 #
    3. o11c ◴[17 Sep 25 03:01 UTC] No.45271124[source]▶
    I think it's fine when the language has sufficiently strict types for string concatenation.

    Unfortunately, many languages allow `string + int`, which is quite problematic. Java is to blame for some of this.

    And C++ is even worse since literals are `const char[]` which decays to pointer.

    Languages okay by my standard but not yours include: Python, Ruby.

    4. paulddraper ◴[17 Sep 25 05:40 UTC] No.45272157[source]▶
    This is so sad obvious it’s painful.

    Arithmetic addition and sequence concatenation are very very different.

    ——

    Scala got this right as well (except strings, Java holdover)

    Concatenation is ++

    replies(1): >>45272561 #
    5. 112233 ◴[17 Sep 25 06:08 UTC] No.45272324[source]▶
    Tangential, but Lua is the most write-only language I have had pleasure working with. The implementation and language design are 12 out of 10, top class. But once you need to read someone else's code, and they use overloads liberally to implement MCP and OODB and stuff, all in one codebase, and you have no idea if "." will index table, launch Voyager, or dump core, because everything is dispatched at runtime, it's panic followed by ennui.
    replies(1): >>45279960 #
    6. AlotOfReading ◴[17 Sep 25 06:08 UTC] No.45272328[source]▶
    C++ would be a very different language if you couldn't use floats:

    (NaN + 0.0) != 0.0 + NaN

    Inf + -Inf != Inf

    I suspect the algebraists would also be pissed if you took away their overloads for hypercomplex numbers and other exotic objects.

    7. Animats ◴[17 Sep 25 06:41 UTC] No.45272547[source]▶
    > string concatenation should have its own operator,

    It does: |

    That character was put in ASCII specifically for concatenation in PL/1.

    Then came C.

    replies(1): >>45273510 #
    8. Animats ◴[17 Sep 25 06:43 UTC] No.45272561[source]▶
    Python managed to totally confuse this. "+" for built-in arrays is concatenation. "+" for NumPy arrays is elementwise addition. Some functions accept both types. That can end badly.
    9. renox ◴[17 Sep 25 09:04 UTC] No.45273510[source]▶
    D (as always) is clever: the operator is ~ So no confusion between addition and concatenation and you can keep | for or.
    replies(1): >>45273565 #
    10. Defletter ◴[17 Sep 25 09:16 UTC] No.45273565{3}[source]▶
    Question, does that work with other types? Say you have two u16 values, can you concatenate them together with ~ into a u32 without any shifting?
    replies(2): >>45273665 #>>45275910 #
    11. nicwilson ◴[17 Sep 25 09:32 UTC] No.45273665{4}[source]▶
    It works with arrays (both fixed size, and dynamically sized) and arrays; between arrays and elements; but not between two scalar types that don't overload opBinary!"~", so no it won't work between two `ushorts` to produce a `uint`
    12. account42 ◴[17 Sep 25 09:40 UTC] No.45273713[source]▶
    Those languages need a dedicated operator because they are loosely typed which would make it ambiguous like + in JavaScript.

    But C++ doesn't have that problem. Sure, a separate operator would have been cleaner (but | is already used for bitwise or) but I have never seen any bug that resulted from it and have never felt it to be an issue when writing code myself.

    replies(1): >>45274183 #
    13. dgb23 ◴[17 Sep 25 09:52 UTC] No.45273792[source]▶
    PHP overloads operators in other ways though.
    14. CyberDildonics ◴[17 Sep 25 10:07 UTC] No.45273877[source]▶
    But why, where does it become a problem?
    15. _flux ◴[17 Sep 25 10:55 UTC] No.45274183[source]▶
    Though then you can have code like "hello" + "world" that doesn't compile and "hello" + 10 that will do something completely different. In some situations you could actually end up with that by gradual modification of the original code..

    Granted this is probably a novice-level problem.

    16. renox ◴[17 Sep 25 13:56 UTC] No.45275910{4}[source]▶
    No, it doesn't. But I'm not sure that this matter, a sufficiently "smart" compiler understand that this is the same thing.
    17. butterisgood ◴[17 Sep 25 19:00 UTC] No.45279960[source]▶
    Perl was one for me that I always had a little trouble reading again later.

    I guess forth as well... hmmm