Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

121–130 of 470 posts

Re: In Defense of C++

#121

Post by s20n »

I believe most C++ gripes are a classic case of PEBKAC.

One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies.

Another perpetual gripe is that C++ is bad because it is overly complex and baroque, usually from C folks like Linus Torvalds[1]. It's pretty ironic, considering the very compiler they use for C (GCC), is written in C++ and not in C.

[1]: Torvalds' comment on C++ https://harmful.cat-v.org/software/c++/linus>

Re: In Defense of C++

#122

Post by ryao »

camkego wrote: post #86

The article says "I think the biggest factor is that any rewrite of an existing codebase is going to yield better results than the original codebase.". Yeah, sorry, but no, ask some long-term developers about how this often goes.

It depends on the codebase. If the code base deserves to be a case study in how not to do programming, then a rewrite will definitely yield better results.

I once encountered this situation with C# code written by an undergraduate, rewrote it from scratch in C++ and got a better result. In hindsight, the result would have been even better in C since I spent about 80% of my time fighting with C++ to try to use every language feature possible. I had just graduated from college and my code whole better, did a number of things wrong too (although far fewer to my credit). I look back at it in hindsight and think less is more when it comes to language features.

I actually am currently maintaining that codebase at a health care startup (I left shortly after it was founded and rejoined not that long ago). I am incrementally rewriting it to use a C subset of C++ whenever I need to make a change to it. At some point, I expect to compile it as C and put C++ behind me.

Re: In Defense of C++

#123

Post by briHass »

gmueckl wrote: post #24

C++ will always stay relevant. Software has eaten the world. That transition is almost complete now. The languages that were around when it happened will stay deeply embedded in our fundamental tech stacks for another couple decades at least, if not centuries. And C and C++ are the lion's share of that. COBOL sticks around 66 years after its first release. Fortran is 68 years old and is still enormously relevant. Muc…

Especially the 'backend' languages that do all the heavy lifting for domain-specific software. Just in my vertical of choice, financial software, there are literally billions of lines of Java and .NET code powering critical systems. The code is the documentation, and there's little appetite to rewrite all that at enormous cost and risk.

Perhaps AI will get reliable enough to pour through these double-digit million LOC codebases and convert them flawlessly, but that looks like it's decades off at this point.

Re: In Defense of C++

#124

Post by m-schuetz »

butterisgood wrote: post #55
loeg wrote: post #45

> 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 m…

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. http…

Operator overloarding is essential for computer graphics libraries for vector and matrix multiplication, which becomes an illegible mess without.

Re: In Defense of C++

#125

Post by ryao »

s20n wrote: post #121

I believe most C++ gripes are a classic case of PEBKAC. One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies. Another…

GCC was originally written in GNU C. Around GCC 4.9, its developers decided to switch to a subset of C++ to use certain features, but if you look at the codebase, you will see that much of it is still GNU C, compiled as GNU C++.

There is nothing you can do in C++ that you cannot do in C due to Turing Completeness. Many common things have ways of being done in C that work equally well or even better. For example, you can use balanced binary search trees in C without type errors creating enormous error messages from types that are sentences if not paragraphs long. Just grab BSD’s sys/tree.h, illumnos’ libuutil or glib for some easy to use balanced binary search trees in C.

Re: In Defense of C++

#126

Post by o11c »

LexiMax wrote: post #98
wvenable wrote: post #77

Earlier quoted context omitted.

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.

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.

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.

Re: In Defense of C++

#127

Post by o11c »

aw1621107 wrote: post #102
butterisgood wrote: post #49

A pet peeve of mine is when people claim C++ is a superset of C. It really isn't. There's a lot of little nuanced differences that can bite you. Ignore the fact that having more keywords in C++ precludes the legality of some C code being C++. (`int class;`) void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit behavior in C++). C…

> C++20 does have C11's designated initialization now, which helps in some cases, but that was a pain for a long time. C++ designated initializers are slightly different in that the initialization order must match the declared member order. That is not required in C.

It also completely negates their utility, even though the exact "problem" they always bring up is already solved when you use normal constructors.

Re: In Defense of C++

#128

Post by zzrrt »

summerlight wrote: post #96

> 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. Only if you have full control on what others are writing. In reality, you're going to read a lot, lots of "clever"…

I’m probably guilty of gratuitous template stuff, because it adds fun to the otherwise boring code I spend a lot of time on. But I feel like the 90% cutdowns are when someone used copy-paste instead of templates, overloads, and inheritance. I don’t think both problems happen at the same time, though, or maybe I misunderstood.

Re: In Defense of C++

#129

Post by pclmulqdq »

duped wrote: post #103
bluGill wrote: post #100

Earlier quoted context omitted.

that idea that packages and builds belongs to simple problem, large projects need things like more than one laguage and so end up fighting the language

Every modern language seems to have an answer to this problem that C and C++ refuse to touch because it's out of scope for their respective committees and standards orgs

C++ has a plethora of available build and package management systems. They just aren't bundled with the compiler. IMO that is a good thing, because it keeps the compiler writers honest.

Re: In Defense of C++

#130

Post by lifthrasiir »

m-schuetz wrote: post #124
butterisgood wrote: post #55

Earlier quoted context omitted.

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. http…

Operator overloarding is essential for computer graphics libraries for vector and matrix multiplication, which becomes an illegible mess without.

I personally think that operator overloading itself is justified, but the pervasive scope of operator overloading is bad. To me the best solution is from OCaml: all operators are regular functions (`a + b` is `(+) a b`) and default bindings can't be changed but you can import them locally, like `let (+) = my_add in ...`. OCaml also comes with a great convenience syntax where `MyOps.(a + b * c)` is `MyOps.(+) a (MyOps.(*) b c)` (assuming that MyOps defines both `(+)` and `(*)`), which scopes operator overloading in a clear and still convenient way.
Post reply on HN