Popular Myths about C++, Part 2 • Hacker News Board

Re: Popular Myths about C++, Part 2

#41

Post by cbd1984 » Mon, Dec 15, 2014, 4:49 PM UTC

72deluxe wrote: post #34

cbd1984 wrote: post #30

Earlier quoted context omitted.

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.

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

I upvoted you twice, in case you care.

You raise some good points; the problem is, they both point the way to using languages other than C++: You essentially advocate using a subset of C++ (everyone does, even Stroustrup), and the subset of C++ you advocate is the high-level one with a maximal amount of automatic resource management, whether by templates or RAII.

OK, if I'm doing that, I obviously don't care about the manual resource management part of C++, so why shouldn't I use a language which gives me all of that and more? Are the performance gains from using that subset of C++ compared to something else even perceptible?

Re: Popular Myths about C++, Part 2

#42

Post by mikeash » Mon, Dec 15, 2014, 4:49 PM UTC

aurelius wrote: post #38

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…

I think you've taken a pretty narrow interpretation of "reliable software". It seems more reasonable to think that Bjarne was speaking at a general level, i.e., the idea that software written in non-garbage collected languages tends to be prone to memory management errors on the part of the programmer. This has been a common meme for the past 15 to 20 years precisely because it is so easy to forget when a block of me…

I'm not arguing that you need to avoid dynamic memory management to write "reliable software." I'm just pointing out that a lot of reliable software is written that way, and thus the idea that you need garbage collection to write reliable software is so obviously false that it's silly to think anyone believes it to be true, making it a terrible straw man to argue against.

Re: Popular Myths about C++, Part 2

#43

Post by 10098 » Mon, Dec 15, 2014, 4:51 PM UTC

cbd1984 wrote: post #30

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.

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.

Anecdata: at my current gig, I almost never run into any memory-related issues with the C++ services that I support, and I've never written a "delete" because everything is managed with smart pointers. The one time we ran out-of-memory wasn't because of a leak.

On the other hand, one of the most frequent problems with our Java services is "GC thrashing".

Re: Popular Myths about C++, Part 2

#44

Post by 72deluxe » Mon, Dec 15, 2014, 5:23 PM UTC

cbd1984 wrote: post #41

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

I upvoted you twice, in case you care. You raise some good points; the problem is, they both point the way to using languages other than C++: You essentially advocate using a subset of C++ (everyone does, even Stroustrup), and the subset of C++ you advocate is the high-level one with a maximal amount of automatic resource management, whether by templates or RAII. OK, if I'm doing that, I obviously don't care about th…

Thanks for the upvotes. You are right about both of these subsets pointing to other languages; I had not thought about that!

I myself throw pointers around all over the place because I am restricted by my Windows compiler (no C++11 features) and I don't do stupid things with them (and am a slow learner for new features...).

I suppose the performance gains are negligible in simple applications but in performance critical applications they can make a difference - games, web servers etc. See how Facebook built their PHP to C++ interpreter for reduction in running costs and heating costs. PHP was more convenient to write (and PHP developers are cheaper to hire I presume) but I wouldn't welcome all programs being of the "interpreted" type.

With C++, the push for type safety and making the compiler do the work for you will mean more efficient programs and less run-time checks. This is particularly important on mobile devices where processing usage = less battery life. And I would be far happier running an application for a few extra hours on my laptop if it was written in a sensible language and made efficient use of my hardware; lots of little performance gains add up.

Imagine the horror of apps being written entirely for developer convenience with little thought to performance - you could kiss goodbye to a big stack of power worldwide. That problem is only going to get worse, and the "there's processing power so I'll use it" approach is what gave us bloatware in the first place.

So I suppose application and system program development is a tradeoff between developer convenience and user convenience (battery life, speed etc.)

Re: Popular Myths about C++, Part 2

#45

Post by thinkpad20 » Mon, Dec 15, 2014, 5:34 PM UTC

jlarocco wrote: post #23

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…

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?"

