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

Popular Myths about C++, Part 1

isocpp.org

Post reply on HN
Print view View original

41–50 of 144 posts

Re: Popular Myths about C++, Part 1

#41

Post by throwawayaway »

Derpdiherp wrote: post #35
throwawayaway wrote: post #21

Earlier quoted context omitted.

why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

References in my opinion should actually be called "Address of" operators, then it's much easier for someone new to see why pointers and references exist together. Printf and the cstdlib - eh yeah I'll hand you that, if someone had no concept at all that a language called C existed prior to C++ this would be confusing without explaining it to them. But a newbie should not be looking at C++ code that uses the cstdlib…

C++ falls to the no true scotsman fallacy yet again.

If you type in hello world to the internet, you are going to be getting C and C++ versions and you are going to find out that both work. You can't hide the truth from beginners for any length of time. Imagine telling someone that they can't look stuff up on the internet in case they get exposed to "the wrong stuff"?

check out google on streams:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...

Re: Popular Myths about C++, Part 1

#42

Post by throwawayaway »

pjmlp wrote: post #38
throwawayaway wrote: post #21

Earlier quoted context omitted.

why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

> why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib? Support for a legacy language full of security holes.

In riposte: C++ willingly supports all previous security holes and adds a few more.

why do we have structs and classes? all this stuff in the first week.

Re: Popular Myths about C++, Part 1

#43

Post by WhitneyLand »

Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints?

Back in the day I read Bjarne's book cover to cover, used C++ for very large scale projects, and was one of those guys who could make sense of arbitrarily complex pointer expressions.

Now I mostly regret it. Led down the rabbit hold of multiple inheritance, STL being much more complicated than templating in other languages, and watching devs take years to master all of the subtleties.

He alludes (next article) to garbage collection not being more reliable than manually memory management? Yes GC has it's own disadvantages and there are many ways in C++ to mitigate memory management problems, but seriously I wish I had a dollar for every hour of time spent on a memory allocation bug in C++.

Re: Popular Myths about C++, Part 1

#44

Post by mikeash »

ExpiredLink wrote: post #30
linuxlizard wrote: post #25

Earlier quoted context omitted.

What sort of C programmer wouldn't test for malloc() failing. Drives me batty to see articles where malloc() is happily assumed to always succeed.

> Drives me batty to see articles where malloc() is happily assumed to always succeed. ... as in Linux.

Malloc will never fail on Linux due to running out of RAM. However, it will fail for other reasons, such as running out of address space. You can easily run out of address space in 32-bit processes, since you only have 4GB of address space, or less. It's much harder in 64-bit processes, but since you can allocate vast chunks of memory without having them be backed by RAM, you can accomplish it there as well.

Re: Popular Myths about C++, Part 1

#45

Post by bkeroack »

millstone wrote: post #20
stinos wrote: post #9

Earlier quoted context omitted.

Good luck trying to understand C++ without C look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one t…

Much of C++ can only be understood in the context of C. For example, why are string literals not std::string, and what the heck are null-terminated strings about? In your alternate universe, C++ would be a nonsense language full of absurd design decisions. Understanding C is perhaps necessary to understand why C++ works the way it does.

Even further, why are strings considered a linear sequence of 8-bit characters (defaulting to ASCII)? That's madness in 2014! If I give you a sequence of bytes and tell you it's a "string", that's no more meaningful than if I gave you a bunch of bytes and said "this is music" or "this is a picture". Without telling you the encoding you have to blindly guess how to interpret it.

Go does a good job of rectifying this: strings are generally opaque binary objects--indexing into them gives you abstract "runes" (representing Unicode code points) which can then be encoded into various flavors of UTF characters.

Re: Popular Myths about C++, Part 1

#46

Post by CountHackulus »

Symmetry wrote: post #22

What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import . And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.

snprintf isn't a standard function. There's certain platforms that don't have it. I know, it happened to me on z/Linux.

Re: Popular Myths about C++, Part 1

#47

Post by kabdib »

linuxlizard wrote: post #25
Symmetry wrote: post #22

What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import . And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.

What sort of C programmer wouldn't test for malloc() failing. Drives me batty to see articles where malloc() is happily assumed to always succeed.

Rule #1 of systems programming: "Never check for an error that you don't know how to handle." This is, of course, a joke, but it has a kernel of truth.

I've worked on production code where, if allocation fails, the system fails, too, and restarts. The allocator never returns. There's usually some kind of helper system watching for the failure, which can take a dump or at least a stack trace.

The theory is that any attempt at recovery is going to be a disaster; not well tested, and probably doomed in the face of memory pressure anyway. On 64 bit systems the memory ceiling is essentially infinite, but reaching the point where we start to swap is horrible and a pyrrhic victory at best, so instead let's do a controlled crash and log enough information so we can analyze and fix the actual problem (which is a misunderstanding of load and resources, or maybe a bug or an attack where we're trying to allocate twenty gazillion bytes).

That's one philosophy. Another (which was prevalent on the Mac in the 80s, in user applications) is to have a reserve; you test the crap out of the code and give it enough memory in some kind of emergency mode to succeed at getting back to a normal state, or at least quitting in an orderly fashion (ditch dynamically loaded code, fonts, whatever) so that the user's work isn't totally lost.

There's a lot to be said for both designs, and of course these don't cover the case when you're writing library code that can be used by anyone, where reliably returning failure to the caller is important. Here you don't have a choice other than to check and be robust.

So three, yes, three philosophies.

Re: Popular Myths about C++, Part 1

#48

Post by Ragnarork »

pjmlp wrote: post #38
throwawayaway wrote: post #21

Earlier quoted context omitted.

why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

> why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib? Support for a legacy language full of security holes.

Pointers aren't even there for supporting a legacy language, they have their use and are distinct from references. Mixing the two and thinking they are equivalent (though they are close in what they do) is a mistake.

Re: Popular Myths about C++, Part 1

#49

Post by throwawayaway »

Ragnarork wrote: post #48
pjmlp wrote: post #38

Earlier quoted context omitted.

> why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib? Support for a legacy language full of security holes.

Pointers aren't even there for supporting a legacy language, they have their use and are distinct from references. Mixing the two and thinking they are equivalent (though they are close in what they do) is a mistake.

How can you have pointers without allowing all the holes that C allows?

Re: Popular Myths about C++, Part 1

#50

Post by humanrebar »

mikeash wrote: post #40

A major problem with C++ is a lack of consistency, which you run into if you start trying to generalize the ideas presented in this article. The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course: return name+'@'+domain; I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well: return "mailto:…

To be fair everything you're upset about is a problem with the standard C++ library, not the language itself.

Not to say that the language doesn't have issues. The initializer list example you provide is half of one, but only because people don't like to write algorithm-based code.

This is actually fine:

   auto v = {1, 2, 3, 5, 8, 13};
   for (auto i : v) {
       std::cout
...all that being said, the C++ standard library gets strings very wrong. I've ranted about it here before. But, to be fair:

1. What language gets strings right?

2. C++ has some interesting ideas around the bend (concepts) that should make using library code much easier. Whether writing library code will be easier is another question, but I'm hopeful.

Post reply on HN