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

101–110 of 114 posts

Re: Popular Myths about C++, Part 3

#101

Post by comex »

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.

In addition to the "unless you sort 10 elements" factor, as stated in a sibling comment -

LLVM + libclang together are already 46MB of code, and they're libraries designed to be statically linked. Sure, they aren't going to fill your drive, but they will take a comparative while to load from disk (especially as part of another application - doesn't matter much on the command line), and it's that much harder to justify including them in an otherwise small downloaded package.

Re: Popular Myths about C++, Part 3

#102

Post by comex »

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.

It matters to me because when I'm "in the zone", every second spent waiting for a compiler to do its thing is a small loss of focus; ideally I'd like incremental compilation time to be below a second. Your brain may be less sensitive to this latency, but I think loss of focus happens to everyone to some extent.

The cost of template instantiations by itself is not too significant, and they ought to be cacheable in the future C++ module system, along with the header file parsing that's the biggest factor making C++ take longer to compile than, say, C. But with today's compilers, it all adds up.

Re: Popular Myths about C++, Part 3

#103

Post by yongjik »

jevgeni wrote: post #80
inDigiNeous wrote: post #70

Earlier quoted context omitted.

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

> I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

Quintessential Linus, but I wouldn't call this an "evaluation"... :)

Re: Popular Myths about C++, Part 3

#104

Post by infogulch »

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…

Does C++ not deduplicate templates that work on the same size types? E.g. if I used std::sort on arrays of `int`, `unsigned`, `float`, and half a dozen structs of exactly 4 bytes, I don't see why there would need to be more than one copy of the template in the final binary.

Re: Popular Myths about C++, Part 3

#105

Post by Aldo_MX »

humanrebar wrote: post #91
Aldo_MX wrote: post #71

Earlier quoted context omitted.

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

Of course compile time matters when features like modules provide a significant improvement.

My question was more focused in having to work around the compiler by doing micro-optimizations, or avoiding some features that "may be heavy", just because one project will take 65535ms instead of 65000ms to do a minimal rebuild.

But at the end of the day, it really depends on the dimensions of the project. In a huge project an improvement from 8 hours to 7.5 hours is greatly appreciated.

Re: Popular Myths about C++, Part 3

#106

Post by imanaccount247 »

pmelendez wrote: post #97
imanaccount247 wrote: post #30

Earlier quoted context omitted.

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()…

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

Yes. C is very small and simple. You can learn all of C in a very short time. C++ is the most complex programming language in existence. It is unlikely that there is any person in the world who actually knows it all, including the creators.

>or you could try to implement or use an existing implementation of a dynamic array

Imagine that. You could use libraries that implement things you want. What a concept.

Re: Popular Myths about C++, Part 3

#107

Post by imanaccount247 »

pmelendez wrote: post #94
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 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++)

The original unreal in 1998 was C with classes. And a significant amount of asm. And note that was in 1998, and part of the sales pitch was that it was OO, which was essentially unheard of at the time. C++ compilers were still really bad at the time, and if you wanted to be portable you really couldn't use much besides C with classes. The unreal engine has been rewritten from scratch several times over the years. What we have now is not indicative of what we had 15 years ago.

Re: Popular Myths about C++, Part 3

#108

Post by pmelendez »

imanaccount247 wrote: post #106
pmelendez wrote: post #97

Earlier quoted context omitted.

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()…

>Do you really think C is any easier to understand that C++? Yes. C is very small and simple. You can learn all of C in a very short time. C++ is the most complex programming language in existence. It is unlikely that there is any person in the world who actually knows it all, including the creators. >or you could try to implement or use an existing implementation of a dynamic array Imagine that. You could use librar…

> "Imagine that. You could use libraries that implement things you want. What a concept."

I think I didn't explain myself, but something that basic in these days should be on the standard library in my opinion.

>"Yes. C is very small and simple. You can learn all of C in a very short time."

I don't think C is simple at all. Its syntax can be really cumbersome at times (see my first example). Also it is very annoying to debug, and C code is very prone to contain memory corruption bugs and leaks.

C has great advantages but being simple is not one of them.

