Live data from Hacker News

Popular Myths about C++, Part 3

isocpp.org

41–50 of 114 posts

Re: Popular Myths about C++, Part 3

#41
post #33

> I have never seen qsort beat sort Well, here you go: https://gist.github.com/ridiculousfish/bb511993deba1d148317 qsort: 674 ms std::sort: 1104 ms qsort only requires one invocation of the comparator to determine the order, while std::sort often requires two. So qsort ought to be faster when comparisons are expensive.

I'm not sure why std::sort should require two comparisons. It's not required to be stable (neither is qsort), so when comparing a and b gives (a >= b), std::sort can just assume (a > b) and the array will be sorted just fine.

Oops, you are correct and I was mistaken. std::sort does not need to determine the total order in order to sort.

I would amend my top-level comment but I don't seem able to.

Re: Popular Myths about C++, Part 3

#42

> I have never seen qsort beat sort Well, here you go: https://gist.github.com/ridiculousfish/bb511993deba1d148317 qsort: 674 ms std::sort: 1104 ms qsort only requires one invocation of the comparator to determine the order, while std::sort often requires two. So qsort ought to be faster when comparisons are expensive.

With unmodified code and the exact same compilation command, I get:

  qsort: 5818 ms
  std::sort: 4948 ms
Ubuntu 12.04 x86-64; g++ and clang++ give the same results.

EDIT: with clang and libc++, same compilation line otherwise:

  qsort: 5822 ms
  std::sort: 571 ms

Re: Popular Myths about C++, Part 3

#43

Earlier quoted context omitted.

There are people that sit back and bash C++ and then there are people that just roll up their sleeves and build really cool things with it. I'd certainly rather be in the second camp. I wouldn't mind having a simpler, more elegant language with the same design tradeoffs but that language doesn't yet exist.

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.

Re: Popular Myths about C++, Part 3

#44

> I have never seen qsort beat sort Well, here you go: https://gist.github.com/ridiculousfish/bb511993deba1d148317 qsort: 674 ms std::sort: 1104 ms qsort only requires one invocation of the comparator to determine the order, while std::sort often requires two. So qsort ought to be faster when comparisons are expensive.

When I run a modified version: http://pastebin.com/raw.php?i=XJup4FsU

    qsort: 10466 ms
    std::sort: 5137 ms

Re: Popular Myths about C++, Part 3

#45

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++11 is a very different language, in much the same way Java 8 isn't Java 1, or Visual Basic .NET isn't BASICA.

(It's entirely possible that all six of these languages are terrible, but that would be six separate claims.)

Re: Popular Myths about C++, Part 3

#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 so you kind of have to learn C.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...

Re: Popular Myths about C++, Part 3

#47
post #10

Earlier quoted context omitted.

"C++ sucks" has become a bit of a meme around here. The upsides outweigh the downsides for a surprising number of cases. Every alternative is either immature, doesn't solve the use case that needs C++ or doesn't have the required libraries/tools.

There are people that sit back and bash C++ and then there are people that just roll up their sleeves and build really cool things with it. I'd certainly rather be in the second camp. I wouldn't mind having a simpler, more elegant language with the same design tradeoffs but that language doesn't yet exist.

My experience with legacy C++: Main problem with C++ is that it has lots of accidental complexity and a relatively weak standard feature set. The lava layer pattern is apparently very hard avoid in old applications. Due to the aforementioned weaknesses the lava layering now applies also to the modules that would be standard static modules in other languages. So it's a bit wastefull.

But since lava layering is caused by cultural and architectural issues I cannot claim that the system would be in any better shape just if some other language had been used.

Re: Popular Myths about C++, Part 3

#48
post #40

Earlier quoted context omitted.

Let's try again, with a more C++14 like solution: sort(v.begin(),v.end(),[](const auto x, const auto y) { return *x > *y; }); instead of your line 39: sort(v.begin(),v.end(),[](const string *x, const string *y) { return *x > *y; }); Some results: • g++ 4.9.2 with O3 qsort 545ms, sort 7289ms • clang with O3 and libc++ qsort 551ms, sort 844ms I've used: clang++ -std=c++1y -stdlib=libc++ -O3 test.cpp and g++-4.9.2 -std=…

The first is comparing pointers, not strings. I wouldn't call this a fair comparison.

+1 I stand corrected.

I've updated my tests and qsort seems to be faster than sort, for this particular test case.

Re: Popular Myths about C++, Part 3

#49

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…

I guess that depends on your definition of 'easily' - you can provide custom allocator s fairly easily. What's more problematic are things like the memory usage patterns of std::vector and std::string. Once you know how they work you can avoid the pitfalls or use custom alternatives.

Re: Popular Myths about C++, Part 3

#50

> “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 time ago, but I gave up eventually. Happily my frustration with C++ led me to investigate other programming languages (not that it was the only one I had used), and I write precious little in it lately -- mostly just to modify code others have written in it.

Post reply on HN