Why C++?

[Aguila]

Every programmer should watch this video!

/>https://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

Use the pdf slides, because in the video they are hardly visible: http://ecn.channel9.msdn.com/content/WhyCPPCB2011.pdf

[Killboy]

I like C++ but he's just pulling most of that out of his ***.

Most likely any JIT compiler will in the end produce more performant code than if you leave the programmer to it. Of course real professionals can speed up code a lot, but average coders will just end up using constructs a good VM could eliminate.

C++ also requires you to build binaries for every architecture, a VM allows you to ship one file to multiple possible processor architectures, the VM then JITs the actual code. High-load code almost always runs in loops, which will be cached by the VM so thats no penalty there.

That's why Android chose Java, to be able to have single apk files for all phones. Of course some lazy bums started whining and Google bent over, producing the NDK. Yay! ARM only!

And for the efficiency part: That is easily countered by endless man hours spent getting features to work that are otherwise built into the framework.

[Aguila]

I don't think you watched the video. Your post is just off-topic.

[cozofdeath]

Watched it and found it kinda re-excited me about C++ because I'm always wondering what programming language I should really rely on to learn more about. Which is going to stick around and be extensively used.

[atom0s]

I like C++ but he's just pulling most of that out of his ***.

Care to go into more detail about why you think that? Not trying to start an argument but rather a discussion about your opinion,

Most likely any JIT compiler will in the end produce more performant code than if you leave the programmer to it. Of course real professionals can speed up code a lot, but average coders will just end up using constructs a good VM could eliminate.

At the risk, and sometimes guarantee, of unwanted overhead though. Depending on built-in framework objects, containers, methods, etc. all come at a price. Some perform great, others perform not so much. Most of which is why people recode things manually to handle objects, memory, garbage collection, and so on.

That's why Android chose Java, to be able to have single apk files for all phones. Of course some lazy bums started whining and Google bent over, producing the NDK. Yay! ARM only!

Having a single file for all phones doesn't change anything. And it doesn't justify the reason Adroid chose Java either. The language sits on top of the device. C/C++ can do this just as well and still be a single file for all phones using it. There is going to be a standard library for development (such as the Androids SDK) on any phone. Each device is going to have a higher-level of abstraction that sits on top of the devices hardware to handle communication between the device, its OS, and its apps.

Not sure if you stopped watching the vid after a short while or missed it but he even discusses the future of each platform (iOS, Android, and WinPhone7) which states that Android is supporting C/C++ in its next revision. Which it will be doing with a C/C++ specific SDK (C/C++ NDK (native)). iOS is also moving to support C/C++ too. All of which is being done because of performance.

http://developer.and.../ndk/index.html

The Android NDK is a companion tool to the Android SDK that lets you build

performance-critical

portions of your apps in native code.

And for the efficiency part: That is easily countered by endless man hours spent getting features to work that are otherwise built into the framework.

There is a pretty big difference between efficiency and performance though, and does really rely heavily on the purpose of the application. If you are building something that is fairly generic, has no intensive purpose, or any time-consuming or time-critical code, then sure it is more efficient to use whats given and be happy with what flaws or drawbacks it has such as overhead.

But when given a critical purpose that demands high-performance and efficient code, just using a framework that is prewritten by others that use a generic structure, that's not always the right choice. Think of health care systems, stuff in hospitals, diabetic pumps and other crucial devices that require performance, low-level efficiency, and so on. I can't say for sure they use C/C++ or even ASM specifically but my guess would be that they don't have the room to lose performance for the 'ease of coding' in the long run.

Again I'm not trying to fight or hate you. Just wanting to have a friendly discussion.

[Killboy]

Gotta admit I didn't watch more than the first 50% of it. What I was trying to say is that it's not just as black-and-white as he makes it out to be. He correctly says that there is no such thing as 'the better language', you have to choose the right tool for the job at hand. But then he goes on rambling about how awesome C++ is and how it outperforms anything else.

At the risk, and sometimes guarantee, of unwanted overhead though. Depending on built-in framework objects, containers, methods, etc. all come at a price. Some perform great, others perform not so much. Most of which is why people recode things manually to handle objects, memory, garbage collection, and so on.

I haven't seen any hard proof that C++ is substantially faster than e.g. C#, I realize that there has to be some impact from any VM or big framework but to what extent, really?

My point was that a half-assed attempt at a C++ dynamic array can end up being worse than the optimized and tested Java implementation. Granted, C++ compilers come with the STL but beyond that you're on your own.

Having a single file for all phones doesn't change anything. And it doesn't justify the reason Adroid chose Java either. The language sits on top of the device. C/C++ can do this just as well and still be a single file for all phones using it. There is going to be a standard library for development (such as the Androids SDK) on any phone. Each device is going to have a higher-level of abstraction that sits on top of the devices hardware to handle communication between the device, its OS, and its apps.

Using native binaries limits you to a single cpu architecture, plus (at least in the case of Android) you also limit yourself to a smaller set of APIs, in turn having to create workarounds for features that would be present for Java apps.

