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

71–80 of 93 posts

Re: Popular Myths about C++, Part 2

#71

Post by chongli »

mikeash wrote: post #57
chongli wrote: post #54

Earlier quoted context omitted.

MCO wasn't a software failure, but a human failure You're making a distinction where none exists. All software (that we know of, anyway) is the product of humans. but ultimately the software behaved exactly as it was intended to I somehow doubt the designers intended for the software to cause the mission to fail. but rather that when reliability really matters, garbage collection isn't in the picture, so the "myth" b…

So the Tacoma Narrows bridge collapse was indistinguishable from a software failure because all software is the product of humans? That makes no sense. The MCO failure came about because people took the correct output of one program, then incorrectly used it as input for another program, which then performed exactly as it was supposed to on the bad input. This is an interesting study in human-computer interaction and…

Ahh, now you're affirming the consequent. I said all software is the product of humans. I did not say that all human products are software.

Where our disagreement seems to occur is where the boundaries of software systems lie. You appear to be making the claim that it is at the granularity of individual programs whereas I am claiming that the entire software system must be considered. If you were to write a bash script that pipes the output of curl (presumably an html file) to /dev/dsp0 and a horrible screeching noise emanates from your speakers, what you have produced is a software error. It does not matter that each of the individual components is working as intended; the system as a whole is not (unless you actually intended to produce that screech, of course).

Re: Popular Myths about C++, Part 2

#72

Post by textphone »

dang wrote: post #68
72deluxe wrote: post #34

Earlier quoted context omitted.

This leaks argument is really getting old. I have no leaks in my code. C++11's addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. Even "old" C+…

All: In HN comments, please don't complain about being downvoted. It's off-topic, explicitly against the site guidelines, and tedious.

Please reduce the number of people with downvote power. Far too many people abuse them now. The site has become very hostile and it's caused entire communities to move away from HN, e.g. to producthunt. This trend will only continue if the hostility isn't improved.

Re: Popular Myths about C++, Part 2

#73

Post by 72deluxe »

dang wrote: post #68
72deluxe wrote: post #34

Earlier quoted context omitted.

This leaks argument is really getting old. I have no leaks in my code. C++11's addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. Even "old" C+…

All: In HN comments, please don't complain about being downvoted. It's off-topic, explicitly against the site guidelines, and tedious.

Ah OK thanks didn't realise. I don't mind being downvoted, just without any replies or explanation. It is particularly militant in C++ articles, where there is an extremely hostile backlash to C++ here on HN, I have noticed. The language bashers come out in force for no good reason.

Re: Popular Myths about C++, Part 2

#74

Post by 72deluxe »

pjmlp wrote: post #66
72deluxe wrote: post #34

Earlier quoted context omitted.

This leaks argument is really getting old. I have no leaks in my code. C++11's addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. Even "old" C+…

> This leaks argument is really getting old. I have no leaks in my code. I imagine you are in the lucky position to have full control over the whole code, right? Back on my C++ days at work, 1999 - 2005, there was always a lucky guy having to track down pointer misuses across the project source code.

Yes I am fortunate to have full control over the code. I still have some older code written by someone else to maintain, and that's pretty horrible in its architecture (incessant message passing for no good reason).

In other jobs I didn't have access to all the code but there were coding standards, regular reviews, and younger developers were mentored by older ones and their check-ins to repositories were vetted to ensure at least some standards. CPPCheck was also useful in some cases, and that Borland memory corruption tool that got built into the executable and caused false positives most of the time...

Re: Popular Myths about C++, Part 2

#75

Post by mikeash »

chongli wrote: post #71
mikeash wrote: post #57

Earlier quoted context omitted.

So the Tacoma Narrows bridge collapse was indistinguishable from a software failure because all software is the product of humans? That makes no sense. The MCO failure came about because people took the correct output of one program, then incorrectly used it as input for another program, which then performed exactly as it was supposed to on the bad input. This is an interesting study in human-computer interaction and…

