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

31–40 of 93 posts

Re: Popular Myths about C++, Part 2

#31

Post by 72deluxe »

CyberDildonics wrote: post #6
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…

Rust is likely not an option for most people using C++ yet. C++ has one huge advantage over almost every other language: its tools and eco system. MSVC++, Intel's ICC, GCC and LDC are all solid compilers where you will not paint yourself into a corner because of your tools. D is more mature but still can't compete on tools since only a few languages can make that claim. Your case is another big point. C++ can manage…

"for some reason its modern dependencies are just as big as scripting languages"

In what way? Isn't writing an application trivial with the STL? Even something like a GUI is possible with a small system and FLTK (although it isn't really very pretty).

Re: Popular Myths about C++, Part 2

#32

Post by blub »

mikeash wrote: post #27
blub wrote: post #25

Earlier quoted context omitted.

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

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

Re: Popular Myths about C++, Part 2

#33

Post by nhaehnle »

makecheck wrote: post #11
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?

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

It's impressive to see how many of the complaints have been addressed by C++11, actually, and how many others have been addressed by compatible changes to the compilers and standard libraries (in particular, template related error messages can still be pretty bad, but they have improved tremendously with gcc and clang in the last few years).

Re: Popular Myths about C++, Part 2

#34

Post by 72deluxe »

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.

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++ should have no leaks if you use RAII properly, have clearly defined container classes, use references everywhere or const pointers if you must. If you write sloppy code, you get sloppy output.

See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources".

EDIT: Wahay getting downvoted - thanks! In any other language (eg. PHP) if there was a vocal crowd complaining about how their scripts are slow when they do something stupid like fetching an entire database table and then doing filtering within the PHP script itself, everyone would say "But you're doing something stupid - it is going to be slow" and nobody would argue with it.

With C++, when you point out that someone is doing something foolish, you get downvoted and people start making arguments about features of the language instead to detract from the truth that you've highlighted, ie "but a good language wouldn't let you do dangerous things", which is the same as saying "knives can cut you - ban all knives!!". It's really wearisome, and always rears its head here on HN where C++ is NOT the language of the day.

Re: Popular Myths about C++, Part 2

#35

Post by mikeash »

blub wrote: post #32
mikeash wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Popular Myths about C++, Part 2

#36

Post by pif »

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

Just wondering: why the downvotes?

Re: Popular Myths about C++, Part 2

#37

Post by fsloth »

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?

My main gripe is the mental overhead when compared with other languages and the bulkiness of the syntax.

Languages that contain lists and maps as first class types and the syntax to go with it are so much nicer.

It's no joke that large C++ applications contain a poorly defined subset of common lisp.

The standard library is small. Things that are included out of the box in other languages do not. Doing some simple things are not as simple as in some other languages.

When dealing with math, on the other hand, as systems languages go, C++ is not the worst alternative. Getting numeric stuff correct is about as difficult in all languages.

I would not use C++ anything that benefits from prototyping. Otoh, when the spec has been defined and it is fairly obvious what needs done there is no reason why it should not be banged together using C++.

Re: Popular Myths about C++, Part 2

#38

Post by aurelius »

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 memory needs to be freed. However, the mechanisms of reference-counted smart pointers, RAII, and clearer ownership semantics in the language, go a long way to help mitigate the common manual memory management problems in C++.

The downside, of course, is that you have to know how to use these ideas to write "reliable software", and C++ does not make it easy. It's pretty much impossible to go from reading the standard to implementing correct and optimal C++ programs. There are so many gotchas, corner-cases, and features which require much study and experience to truly understand.

Re: Popular Myths about C++, Part 2

#39

Post by 72deluxe »

gear54rus wrote: post #28
72deluxe wrote: post #19

Earlier quoted context omitted.

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 :)

Ah yes I forgot that. I remember Stroustrup explicitly stating that he avoided adding stuff like GUIs to the STL as people forget that C++ isn't just ran on desktops.

I use wxWidgets with a mix of STL (you can tell wxWidgets to use STL for its containers if you want) and all works well.

I had been happily using extra networking libraries and the ease of using libraries means I kind of forget that the STL doesn't have it - I just get into a habit of using the right library for the job, which is the way it should be I suppose.

Re: Popular Myths about C++, Part 2

#40

Post by ijk »

WhitneyLand wrote: post #17
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.

>>garbage collection is about the ease of writing code, not reliability No, it is about reliability. You are confusing not always necessary/perfect/optimal with average case reliability. On average, automatic memory management has less bugs because certain classes of mistakes can be entirely eliminated. Also this argument of good programmers don't have to rely on X as a crutch is more about pride than productivity. I…

> Also this argument of good programmers don't have to rely on X as a crutch is more about pride than productivity. In the real world, most teams have code touched by developers at a variety of skill sets and everyone's contributions affect quality of code so tools should be measured across levels of expertise.

Not to mention that sometimes even Homer nods.

If something needs to happen in a certain way and you have to manually ensure that it happens every time, sooner or later even the best of us will slip up. Now, the tradeoff in power and flexibility might be worth the risk of shooting ourselves in the foot, but it's still a tradeoff.

Post reply on HN