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

Popular Myths about C++, Part 3

isocpp.org

Post reply on HN
Print view View original

91–100 of 114 posts

Re: Popular Myths about C++, Part 3

#91

Post by humanrebar »

Aldo_MX wrote: post #71
comex wrote: post #51

Bjarne should know better than to directly compare the performance of std::sort and qsort. One is typically printed in full in a header file, while the other is typically compiled separately. If qsort were found in a header file, it could be inlined into identical code to the C++ version, regardless of the fact that there are void pointers lying around everywhere. There are caveats: the compiler might not choose to i…

Does compile time really matter that much? I mean, unless you are building a huge project which is expected to take hours to compile, I don't see much benefit in optimizing compile times.

> Does compile time really matter that much?

Yes. Which is why C++ needs modules. It's a big problem when people have to alter their designs to work around their tools (compilers, in this case).

Re: Popular Myths about C++, Part 3

#92

Post by imanaccount247 »

kragen wrote: post #87
imanaccount247 wrote: post #29

Earlier quoted context omitted.

In 1995 most games were in C or asm, not C++. Even will into 2000+ as asm faded out, C was still big and the C++ usage was largely as C with classes.

I wasn't writing games in 1995 but I suspect you are mistaken. Fortunately https://en.wikipedia.org/wiki/1995_in_video_gaming tells us about the major games that year; unfortunately there are 33 of them. Descent and Mortal Kombat 3 are the ones I remember. https://github.com/drguildo/Descent/blob/master/MAIN/AUTOMAP... Descent is written in C++ (note the "//" comments) but it's a very C-styled C++, not even with clas…

>Descent is written in C++ (note the "//" comments) but it's a very C-styled C++, not even with classes

That is C. Lots of C compilers supported // comments, like watcom which they used. Notice the file extension says it is C. Notice it uses absolutely no C++ features at all.

http://en.wikipedia.org/wiki/RollerCoaster_Tycoon Still using ASM in 1999. Go look at quake 3 which was when id started into C++. Notice how it is barely C++. It seems odd to "suspect I am mistaken" rather than look at the evidence which lines up exactly with what I said.

Re: Popular Myths about C++, Part 3

#93

Post by ant6n »

btmorex wrote: post #34
chisophugis wrote: post #23

What Bjarne doesn't mention is the enormous difference in code size between qsort and std::sort. The flexibility of having the compiler generate a sorting routine from std::sort is convenient but enormously redundant in many cases. In LLVM, we have array_pod_sort which is just a thin wrapper around qsort in order to avoid the code bloat of std::sort: http://llvm.org/docs/doxygen/html/namespacellvm.html#ae5788f... For…

As long as std::sort can fit in the instruction cache, who cares? (outside the embedded world obviously) It will always be faster unless you're getting regular instruction cache misses.

Unless you sort 10 elements

Re: Popular Myths about C++, Part 3

#94

Post by pmelendez »

imanaccount247 wrote: post #29
pmelendez wrote: post #13

Earlier quoted context omitted.

>"In 1995 C++ it wasn't a good choice. In 2000 it was a poor decision in most cases. In 2005 it was a bad decision in almost every case. " Was it? Most console games are written in C++ in that period of time. A very popular desktop office suite is built on C++. The most popular design and photograph edition tool for Windows is written using C++. So you are suggesting that all those guys who picked C++ for those popul…

In 1995 most games were in C or asm, not C++. Even will into 2000+ as asm faded out, C was still big and the C++ usage was largely as C with classes.

I am not sure about 1995. But at least since 1998 exists Unreal engine and the amount of games using it is humongous. And Unreal's source code is more involved that just C with Classes. (Which by the way is still C++)

Re: Popular Myths about C++, Part 3

#95

Post by pmelendez »

nocman wrote: post #50
JoshTriplett wrote: post #2

> “To understand C++, you must first learn C” > “C++ is an Object-Oriented Language” > “For reliable software, you need Garbage Collection” > “For efficiency, you must write low-level code” > “C++ is for large, complicated, programs only” Well, 2.5/5 of those aren't myths. You certainly don't need to write low-level code for efficiency, C++ does a rather poor job of acting like an OO language, and you don't need Garb…

"And C++ isn't just for large, complicated programs; it's for small, complicated programs too." hahahahahahaha!!!!!!!!!!!!!!!!!!! -- I was thinking that, but hadn't put it into those exact words yet. I was thinking something like "C++ is definitely for complicated programs" -- not that they necessarily need to be complicated, but that C++ often unnecessarily complicates them. I really wanted to like the STL a long ti…

>"I was thinking something like "C++ is definitely for complicated programs"

I am not sure which language are you comparing it to but there is definitely a subset of C++ that is easy to use, very readable and type safe.