Ahh, now you're affirming the consequent. I said all software is the product of humans. I did not say that all human products are software. Where our disagreement seems to occur is where the boundaries of software systems lie. You appear to be making the claim that it is at the granularity of individual programs whereas I am claiming that the entire software system must be considered. If you were to write a bash scri…

I agree with your example of a pipe. But what if you manually retyped it and you were supposed to carry out a format conversion as you did so?

My understanding of the MCO failure was that it was a manual step in the process that failed. The humans were supposed to do something, and didn't. I don't see how that can be defined as software, or anything even close. It's analogous to seeing a highway sign that says the speed limit is 80km/h, setting my car cruise control to 80MPH, and then saying that it was a software defect that caused me to get a speeding ticket.

Re: Popular Myths about C++, Part 2

#76

Post by leetNightshade »

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…

You have another option: Unreal Engine Blueprints. If you're not comfortable with C++, use Blueprint, that's what it's there for.

Re: Popular Myths about C++, Part 2

#77

Post by steveklabnik »

pyrois wrote: post #3
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…

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…

> My understanding is that they make breaking changes fairly frequently

http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

    * now -> Jan 9: TONS of breaking changes
    * Jan 9 -> Feb 16: probably shouldn't break, but we
      reserve the right to deal with exceptional circumstances
    * Feb 16 -> six weeks, maybe 12: no more breakage

Re: Popular Myths about C++, Part 2

#78

Post by AnimalMuppet »

mikeash wrote: post #50
mark-r wrote: post #47

Earlier quoted context omitted.

The reason this isn't a straw man is that it's a true belief held by many people; most of us aren't exposed to the extremes of reliability that you're talking about. When lives aren't on the line, memory management is generally a necessity.

Who actually holds this belief, that garbage collection is a requirement for reliable software? Most people don't work with such software but surely everyone who even thinks about programming is aware that it exists. I mean, you don't have to dive deep into computing to know that cars are full of computers and software these days.

Keep reading HN. You'll see articles and comments that state (or imply) that normal humans can't handle memory management, and therefore GC is the way to avoid bugs and memory leaks.

Sorry, I can't give you references off the top of my head, but I've seen that stated, here, in the last couple of months at least.

Re: Popular Myths about C++, Part 2

#79

Post by [deleted] »

72deluxe wrote: post #74
pjmlp wrote: post #66

Earlier quoted context omitted.

> This leaks argument is really getting old. I have no leaks in my code. I imagine you are in the lucky position to have full control over the whole code, right? Back on my C++ days at work, 1999 - 2005, there was always a lucky guy having to track down pointer misuses across the project source code.

Yes I am fortunate to have full control over the code. I still have some older code written by someone else to maintain, and that's pretty horrible in its architecture (incessant message passing for no good reason). In other jobs I didn't have access to all the code but there were coding standards, regular reviews, and younger developers were mentored by older ones and their check-ins to repositories were vetted to e…

[deleted]

Re: Popular Myths about C++, Part 2

#80

Post by 72deluxe »

AnimalMuppet wrote: post #78
mikeash wrote: post #50

Earlier quoted context omitted.

Who actually holds this belief, that garbage collection is a requirement for reliable software? Most people don't work with such software but surely everyone who even thinks about programming is aware that it exists. I mean, you don't have to dive deep into computing to know that cars are full of computers and software these days.

Keep reading HN. You'll see articles and comments that state (or imply) that normal humans can't handle memory management, and therefore GC is the way to avoid bugs and memory leaks. Sorry, I can't give you references off the top of my head, but I've seen that stated, here, in the last couple of months at least.

I get this feeling too, and I wonder if it is from a large vocal group of people who have never ever developed anything in C or C++, yet appear to know all about how "dangerous" it is and enjoy mocking the languages, whilst pointing to niche languages with much smaller development tool ecosystems and support libraries.

Is it just me?

Post reply on HN