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

71–80 of 114 posts

Re: Popular Myths about C++, Part 3

#71

Post by Aldo_MX »

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.

Re: Popular Myths about C++, Part 3

#72

Post by kgabis »

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.

Re: Popular Myths about C++, Part 3

#73

Post by makomk »

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.

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.

Re: Popular Myths about C++, Part 3

#74

Post by throwawayaway »

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.

i worked out the number of compilations i did for a year and the cost of c++ vs. c for a 15000 line project and i think it came to ten minutes total.

which i found shocking, but there it was. my perception was different from the reality.

Re: Popular Myths about C++, Part 3

#75

Post by Scea91 »

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.

I am working on a project where full rebuild takes about an hour. Fortunately, we do not need to perform full rebuild often on our development machines so most of the time I can build with the changes I've made in between 10 secs to 5 minutes. I would expect this to be similar for other projects.

Surely we care about build speed, but there is no need to care about such micro optimizations as qsort vs std::sort. Most of the speedup is in correctly separating translation units and not including unnecessary header files (sometimes forward declaration is enough for example...).

With that said, when there are some tradeoffs then optimizing build speed is among one of the last things we care about.

Re: Popular Myths about C++, Part 3

#76

Post by jbergens »

cageface wrote: post #43
lomnakkus wrote: post #32

Earlier quoted context omitted.

False dichotomy. Plenty of people who "build really cool things with it" also bash C++, and rightfully so.

Nobody I know. People I know that use C++ every day will admit it has issues but are also realistic enough to understand that any language with the same design constraints and long history as C++ will be complex. It's the catbirds in the gallery that don't actually have to write the kind of apps that require a language like C++ that "bash" it.

But for projects that don't view those design constraints as very important and projects created when there were other languages that don't have the same history those compromises/explanations won't help. If/when there is a better language you don't have to suffer the history of C++ anymore, just use a newer language without the history. And if the constraints for example were to make it C compatible and very fast, for many projects those may not be of much importance anymore. Other language may be fast enough and easier to write in. I think it is probable that most of todays applications has lower speed requirements than C++ were aiming for. Those who needs speed can probably still use C.

Re: Popular Myths about C++, Part 3

#77

Post by pjmlp »

fiatmoney wrote: post #19

"C++ is a big language. The size of its definition is very similar to those of C# and Java." I can't speak with authority to C#, but C++ is a massively larger core language than Java with far more complicated semantics.

I think the biggest problem is that many idioms in C++ can only be understood by those of us that embraced the language since the C++ARM days and understand the design decisions to built the language on top of the C toolchain.

C++11 and C++17 might be quite a pleasure to use when a small team controls all the code, unfortunately most of the real world applications are done in pre-C++98 style.

And then, you still need to learn about each libraries use which version of the standard.

This is why there are so many fundamental types like string duplicated everywhere. We had to rely on third party libraries like Tools.h++ for consistency across compilers and OSs, before the majority reached C++98 compliance.

Re: Popular Myths about C++, Part 3

#78

Post by inDigiNeous »

jevgeni wrote: post #65
duaneb wrote: post #54

Earlier quoted context omitted.

If you're teaching programming, don't teach C++. If you're teaching systems programming, don't hide pointers. In this case, knowing the addition operator is useful iff they understand the underlying operations.... chances are, if they're learning C++, they don't.

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 and C++14 really bring some nice things to the table.

Re: Popular Myths about C++, Part 3

#79

Post by GFK_of_xmaspast »

ridiculous_fish wrote: post #25
agwa wrote: post #22

Earlier quoted context omitted.

Under what compiler? On GCC 4.9 they're neck-and-neck:: qsort: 6727 ms std::sort: 6718 ms (CPU is Core i7-950)

qsort wins by 2x with clang++ on OS X, 10x with g++-4.9 on OS X, and by about 14% with gcc 4.8 on Linux. This may be a pathological case for either implementation, since the array is already sorted. Still the point about std::sort requiring up to twice as many comparisons is valid.

" the array is already sorted"

Oh come on.

Re: Popular Myths about C++, Part 3

#80

Post by jevgeni »

inDigiNeous wrote: post #70
jevgeni wrote: post #64

Earlier quoted context omitted.

This is my point exactly. I'd consider both git and the Linux kernel tough projects, so the choice of the programming language is interesting. More so, given his stance on C++.

How come it's interesting ? Linus has always been a C -programmer, and kernel space is something where you want to keep things simple and access tha raw bits of things, so C is a natural choice. And if you've been programming C for 20 years or more, writing git with C feels like a natural solution. It's not always about writing stuff with the most high definition solution, it's more about expressing ideas with the to…

In the case of git, C++ was actually evaluated (in a manner very natural to Linus) and not discarded due to some habit:

http://harmful.cat-v.org/software/c++/linus

Post reply on HN