I can't think of many mobile apps apart from games that would require this kind of performance, but then again I don't know the actual performance difference between a 'normal' app and an equivalent app compiled with the NDK.

There is a pretty big difference between efficiency and performance though, and does really rely heavily on the purpose of the application. If you are building something that is fairly generic, has no intensive purpose, or any time-consuming or time-critical code, then sure it is more efficient to use whats given and be happy with what flaws or drawbacks it has such as overhead.

Fair enough. In the case of embedded systems/microchips you don't have as big a 'buffer' like running on a quad-core 12Ghz box, so I guess you don't really have much of a choice but optimize for performance.

I guess I got a little carried away with the ranting

[atom0s]

Gotta admit I didn't watch more than the first 50% of it. What I was trying to say is that it's not just as black-and-white as he makes it out to be. He correctly says that there is no such thing as 'the better language', you have to choose the right tool for the job at hand. But then he goes on rambling about how awesome C++ is and how it outperforms anything else.

Well the video is about performance.

Here's a site that has a ton of benchmark information comparing some of the most popular languages against each other:

http://shootout.alioth.debian.org/

Here's a study from Google comparing some of their personal benchmarks to their own language:

http://www.readwrite...e-benchmark.php

In almost every (at least every one that I looked at) C and C++ are first in every benchmark specifically aimed towards performance.

I haven't seen any hard proof that C++ is substantially faster than e.g. C#, I realize that there has to be some impact from any VM or big framework but to what extent, really?

My point was that a half-assed attempt at a C++ dynamic array can end up being worse than the optimized and tested Java implementation. Granted, C++ compilers come with the STL but beyond that you're on your own.

Depends on the comparison I'd guess. Overall running benchmarks, I'd say C/C++ will come out above C#/Java just because it's not running in a VM and worrying about the overhead of running in one. There isn't too many benchmarks specifically comparing the three, or even benchmarks that hold any weight or have any strong name behind them so it's rough finding solid information comparing that.

Granted the above link is well known so here is one comparison:

http://shootout.alio...lang2=gpp&box=1

Comparing a half-assed attempt to a proven implementation isn't really benchmarking properly either. Both sets would need to be proven and trusted solutions. Why would you benchmark two completely different things and try to reason their comparison? I think that's more of a cheap-shot. And the statement can work the other way around. Someone could make a terrible container in Java and it will be outperformed by similar containers in any language.

The STL is just like Java and C#'s included wrappers, objects, and methods. It's all the ease of doing common things on the platform without the cost of having to reinvent the wheel. But, it all comes with a price. The STL is nice and all when doing something basic to something more in-depth, but most of the time if you find a project that is heavy on processing and computing and uses any type of container or memory intensive things, they will have written their own containers, their own memory manager and allocators, etc. specifically to out-perform the STL. The STL is great but it is certainly not the best implementations of the things in it.

Before C++11's redo of some major components in the STL there are tons of flaws with how the containers in it work.

std::vector, for one, has tons of overhead depending on how it is used.

But that's the point of the STL just like any other set of tools/wrappers. They are there if you need them, but you are free to make your own. C# is the same, so is Java.

Using native binaries limits you to a single cpu architecture, plus (at least in the case of Android) you also limit yourself to a smaller set of APIs, in turn having to create workarounds for features that would be present for Java apps.

I can't think of many mobile apps apart from games that would require this kind of performance, but then again I don't know the actual performance difference between a 'normal' app and an equivalent app compiled with the NDK.

That wasn't really the point of this topic and the video though. Sure an emulator will handle varying architectures because they have all of them built into it. Which in turn is a loss of space if you want to get technical comparing that, since the install package is going to contain the ability to handle which ever platform it is on. But an install package for a C/C++ native application can do the same containing all the architectures in a single package and installing the appropriate one for the job.

Not specifically to the Adroid case, but in general. As for the Android performance, I dunno either, we'll have to wait and see when it becomes more popular. I'm not an Adroid user either so I'm not too certain how well it will do. I can only imagine if it is true native executing code though, it should perform well.

Fair enough. In the case of embedded systems/microchips you don't have as big a 'buffer' like running on a quad-core 12Ghz box, so I guess you don't really have much of a choice but optimize for performance.

I guess I got a little carried away with the ranting

Hehe, no worries. Discussions are fun to have on topics like this.

[Aguila]

I really like this video, because I think he is absolutely right with every point. He is not saying that all other languages are bad, but he is mentioning some good reasons why c/c++ is still the top language.

This is a nice proof: Do you know any complex and good Java/.NET applications?

I have thought a while after the video and I really don't know much. I know a few apps, but they are all simple so it doesnt really matter which language.

The best Java application for me is JDownloader.... but this is the truth: I have a good PC and this stupid java app takes about 4 seconds to start. This is just not acceptable.

There are some java IDEs written in java, probably only because they are IDEs for java... perfomance is also really bad.

VS 2010 start time about 3 seconds, ram about 100MB.... Netbeans 7 about 10 seconds start time, ram about 300MB.

VS 2010 has a .NET GUI, ok, the main part is of course in C/C++.