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

Popular Myths about C++, Part 2

isocpp.org

Post reply on HN
Print view View original

21–30 of 93 posts

Re: Popular Myths about C++, Part 2

#21

Post by maxlybbert »

debacle wrote: post #8

I feel like it's a bit grasping if you need such a complex example to debunk a straw man. Implicit garbage collection is about the ease of writing code, not reliability. You make the compiler work for you by not making what you want explicit. Yes, for bad programmers, this leads to better code, but that doesn't mean you don't benefit from implicit garbage collection if you are a good programmer.

I didn't consider it a complex example. Instead, it was a set of examples, each focused on one argument regarding garbage collection.

Re: Popular Myths about C++, Part 2

#22

Post by mikeash »

chongli wrote: post #20
mikeash wrote: post #14

Really, "For reliable software, you need Garbage Collection" is the straw man you're going to attack? What comes to mind when you hear "reliable software"? Personally, I immediately think of critical embedded systems like rocket and spacecraft guidance and automotive control systems. And one thing I hear repeatedly is that many well-known coding standards for building such critical software prohibit all dynamic memor…

And when I think of rocket and spacecraft systems (in the context of a discussion around programming) I recall fiascoes such as the Mars Climate Orbiter[0]. If we're going to be thorough about a discussion of reliability in software, we have to include cost in the equation. Rocket and spacecraft systems have extremely high cost per SLOC. It stands to reason that there might be solutions for producing reliable softwar…

Mars Climate Orbiter is an odd choice. There are good examples of expensive software failures in spacecraft systems (the first Ariane 5 launch being a high profile one) and they support your overall point, but MCO wasn't a software failure, but a human failure. Certainly the software could have and should have been better designed to not allow that failure, but ultimately the software behaved exactly as it was intended to, and did exactly what it was told to do.

