Popular Myths about C++, Part 3 • Hacker News Board

Re: Popular Myths about C++, Part 3

#81

Post by jevgeni » Tue, Dec 23, 2014, 2:15 PM UTC

inDigiNeous wrote: post #78

jevgeni wrote: post #65

Earlier quoted context omitted.

I completely agree. It's difficult to find a place for C++ in my little projects, given that I can use C for low level stuff and Python or Lua for high level stuff.

Then don't use C++. There's a tool for every need. I wouldn't use C++ either if there was an option for cross-platform, high performance, non-garbage collected way to program highly interactive VR -applications. There simply isn't, so I must use C++ and learn it. But got to say, my experiences with learning C++11 has changed how I view C++, it's much more robust and nice environment than what I thought, the new C++11…

I agree, that C++11 is an improvement. I was actually quite excited when Stroustrup's updated book on the subject came out. But like I said, I still can't find a fit for C++ in any of my projects. My use cases however are far different from yours, so I'm naturally opinionated away from C++.

Re: Popular Myths about C++, Part 3

#82

Post by kbart » Tue, Dec 23, 2014, 2:28 PM UTC

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.

To fully rebuild the whole project (U-Boot, Kernel, fs) I'm currently working takes 6 to 8 hours on 8 core i7 and believe me, I've done it may times.. So yes, compile time does matter sometimes.

Re: Popular Myths about C++, Part 3

#83

Post by Symmetry » Tue, Dec 23, 2014, 2:32 PM UTC

jayvanguard wrote: post #3

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. In 2010 it was completely indefensible. It is almost 2015, why are we even talking about it? C++ was a mistake. A bad detour on the highway of computing.

C++ is currently really the only choice if you're making an application that is both large and performance critical. If you're building a AAA video game or a web browser or a robot's navigation system then it probably is the best choice even if it's a painful one.

Re: Popular Myths about C++, Part 3

#84

Post by kbart » Tue, Dec 23, 2014, 2:37 PM UTC

chuckcode wrote: post #46

One of the reasons people use "low level code" for performance is because the STL doesn't easily provide control of memory which is critical to performance. Electronic Arts wrote their own version of the STL largely so they could better control memory [1]. I'm not really sure about the rest of the myths. I'm a little confused about how "To understand C++, you must first learn C” is a myth since C++ is a superset of C…

Actually, I've found that it's even undesirable to know C, because programmers, that came from C to C++, usually try to do everything in "C way" that leads to the code is "C with objects". To really learn modern C++, one must "forget" C and start with basic concepts.

Re: Popular Myths about C++, Part 3

#85

Post by rasz_pl » Tue, Dec 23, 2014, 3:02 PM UTC

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.

Yes, and if it doesnt just wait for better CPU, right? You work for microsoft?

Re: Popular Myths about C++, Part 3

#86

Post by jeorgun » Tue, Dec 23, 2014, 3:15 PM UTC

stinos wrote: post #69

I used a container version of sort() to avoid being explicit about the iterators Is that something new in C++14, coulnd't immediately find it on the net? Or is it just a version he wrote himself? The latter makes sense for pretty much all algorithms in which you'd use often on a container, to the point you'd start wondering why the standard doesn't provide them built-in.

The C++17 standard should have them, once concepts become a thing; iirc they're not in it now to avoid issues with choosing between sort(Container, Comparator) and sort(Iterator, Iterator) overloads.

Re: Popular Myths about C++, Part 3

#87

Post by kragen » Tue, Dec 23, 2014, 3:21 PM UTC

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 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 classes. MK3 I don't have any idea, but it was eventually released for a lot of platforms with different CPUs, so I doubt it was written in assembly.

Re: Popular Myths about C++, Part 3

#88

Post by humanrebar » Tue, Dec 23, 2014, 3:32 PM UTC

rasz_pl wrote: post #85

btmorex wrote: post #34

Earlier quoted context omitted.

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.

Yes, and if it doesnt just wait for better CPU, right? You work for microsoft?

If it doesn't, use qsort. C++ lets you do that.

Re: Popular Myths about C++, Part 3

#89

Post by humanrebar » Tue, Dec 23, 2014, 3:33 PM UTC

makomk wrote: post #73

btmorex wrote: post #34

Earlier quoted context omitted.

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.

Even if each instance of std::sort fits in the instruction cache, it's helping to push some other code elsewhere in the program out of the instruction cache, slowing that code down in the process.

If std::sort pushes something out of icache, it's to make room for inlining swaps and compares. I'm skeptical that the other things bumped from icache should be kept hotter.

Re: Popular Myths about C++, Part 3

#90

Post by humanrebar » Tue, Dec 23, 2014, 3:38 PM UTC

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…

Your concern is valid, especially since it includes measurements on a real project. But I'm not sure it's a major concern. One can (and you already do) use qsort when binary sizes become a concern.

This is an interesting optimization, but it's not suitable for a beginner-to-intermediate C++ audience, which is who Stroupstrup is addressing. The sensible default is to use std::sort.

If someone can (and it looks like you have) measure a benefit in doing something special, then she should have at it. If an entire project, again with measurements, can prove that std::sort shouldn't be its default sort algorithm, that's fine too.