Re: Popular Myths about C++, Part 3

#109

Post by imanaccount247 »

pmelendez wrote: post #108
imanaccount247 wrote: post #106

Earlier quoted context omitted.

>Do you really think C is any easier to understand that C++? Yes. C is very small and simple. You can learn all of C in a very short time. C++ is the most complex programming language in existence. It is unlikely that there is any person in the world who actually knows it all, including the creators. >or you could try to implement or use an existing implementation of a dynamic array Imagine that. You could use librar…

> "Imagine that. You could use libraries that implement things you want. What a concept." I think I didn't explain myself, but something that basic in these days should be on the standard library in my opinion. >"Yes. C is very small and simple. You can learn all of C in a very short time." I don't think C is simple at all. Its syntax can be really cumbersome at times (see my first example). Also it is very annoying…

>I think I didn't explain myself, but something that basic in these days should be on the standard library in my opinion.

Ok well you hop in your delorian and go back to 1970 and let them know. In the mean time, how does that in any way make C not capable for the same tasks as C++?

>I don't think C is simple at all

Then you don't know C. The entire point of C is that it is simple.

>Its syntax can be really cumbersome at times

That has nothing to do with simplicity, and C++ has far more complex syntax.

>Also it is very annoying to debug

C is very simple and straight forward to debug. C++ is much more difficult to debug. Have you ever used either language?

>and C code is very prone to contain memory corruption bugs and leaks.

Because it is so simple.

>C has great advantages but being simple is not one of them.

Well your opinion is in the vast minority, and does not seem to have any basis in reality. The C spec is a tiny fraction of the size of the C++ spec.

Re: Popular Myths about C++, Part 3

#110

Post by pmelendez »

imanaccount247 wrote: post #109
pmelendez wrote: post #108

Earlier quoted context omitted.

> "Imagine that. You could use libraries that implement things you want. What a concept." I think I didn't explain myself, but something that basic in these days should be on the standard library in my opinion. >"Yes. C is very small and simple. You can learn all of C in a very short time." I don't think C is simple at all. Its syntax can be really cumbersome at times (see my first example). Also it is very annoying…

>I think I didn't explain myself, but something that basic in these days should be on the standard library in my opinion. Ok well you hop in your delorian and go back to 1970 and let them know. In the mean time, how does that in any way make C not capable for the same tasks as C++? >I don't think C is simple at all Then you don't know C. The entire point of C is that it is simple. >Its syntax can be really cumbersome…

>Ok well you hop in your delorian and go back to 1970 and let them know.

Well they could have added in C99 or more recently in C11. What's wrong about updating a language?

> In the mean time, how does that in any way make C not capable for the same tasks as C++?

I would rather prefer not reinventing the wheel and a language that actually ship with it.

> Then you don't know C. The entire point of C is that it is simple.

I know C fairly well to recognize it quirks (just like all languages have). I think your definition of simple is very different of mine. Scheme is simple, InteractiveC is simple, C it is not.

> That has nothing to do with simplicity, and C++ has far more complex syntax.

cumbersome(adj): difficult because of extent or complexity

simple(adj): 1.easily understood or done; presenting no difficulty. antonyms: complex

How come something cumbersome has nothing to do with simplicity?

Also I am not saying that C++ is simple. But it has a subset that it is well defined, type safe and easy to understand.

> C is very simple and straight forward to debug. C++ is much more difficult to debug. Have you ever used either language?

Yes, I have used both in my formal job, and I can avoid memory leaks and memory corruption easily on C++. Not the case on C, specially when working in medium size teams where always people forget what they should cast a void* into and why they should not.

>>and C code is very prone to contain memory corruption bugs and leaks.

>Because it is so simple.

Seriously? It is a feature now? Well Scheme is a good example of language that is order of magnitudes simpler than C and it is not prone to memory leaks nor memory corruptions

>"Well your opinion is in the vast minority, and does not seem to have any basis in reality. The C spec is a tiny fraction of the size of the C++ spec."

If by simple you mean simpler than C++, yeah. You could say the same of Perl. Does is it make Perl a simple language?

Post reply on HN