That was my impression when I took a course in C++ as a grad student. The course emphasized C++11, so I assume it represented (at the time, early 2013) modern usage. But 80% of every lecture consisted of presenting some example code, and explaining how what you think this code should do (if indeed it's obvious at all) is probably wrong. So many gotchas. It made me terrified to think of trying to write/test/debug a large and sophisticated C++ code base.

Re: Popular Myths about C++, Part 2

#46

Post by shawn-butler » Mon, Dec 15, 2014, 5:48 PM UTC

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++?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/ gives a sense of where the standards committee is going.

Re: Popular Myths about C++, Part 2

#47

Post by mark-r » Mon, Dec 15, 2014, 6:04 PM UTC

mikeash wrote: post #35

blub wrote: post #32

Earlier quoted context omitted.

But it's not nonsense, realiability isn't all or nothing, and GC has the effect that it completely removes a class of problems that happen often in languages like C or C++ when doing manual memory management. It is making those programs more reliable, even if they aren't as bug-free as your typical spacecraft software. That was just a joke with Apple. :)

I'm not arguing against GC or the reliability thereof. I'm merely arguing that "GC is required for reliability" is a ridiculous straw man of a myth. I am in fact a fan of GC, but I also recognize that when lives are on the line, GC and indeed dynamic memory management of any type is usually out of the picture.

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.

Re: Popular Myths about C++, Part 2

#48

Post by pyrois » Mon, Dec 15, 2014, 6:10 PM UTC

cbd1984 wrote: post #41

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

I upvoted you twice, in case you care. You raise some good points; the problem is, they both point the way to using languages other than C++: You essentially advocate using a subset of C++ (everyone does, even Stroustrup), and the subset of C++ you advocate is the high-level one with a maximal amount of automatic resource management, whether by templates or RAII. OK, if I'm doing that, I obviously don't care about th…

Good point! For me, I think the question here isn't so much "performance gains" as "interoperability, near-ubiquity, and staying power".

For "interoperability", I'm just going to quote myself:

"If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages."

In terms of ubiquity, what I mean is that almost every platform has a standards-compliant-ish C++ compiler for it. And before people get in a tizzy, I mean weird platforms, not just computers with a browser installed. That's Intel, yes, but also DSPs, FPGAs, ARMs, and whole host of other chips. This didn't used to be true, but with LLVM, almost an entire standards-compliant C++ toolchain can be generated for your platform pretty easily. The exception tends to be, ironically enough, exceptions. They need to be special-cased for your chip, but still, C++ exists in places where the JVM doesn't dare go.

And finally, for staying power, I'll quote myself again!

"Look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power."

[0] http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html

Re: Popular Myths about C++, Part 2

#49

Post by cpitman » Mon, Dec 15, 2014, 6:16 PM UTC

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…

Yes, I completely agree. I had a client that pushed for a large enterprise application to be written in C++. By large, I mean it took a ~30 person team about 3 years to develop. In the end, I think the 80/20 rule applied and well under 20% of the code was performance critical while the rest was handling common operations that in higher level languages would either be easy or part of a standard library. On top of that, once the client wanted to take over the project they had a hell of a time finding competent C++ developers.

Back in 2005 two Microsoft developers (Raymond Chen and Mariani) did a blog series where one of them wrote and optimized a C++ Chinese/English dictionary and the other did the same in C#[0]. The naïve C# version outperformed the C++ version until Raymond performed several significant optimizations.

[0]: http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx

Re: Popular Myths about C++, Part 2

#50

Post by mikeash » Mon, Dec 15, 2014, 6:29 PM UTC

mark-r wrote: post #47

mikeash wrote: post #35

Earlier quoted context omitted.

I'm not arguing against GC or the reliability thereof. I'm merely arguing that "GC is required for reliability" is a ridiculous straw man of a myth. I am in fact a fan of GC, but I also recognize that when lives are on the line, GC and indeed dynamic memory management of any type is usually out of the picture.

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.