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

71–80 of 144 posts

Re: Popular Myths about C++, Part 1

#71

Post by jlarocco »

mikeash wrote: post #66
jlarocco wrote: post #65

Earlier quoted context omitted.

> auto v = {1,2,3,5,8,13}; > Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time! IMO it would be more confusing if that created a vector . Unless the compiler is reading your mind, how is it supposed to know you meant a vector , a set , deque , a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?

The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. For example, in Python: x = [1, 2, 3, 5, 8, 13] # this is a list of integers y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers There's nothing inherently wrong with C++'s initializer list approach. Nor is there anything inherently wrong with auto. Bu…

> The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. > For example, in Python:

> x = [1, 2, 3, 5, 8, 13] # this is a list of integers

> y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers

Actually, that's not the best way to do it:

    y = {1, 2, 3, 5, 8, 13} # this is a set of integers without creating a list first.
    z = set(1, 2, 3, 5, 8, 13) # so is this
In C++ {} is syntactic sugar for "Create an initializer_list with these values," which is what happens when it's assigned to an "auto" variable. Not surprising at all. If you want a different type, you need to specify the type that you want.

Maybe it's confusing to beginners and people who don't take the time to learn the language, but C++ isn't catering to those people.

Don't get me wrong, there are a lot of "gotchas" in C++, I just don't think the two you've posted are very bad.

Re: Popular Myths about C++, Part 1

#72

Post by linuxlizard »

mikeash wrote: post #44
ExpiredLink wrote: post #30

Earlier quoted context omitted.

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

While address space is huge, RAM isn't infinite. Our embedded Linux runs out of memory quite often. Or if the swap space fills up on a server with a disk.

I've spent many hours chasing corrupted memory due to someone not checking malloc() fail.

I chased code that boiled down to assert( ptr=malloc() ); Guess what happens when NDEBUG is defined?

Re: Popular Myths about C++, Part 1

#73

Post by linuxlizard »

kabdib wrote: post #47
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.

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

I worked on some safety critical systems in C. The philosophy was treat the code like a little person running around. The person (the code) always wanted to know where the fire escape was. The fire escape always needed to be very easy to use and very reliable. Every function had little fire escape handler to clean up on error. Higher level functions had to decide how to put out the fire (speaking metaphorically here but we really could have started fires) or to raise the alarm to a higher level.

At the very top level, the only thing we could do was save a log then reset (least worst option). Too many resets too fast and we'd take ourselves offline and scream for a human (again, least worst option).

Re: Popular Myths about C++, Part 1

#74

Post by Scea91 »

rumdz wrote: post #16
gamesbrainiac wrote: post #4

Earlier quoted context omitted.

Thanks. Very short post though. What I have to say is, that C++11 and onwards had indeed made C++ much more approachable. I think Herb Sutter's talk on modern C++ is also worth a look. [0] [0] https://www.youtube.com/watch?v=TJHgp1ugKGM

I just finished watching this and 48:58 really blew my mind.

I've written an article about this: http://blog.honzabrabec.cz/2014/07/06/the-power-of-algorithm...

Re: Popular Myths about C++, Part 1

#75

Post by maxlybbert »

mike-cardwell wrote: post #13

"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings." I just compiled the C code and the C++ code using: gcc -std=c99 -Wall -Wextra test.c -o test g++ -std=c++11 -Wall -Wextra test.cpp -o test According to valgrind: C: total heap usage: 1 allocs, 1 frees,…

Try it with optimizations on:

gcc -std=c99 -O3 -Wall -Wextra test.c -o test

g++ -std=c++11 -O3 -Wall -Wextra test.cpp -o test

In my experience, C++ compilers are great at eliding temporaries and various constructor calls (and related memory allocations), but only if optimizations are turned on.

Re: Popular Myths about C++, Part 1

#76

Post by jerf »

mikeash wrote: post #44
ExpiredLink wrote: post #30

Earlier quoted context omitted.

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

"You can easily run out of address space in 32-bit processes, since you only have 4GB of address space, or less."

Ah, 21st Century problems.

Re: Popular Myths about C++, Part 1

#77

Post by mikeash »

jlarocco wrote: post #71
mikeash wrote: post #66

Earlier quoted context omitted.

The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. For example, in Python: x = [1, 2, 3, 5, 8, 13] # this is a list of integers y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers There's nothing inherently wrong with C++'s initializer list approach. Nor is there anything inherently wrong with auto. Bu…

> The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. > For example, in Python: > x = [1, 2, 3, 5, 8, 13] # this is a list of integers > y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers Actually, that's not the best way to do it: y = {1, 2, 3, 5, 8, 13} # this is a set of integers without creating a…

Um, the whole point of this discussion is about the claim that C++ is a good language for beginners to learn.

I have problems with using C++ to build real projects with experienced programmers too, but those are mostly different problems.

Re: Popular Myths about C++, Part 1

#78

Post by Scea91 »

WhitneyLand wrote: post #43

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

With the recent updates to the standard C++ is actually a really pleasant language to use. You just have to know a lot, but the reward is there.

Re: Popular Myths about C++, Part 1

#79

Post by linuxlizard »

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.

Memory leaks in Firefox/Chrome might belie that notion.

I've had Python throw MemoryError at me while I was doing some video processing with NumPy. 8GB RAM, 64GB swap. I wasn't careful with my refs and I confused Python's garbage collection (memory leak).

Re: Popular Myths about C++, Part 1

#80

Post by mnem »

pierrebai wrote: post #60
mike-cardwell wrote: post #13

"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings." I just compiled the C code and the C++ code using: gcc -std=c99 -Wall -Wextra test.c -o test g++ -std=c++11 -Wall -Wextra test.cpp -o test According to valgrind: C: total heap usage: 1 allocs, 1 frees,…

This is the archetypal problem with benchmarks: not only are they hard to design, but people will incorrectly nit-pick the results. You count the number of allocations, without looking at the big picture: this is a toy example. It provides the hard-coded input to the function. This results in the C version not having to allocate memory for the hard-coded literals and the function problably being inlined and optimized…

It may not be the point of the example but it's mentioned explicitly by the article's author as a feature. Doesn't that make allocations in the example fair to comment on?
Post reply on HN