My only problem with C++ is somebody else code, because there is also a terrible subset of C++ where things can turn very hairy. But same can be said about C, and actually C sometimes encourage you to be "clever".

Re: Popular Myths about C++, Part 3

#96

Post by chuckcode »

kgabis wrote: post #72

That qsort example is getting tedious. I wonder why restrict keyword is never mentioned when talking about C++'s performance advantages over C - it can offer a huge boost on modern CPU architectures. I know it's supported by all major compilers, but still - it's not a part of C++'s standard.

Completely agree. Restrict keyword can free up the compiler to vectorize a lot of code with sse and avx on intel chips.

[1] http://locklessinc.com/articles/vectorize/ [2] http://stackoverflow.com/questions/1965487/does-the-restrict...

Re: Popular Myths about C++, Part 3

#97

Post by pmelendez »

imanaccount247 wrote: post #30
adamnemecek wrote: post #5

Earlier quoted context omitted.

So what's an alternative?

C?

Do you really think C is any easier to understand that C++?

Let's do something simple, a function that returns a reference to an array of a known size.

Some of C alternatives would be:

    int (*foo())[2] {
    }
or maybe if you have the length somewhere else:

    int** foo ()
    {
    }
or you could try to implement or use an existing implementation of a dynamic array (nothing in the standard as far as I know)

vs.

    std::vector& foo() {
    }

Re: Popular Myths about C++, Part 3

#98

Post by kragen »

imanaccount247 wrote: post #92
kragen wrote: post #87

Earlier quoted context omitted.

I wasn't writing games in 1995 but I suspect you are mistaken. Fortunately https://en.wikipedia.org/wiki/1995_in_video_gaming tells us about the major games that year; unfortunately there are 33 of them. Descent and Mortal Kombat 3 are the ones I remember. https://github.com/drguildo/Descent/blob/master/MAIN/AUTOMAP... Descent is written in C++ (note the "//" comments) but it's a very C-styled C++, not even with clas…

>Descent is written in C++ (note the "//" comments) but it's a very C-styled C++, not even with classes That is C. Lots of C compilers supported // comments, like watcom which they used. Notice the file extension says it is C. Notice it uses absolutely no C++ features at all. http://en.wikipedia.org/wiki/RollerCoaster_Tycoon Still using ASM in 1999. Go look at quake 3 which was when id started into C++. Notice how it…

Thanks for helping me look at the evidence! Maybe you're right. Do you want to pick another two or three random games from that list and figure out what language they're written in? Or figure out what MK3 was written in? I was trying but then I ran out of time while writing my comment.

I don't think RollerCoaster Tycoon is a good piece of evidence because it's famous largely for being written in assembly at a time when most games had already abandoned it.

(Sadly, I don't think it would be odd at all to ignore the evidence, but I aspire to better than that.)

Re: Popular Myths about C++, Part 3

#99

Post by Torgo »

imanaccount247 wrote: post #29
pmelendez wrote: post #13

Earlier quoted context omitted.

>"In 1995 C++ it wasn't a good choice. In 2000 it was a poor decision in most cases. In 2005 it was a bad decision in almost every case. " Was it? Most console games are written in C++ in that period of time. A very popular desktop office suite is built on C++. The most popular design and photograph edition tool for Windows is written using C++. So you are suggesting that all those guys who picked C++ for those popul…

In 1995 most games were in C or asm, not C++. Even will into 2000+ as asm faded out, C was still big and the C++ usage was largely as C with classes.

It's unfortunate that you were downvoted when you're right, at least for the console space. You couldn't use many of the advanced features of C++ on the consoles of 1995 (rtti, exceptions, STL was garbage in 1995); C++ compilers were all non-conforming and so cross-platform was horrible; code optimization was bad and space/cpu was at a premium. I don't think either the Saturn or the PS1 devkits even had a C++ compiler in 1995 though it would have been possible, and the other consoles definitely didn't. I think people get used to how well things work and how ubiquitous tech is now and they don't remember how it used to be.

Re: Popular Myths about C++, Part 3

#100

Post by comex »

blub wrote: post #61
comex wrote: post #51

Bjarne should know better than to directly compare the performance of std::sort and qsort. One is typically printed in full in a header file, while the other is typically compiled separately. If qsort were found in a header file, it could be inlined into identical code to the C++ version, regardless of the fact that there are void pointers lying around everywhere. There are caveats: the compiler might not choose to i…

Are you sure that the callback can be inlined though? How would that work, the calls through the pointer would be replaced with the function body? I would assume that qsort itself could be, but that wouldn't help much.

Yes - modern compilers can replace function pointer calls with direct calls if the value is known, and from there they can be inlined.
Post reply on HN