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

51–60 of 93 posts

Re: Popular Myths about C++, Part 2

#51

Post by svalorzen »

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…

I don't understand the point about the subset of C++. Nobody is really saying that, they are saying that for most things pointers should not be used, since they would not be needed. But when they are needed, they exist and should be used. If you need to create your own class which handles memory, (smart)pointers are the way to go. If you need to interface yourself with a C library, bare pointers are the way to go.

The fact that most screws have cross or line head cuts does not mean that I won't ever buy a star-shaped screwdriver. When you don't need it, you don't need it. But when you need it, there's nothing else like it.

On the other hand, higher level languages just cut on what you can do, and just give you a big ultra powerful hammer with which you can slam everything together. I guess it works, but I find it rather sloppy working.

Re: Popular Myths about C++, Part 2

#52

Post by lomnakkus »

mikeash wrote: post #42
aurelius wrote: post #38

Earlier quoted context omitted.

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.

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

You're also arguing a straw man. Of course you can write reliable software without dynamic allocation. The question is: can you do it faster and/or cheaper using C++ or $ALTERNATIVE?

(You mentioned rocket and spacecraft guidance software as examples. That's an example of software that's exceedingly expensive to develop... and it doesn't actually do that much even though it's obviously complex.)

Re: Popular Myths about C++, Part 2

#53

Post by pjmlp »

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 think Apple declared GCs "bad" anyway.

Correction, Apple failed to implement a working GC, given the constraints on Objective-C semantics. It was a conservative GC and still it borked when mixing libraries not compiled the same way.

So they made a sensible option of having the compiler insert the retain/release method calls that Objective-C developers would need to do manually.

This only covers framework code or objects that follow Cocoa semantics, everything else is manual.

Swift, being binary compatible with the Objective-C runtime, needs to make use of the same memory model.

Re: Popular Myths about C++, Part 2

#54

Post by chongli »

mikeash wrote: post #22
chongli wrote: post #20

Earlier quoted context omitted.

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

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" being addressed is stupid

I would continue to disagree. I don't accept it on faith that the standards of fallible agencies such as NASA are proven correct, especially given the counterexample I mentioned earlier. There are ways to implement hard real-time garbage collectors and prove them correct with far more rigour than was employed in the MCO mission. The side benefit of such proofs is that we us mere mortal programmers can benefit from the work in our everyday lives, something you can't say about the extremely domain-specific code used by NASA.

Re: Popular Myths about C++, Part 2

#55

Post by kzrdude »

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

"G++ now allows typename in a template template parameter." (GCC changelog)

    template typename X> struct D; // OK
Thanks guys..

Re: Popular Myths about C++, Part 2

#56

Post by mikeash »

lomnakkus wrote: post #52
mikeash wrote: post #42

Earlier quoted context omitted.

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.

> 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. You're also arguing a straw man. Of course you can write reliable software without dynamic allocation. The question is: can you do it fast…

What straw man am I arguing?

You say, "Of course you can write reliable software without dynamic allocation." Why is that "of course," if the myth being addressed is that you cannot write reliable software without garbage collection? If you're saying everyone knows that you can write reliable software without GC, and it'll just be expensive and such, then we're in agreement, because that's exactly what I'm saying.

Re: Popular Myths about C++, Part 2

#57

Post by mikeash »

chongli wrote: post #54
mikeash wrote: post #22

Earlier quoted context omitted.

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

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 how to make that robust, but I don't see how you can possibly apply it to the question of how to make "reliable software."

Re: Popular Myths about C++, Part 2

#58

Post by vitd »

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

I concur with this. I use C++ daily and have been for about 20 years, and I still run into gotchas and things I misunderstand all the time.

I feel it's even worse than that, though. There seems to be a culture among C++ programmers to do things in overly clever ways and to push the limits of readability and understandability. Just look at the headers for the standard C++ template library, for example. (I'm currently looking at the ones shipped with gcc.) They don't even use consistent indentation, and have single letter variables that are meaningless to all but those who wrote it. It's pretty frustrating to deal with.

Re: Popular Myths about C++, Part 2

#59

Post by AnimalMuppet »

So far, all the comments seem to be missing Stroustrup's biggest point: garbage collection only works for memory. Destructors work for everything - memory, file handles, semaphores/locks, database connections, everything.

Garbage collection handles 90% of the problem transparently to the programmer. That's wonderful (really - I'm not being sarcastic here). But the problem is, garbage collecting languages usually don't have destructors, and so you're left having to manage the other 10% of the problem yourself. You have to remember to close all your own files, clean up all your database connections, and so on. Garbage collection usually makes the 90% trivial, at the price of giving you no tool at all for dealing with the other 10% (non-memory portion) of resource management.

Re: Popular Myths about C++, Part 2

#60

Post by spoiler »

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

I remember working on a small in-house C++ library with a colleague.

Being mostly a C programmer, my code in C++ was basically (as he coined it) fancy-C. Then he rewrote my code in "the C++ way," after which the code became completely opaque to me.

My initial mistake was that I expected C++ to be like (or similar to) C, a mistake I believe many of us make. C++ is a lot more complex in scope (not necessarily in a bad way, either) and requires proper learning.

I came to the realisation that C and C++ are not even similar languages. Yes, you can write proper C code in C++ (with a bit of added strictness), but that's not how one should write C++. Also, I think that lot of the "anger" towards C++ is that the the names makes you think it's like C, but then you start learning the language and realise that in fact it is nothing like C on the outside, just on the inside.

Anyway, I'm not hating on C, I actually haven't taken on the quest to learn it properly, and I still rely mostly on C.

Post reply on HN