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

331–340 of 470 posts

Re: In Defense of C++

#331

Post by lelanthran »

saghm wrote: post #322
lelanthran wrote: post #313

Earlier quoted context omitted.

> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code. The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their f…

And yet, they both still suffer from the flaw that the parent comment cites. Describing a shared property doesn't imply a claim that they're the same language.

> And yet, they both still suffer from the flaw that the parent comment cites.

I dunno; the flaw is not really comparable, is it? The skill and discipline required to write C bug-free is an orders of magnitude less than the skill and discipline required to write C++.

Unless you read GGPs post to mean a flaw different to "skill and discipline required".

Re: In Defense of C++

#332

Post by lelanthran »

estimator7292 wrote: post #316
lelanthran wrote: post #313

Earlier quoted context omitted.

> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code. The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their f…

Have you written significant amounts of C or C++? Most people don't write C, nor use the C compiler, even when writing C. You use C++ and the C++ compiler. For (nearly) all intents and purposes, C++ has subsumed and replaced C. Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features. It's still C++ on the C++ compiler. Actual uses of actual C are pretty esoter…

> Have you written significant amounts of C or C++?

Yes.

> Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features.

Those "someone's" have not written a significant amount of C. Maybe they wrote a significant amount of C++.

The cognitive load when dealing with C++ code is in no way comparable to the cognitive load required when dealing with C code, outside of code-golfing exercises which is as unidiomatic as can be for both languages.

Re: In Defense of C++

#333

Post by AnimalMuppet »

tialaramex wrote: post #318
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…

So, what programmers wanted (yes, already before C++ got this) was what are called "destructive move semantics". These assignment semantics work how real life works. If I give you this Rubik's Cube now you have the Rubik's Cube and I do not have it any more. This unlocks important optimisations for non-trivial objects which have associated resources, if I can give you a Rubik's Cube then we don't need to clone mine,…

In particular, move is important if there is something like a unique_ptr. To make a copy, I have to make a deep copy of whatever the unique_ptr points to, which could be very expensive. To do a move, I just copy the bits of the unique_ptr, but now the original object can't be the one that owns what's pointed to.

Re: In Defense of C++

#334

Post by renox »

Defletter wrote: post #239
renox wrote: post #236

Earlier quoted context omitted.

D (as always) is clever: the operator is ~ So no confusion between addition and concatenation and you can keep | for or.

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?

No, it doesn't. But I'm not sure that this matter, a sufficiently "smart" compiler understand that this is the same thing.

Re: In Defense of C++

#335

Post by throwawaymaths »

pornel wrote: post #264
jillesvangurp wrote: post #220

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…

People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no…

To me a compiler's effort is misplaced and wasted when it's spent on checking invariants that could be checked by a linter or a sidecar analysis module.

Re: In Defense of C++

#336

Post by Night_Thastus »

fluoridation wrote: post #165
Night_Thastus wrote: post #115

Earlier quoted context omitted.

C++11 through 17 negated a lot of its usefulness - the standard library does a lot of what Boost originally offered. Alternative libraries like QT are more coherent and better thought out.

Qt is... fine... as long as you're willing to commit and use only Qt instead of the standard library. It's from before the STL came out, so the two don't mesh together really at all.

In my experience I've had no issues. Occasionally have to use things like toStdString() but otherwise I use a mix of std and qt, and haven't had any problems.

Re: In Defense of C++

#337

Post by AnimalMuppet »

zbentley wrote: post #310
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.

Regrettably, “intended purpose” is highly subjective. Sure, Reasonable minds can and do differ about where the line is in many of those cases. And because of that variability of interpretation, we get extremely hard to understand code. As much as I have seen value in overloading at times, I’m forced to agree that it should probably not exist entirely.

Depends on what you're trying to understand.

Let's say I have matrices, and I've overloaded * for multiplying a matrix by a matrix, and a matrix by a vector, and a matrix by a number. And now I write

  a = b * c;
If I'm trying to understand this as one of a series of steps of linear algebra that I'm trying to make sure are right, that is far more comprehensible than

  a = mat_mult(b,c);
because it uses math notation, and that's closer to the way linear algebra is written.

But if I take the exact same line and try to understand exactly which functions get called, because I'm worried about numerical stability or performance or something, then the first approach hides the details and the second one is easier to understand.

This is always the way it goes with abstraction. Abstraction hides the details, so we can think at a higher level. And that's good, when you're trying to think at the higher level. When you're not, then abstraction just hides what you're really trying to understand.

Re: In Defense of C++

#338

Post by jayd16 »

C++ as a language is truly a mess. But as far as a niche it has a pretty unique offering, even today.

My background is games and I've been heavily in Unreal lately. The language feels modern enough with smart pointers and such. Their standard library equivalent is solid.

The macros still feel very hacky and, ironically, Unreal actually does its own prepass over the source to parse for certain macros.... kind of shows that it's not a good language feature if that's needed. BUT the syntax used fits right into the language, so it feels idiomatic enough.

Templates are as powerful as they are just a mess to read.

Does anything come close to the speed and flexibility of the language? I think the biggest reason C++ sticks around is momentum but beyond that nothing _really_ replaces the messy but performance critical nature of it.

Re: In Defense of C++

#339

Post by llogiq »

alkonaut wrote: post #198

> Yes, C++ can be unsafe if you don’t know what you’re doing. But here’s the thing: all programming languages are unsafe if you don’t know what you’re doing. I think this is one of the worst (and most often repeated arguments) about C++. C and C++ are inherently unsafe in ways that trip up _all_ developers even the most seasoned ones, even when using ALL the modern C++ features designed to help make C++ somewhat safe…

The problem with C++ vs. unsafety is that there is really no boundary: All code is by default unsafe. You will need to go to great lengths to make it all somewhat safe, and then to even greater lengths to ensure any libraries you use won't undermine your safety.

In Rust, if you have unsafe code, the onus is on you to ensure its soundness at the module level. And yes, that's harder than writing the corresponding C++, but it makes the safe code using that abstraction a lot easier to reason about. And if you don't have unsafe code (which is possible for a lot of problems), you won't need to worry about UB at all. Imagine never needing to keep all the object lifetimes in your head because the compiler does it for you.

Re: In Defense of C++

#340

Post by aw1621107 »

bayindirh wrote: post #280
pornel wrote: post #264

Earlier quoted context omitted.

People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no…

These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. Howev…

> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago.

IIRC borrow checking usually doesn't consume that much compilation time for most crates - maybe a few percent or thereabouts. Monomorphization can be significantly more expensive and that's been much more widely used for much longer.

Post reply on HN