As far as cost, you're completely right. My point isn't that we should all be building software this way (far from it, most software doesn't need to be that reliable) but rather that when reliability really matters, garbage collection isn't in the picture, so the "myth" being addressed is stupid.

Re: Popular Myths about C++, Part 2

#23

Post by jlarocco »

CyberDildonics wrote: post #5
tinco wrote: post #2

Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…

I've been doing nothing but modern C++11 for a year solid and I have to also agree. C++11 and its standard libraries are a huge improvement but is still difficult to iterate and prototype with. Templates, lambdas, and generic programming are great additions but still very difficult to deal with and debug at times. By using Intel's compiler performance can really scream, but the time it takes to get things done is ver…

My biggest complaint about C++ is all of the non-intuitive "gotchas" and corner cases hidden all over the place that seem to change with every new release. A lot of times the obvious code is either subtly broken and/or less efficient than one would expect.

Reading through "Effective Modern C++," I was constantly thinking, "How is anybody supposed to remember all of these corner cases?"

Re: Popular Myths about C++, Part 2

#24

Post by CyberDildonics »

blub wrote: post #13
CyberDildonics wrote: post #5

Earlier quoted context omitted.

I've been doing nothing but modern C++11 for a year solid and I have to also agree. C++11 and its standard libraries are a huge improvement but is still difficult to iterate and prototype with. Templates, lambdas, and generic programming are great additions but still very difficult to deal with and debug at times. By using Intel's compiler performance can really scream, but the time it takes to get things done is ver…

Well, you have to think in each case what makes sense to you, look at the requirements of the project, team skills, candidates pool, etc and pick the best fit. Choice of programming language is an architectural decision with a big impact and it can't come down just to preference or how nice a language feels, although that plays a part too. One can also do quick prototyping in one language and the real thing in anothe…

Julia is one example of an alternative, but the real point of course is that even modern C++ requires a lot of extra mental energy that just isn't needed in almost any other language. It has its strengths, but I do agree with not using it unless it is completely necessary. Because of its massive language and compiler complexity it is becoming something of a black art the way assembly language has been in the past. Very powerful but very complicated.

Re: Popular Myths about C++, Part 2

#25

Post by blub »

mikeash wrote: post #14

Really, "For reliable software, you need Garbage Collection" is the straw man you're going to attack? What comes to mind when you hear "reliable software"? Personally, I immediately think of critical embedded systems like rocket and spacecraft guidance and automotive control systems. And one thing I hear repeatedly is that many well-known coding standards for building such critical software prohibit all dynamic memor…

All software can be reliable of course, even if it's not embedded software. Not leaking memory at every step, avoiding double freeing of pointers or other memory-related errors tends to make software more reliable...

Why so upset if I may ask? I think Apple declared GCs "bad" anyway.

Re: Popular Myths about C++, Part 2

#26

Post by maxlybbert »

k__ wrote: post #9
Dewie wrote: post #4

Earlier quoted context omitted.

> Depends on how strongly you mean "no other option". For example, is Rust another option? What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler - while also being high level - language. > Here's my standard example for when I would happily choose C++: I think the standard examples are certain application-level programs.

> What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler language. Isn't C simpler than C++ and doesn't waste cycles? The only "no other option" scenario I could imagine is, legacy code in C++ or using a framework that needs C++.

> Isn't C simpler than C++ and doesn't waste cycles?

I gave a couple of C++ books to a recent CS graduate. She assured me that C++ would be easy to pick up because it has a much smaller standard library than Java. I smiled but didn't say any anything.

Yes, C is simpler than C++. But that simplicity comes with a cost, mainly that the programmer has to keep track of more details. And the C standard library is smaller than the C++ standard library (and that would be true even if the C++ standard library didn't include the C standard library).

Re: Popular Myths about C++, Part 2

#27

Post by mikeash »

blub wrote: post #25
mikeash wrote: post #14

Really, "For reliable software, you need Garbage Collection" is the straw man you're going to attack? What comes to mind when you hear "reliable software"? Personally, I immediately think of critical embedded systems like rocket and spacecraft guidance and automotive control systems. And one thing I hear repeatedly is that many well-known coding standards for building such critical software prohibit all dynamic memor…

All software can be reliable of course, even if it's not embedded software. Not leaking memory at every step, avoiding double freeing of pointers or other memory-related errors tends to make software more reliable... Why so upset if I may ask? I think Apple declared GCs "bad" anyway.

I'm upset because a leading figure of the programming community who a lot of people listen to is spouting nonsense, and lots of people are going to believe it.

Why do you think I'd care what Apple says about garbage collection...?

Re: Popular Myths about C++, Part 2

#28

Post by gear54rus »

72deluxe wrote: post #19
lelandbatey wrote: post #7

I've heard so much laid at C++ feet over the years, but I don't find it all that horrible to work with. It seems about on the same level as Python to get most things done, just without all the magic of the python standard library. Are there some good stories of the bad of C++ that anyone can share?

I've not used the Python standard library, but doesn't the STL do a lot of what you want for C++?

It lacks networking features which is pretty limiting. I use QT for 90% of projects, this is the new STD for me and I'm quite happy :)

Re: Popular Myths about C++, Part 2

#29

Post by daxelrod »

expr- wrote: post #15
makecheck wrote: post #11

Earlier quoted context omitted.

Though not updated for C++11, a place to start would be the C++ FQA [1]. [1] http://yosefk.com/c++fqa/defective.html

C++ FQA is rarely a good place to start for anything else than finding examples of biased writing.

I found that combining the C++ FAQ and the C++ FQA made me a much better C++ programmer when I was learning the language.

Sure, it's ranty and biased, but that's kind of the point.

Re: Popular Myths about C++, Part 2

#30

Post by cbd1984 »

Dewie wrote: post #4
pyrois wrote: post #3

Earlier quoted context omitted.

Depends on how strongly you mean "no other option". For example, is Rust another option? I'm not sure how comfortable I am writing for a language with a version of "0.12.0". My understanding is that they make breaking changes fairly frequently (at least compared to the religious mania that is C++'s approach to backwards-compatibility). D seems like an option. Go, maybe, depending on what you're doing. Here's my stand…

> Depends on how strongly you mean "no other option". For example, is Rust another option? What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler - while also being high level - language. > Here's my standard example for when I would happily choose C++: I think the standard examples are certain application-level programs.

Another thing to think about: Program in C++ if you have memory to waste on leaks, or time to waste on plugging leaks.

GC induces things that are arguably leaks, but in the average case they're controlled; leaks in C++ grow without bound in the average case.

Post reply on HN