I see that most of the apps that include heavy GUI content are usually developed in C++. Most of the games/browsers are coded in C++.

Can't we just develop better GUI apps with the latest dynamic languages? I know java wouldn't be a great choice. But what about languages like python which are natively built on C? Aren't the latest languages supposed to be better than their ancestors? Why do we still have to prefer the age old C++ over the latest languages?

And I would also like to know, what is it that is responsible in C++, for the better speed of processing GUI? On the other hand what is it that the other latest languages lack?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

18

If you think that Java is a 'dynamic' language, then you're deeply confused about what that word means in this context.
–
Mike BaranczakMay 31 '11 at 14:04

11

@Mike Baranczak: That's a long story. Basically, there was a research project first at Stanford, later at Sun Research called Self. Self is a programming language in the Smalltalk family that is simpler, more powerful, more expressive and most importantly significantly more dynamic than Smalltalk. Because it was designed as a programming language to develop whole systems in (as all Smalltalk dialects are), including (but not limited to) desktop applications, servers, operating systems, device drivers, itself, it had to blazingly fast. So, the Self team invented a whole bunch of new ...
–
Jörg W MittagJun 1 '11 at 1:09

11

... optimization techniques, and when the Self VM came out in 1987 (and even more so the second generation in 1992), it was fast. It was faster than any other Smalltalk VM. The Self system shipped with a lot of example code, and one of those examples was a Smalltalk interpreter written in Self, and even that was faster than any other Smalltalk VM. Self was faster than many C++ implementations at that time, and even competitive with C. Well, you get it. It was fast. However, Sun decided that they didn't have a need for an object-oriented programming language or a fast VM, so they ...
–
Jörg W MittagJun 1 '11 at 1:12

11

... basically starved the Self project to death by drying up the funding. When the Self VM engineers left Sun out of frustration, they were quickly scooped up by a Smalltalk startup called LongView (more commonly known by the name of their most product, an optional static type system for Smalltalk: StrongTalk). LongView knew that they would never be able to sell static typing for Smalltalk, so they thought they would rather sell the fastest Smalltalk on the planet and then include StrongTalk in the package in a sort-of Trojan Horse kind of play. They also realized that none of the cool ...
–
Jörg W MittagJun 1 '11 at 1:15

11

... optimizations the Self VM did were in any way particular to Self, but were applicable to pretty much any object-oriented language (or even just any language at all). So, the Self VM engineers got to work on a Smalltalk VM called the Animorphic VM. Again, the Animorphic VM was blindingly fast (and still is, actually, even though the codebase hasn't been touched in 15 years or so, it can still compete with modern high-performance Smalltalks, JVMs and .NET, especially if you take into account that it uses a lot less resources than those, since it was designed for 486s with 20 meg ...
–
Jörg W MittagJun 1 '11 at 1:19

13 Answers
13

I'm one of those people who write C++ GUI apps (mostly for windows). With Qt, to be precise. My reasons:

I like C++. I'm a freelancer and usually I can choose my tools (lucky me!)

In a managed environment you may have a hard time when you need to use some unmanaged code (long-winded WinAPI declarations in C#, anyone?)

Less/easily deployable dependencies

More control over everything.

RAII (vs. GC). And even if I allocate with new, I rarely ever delete anything explicitly, because I use smart pointers or the QObject hierarchy.

C++ is very exciting these days, I can't wait for a compiler to fully support the new standard.

Speed (only at the end of the list. I know it's not that important for the GUI itself, but it tends to be speedier because C++ programs don't suffer from the overhead that runtimes, byte code JIT-compiling and similar technologies add to the program.)

As you can see, these are mostly personal preferences. I find it important for my work to be enjoyable and C++ provides that to me.

+1 Speed is definitely the top reason here, aside from personal preference. However, I like "C++ is very exciting these days". To address the question-asker, not @Tamás Szelei: Sure, computing changes quickly with new ideas, paradigms, technologies, products but the latest and greatest is not a virtue. C++ has been around for a while and it doesn't mean it is outdated, rather it has a long proven track record compared to newer technologies. The original Stroustrup text (the inventor's book) is heavy going but there are some nice books out there by others - check oreilly.com for example.
–
therobyouknowMay 31 '11 at 12:11

1

@Tarnas I think "always will be faster" is a bit narrowminded/authorative, but not enough to warrant a downvote...
–
MaxMay 31 '11 at 13:24

Yes, that wording was unfortunate, thanks for bringing it to my attention. I changed it.
–
Tamás SzeleiMay 31 '11 at 13:57

1

As anecdotal support: I've been involved in different projects to create significantly sized GUIs on Windows using C++ and JavaScript. I've also been involved in different game console projects in C++ and JavaScript. In both cases, there were significantly more speed and memory issues with JavaScript.
–
Steven BurnapMar 12 '14 at 18:41

1

Late to the party, but can you elaborate on the "less/easily deployable dependencies"?
–
weberc2Mar 20 '14 at 20:39

Games use C++ for core tasks, where performance is important. They use dynamic languages for scripting tasks where flexibility is important.

Desktop GUI apps: Visual Studio, for example, is written in .NET and not native C++. It seems to work quite well for an IDE, as the IDE itself doesn't need to do lots of performance intense tasks. (The compiler, linker and other tools are not necessarily written in .NET - though as wawa points out in a comment, some appear to be (e.g. VB.NET))

Browsers need to be fast too. After all they are kind of a secondary OS. On the other hand, you can argue that large parts of Firefox are actually "written in" javascript, as the Mozilla framework seems to heavily depend on javascript.

To sum up: I would not say C++ is necessarily preferred but if you have a performance bottleneck you have to go closer to the metal and then you meet C++ (well, or C). Sometimes it will just be easier to do everything in C++ -- one language.

+1 Best answer: It's purely to do with speed as the top reason for using C++. Even Microsoft themselves concede that C++ is best for performance compared with c# and visual basic - see their into on their Visual Studio pages. A very close second is portability - if you use cross platform libraries such as Qt. Best answer also because it's objective rather than subjective.
–
therobyouknowMay 31 '11 at 12:07

2

Your second point isn't entirely true. The VB.NET compiler is writen in VB.NET and the F# compiler is written in F#. The C# compiler isn't but from what has been released about project Roslyn, I think the C# compiler is being rewritten in C#.
–
Wesley WiserMay 31 '11 at 14:27

4

The visual studio gui (the chrome) is written (from vs2010) in c# and WPF. The solution explorer, build system, code browser and toolbox is written in c#/c++ with winforms. The compiler is written in c++.
–
Martin BeckettMay 31 '11 at 15:55

For most desktop apps, only the rendering and layout engines (i.e., the View) need to be fast. The Model doesn't tend to have much time spent in it anyway, and the Controller spends most of its time just waiting for the user to do something (and few users can click as often as 10 times a second with any reliability).
–
Donal FellowsMar 13 '14 at 0:55

The GUI apps that you see written in C++ are generally done so due to legacy reasons. Python (with Qt or Gtk) is very much viable for GUI applications, as is C# if you work in a Windows house. When starting something new, either is very much preferred to C++ because of the lack of plumbing work that has to be done.

+1 existing code is important. It is rare to start completely from scratch when developing new programs
–
user1249May 31 '11 at 7:35

3

how is using Python with Qt any more preferable to using C++ with Qt? If I were to start a new project today, I'd still use C++ for the GUI. Because: a) It's what I know, b) it does the job well. Just because C++ has been around a while doesn't make it "outdated".
–
TZHXMay 31 '11 at 8:19

2

@TZHX: "It's what I know" is a viable argument. If that's not given, not having to look after memory management anymore is a huge performance boost, and it may offset the effort of learning Python even for a single project. Another reason for using Python would be cross-platformness - with C++, you have to be careful and take special measures, whereas python is likely to just work.
–
tdammersMay 31 '11 at 8:27

7

C++ is likely to just work, also. With Python you have to worry about which version of python the user has installed, or worry about bundling it. There really isn't that much work to be done "looking after memory" unless you make stupid errors. I think lots of people give "memory management" as a big hindrance to working with C++ without actually knowing how much difference it makes.
–
TZHXMay 31 '11 at 10:36

2

@TZHX Same thing applies to C++ - "Just works" isn't exactly always true, concerning shared libraries, DLL hell, architecture mismatches, dependencies etc. That said, I really like C++ as a language, so this is not just harping from someone who don't like the language.
–
MaxMay 31 '11 at 13:05

Because no matter how many performance tests .NET and the like crowds show, no matter how close they come in benchmarks, in the end, C++ app comes out on-top. It's faster at cold boot, it's snappier, and has more ways it can be improved.

I have heard numerous proofs at the project starting phases that .NET is the way to go, but once it's chosen, they always ended up being a heavy cludge.

Also, C++ nowadays is quite safe and quite easy to use, especially with frameworks like Qt or WTL.

+1: "Also, C++ nowadays is quite safe and quite easy to use, especially with frameworks like Qt ..." I totally agree: I think a big strength is not (only) C++ in itself, but the fact that (1) it is compiled to native code, (2) has a reasonable set of features (OOP, templates), (3) has very good frameworks like Qt. This compensates the fact that the language is rather large and difficult to learn: once you master a decent subset of the language and some good libraries, you can be really productive with it.
–
GiorgioOct 10 '11 at 19:30

Most of game engines are coded in C++. Also lot of browser engines are coded in C++. But the browser GUI is often coded using some lightweight script (JavaScript, Python). With notable exception of Source Engine, most games engines also use scripting languages (like Lua or Python). [for reference: list of Lua scripted games]

Also take popular C++ GUI library like Qt. In current version (4.7) it uses QML for the GUI. QML is basically JavaScript with Qt bindings.

[Citation Needed]. I know many games uses scripting languages to let users extend them, but as far as I know there aren't really many games using scripting languages for their release-binary-functionality.
–
ProdigySimMay 31 '11 at 15:42

1

@ProdigySim: I know of several that do. Off the top of my head, World of Warcraft (Lua+XML), Naughty Dog's Uncharted series (Lisp), the Unreal series (UnrealScript), games based on the Torque and Unity engines, Dungeon Siege, NeverWinter Nights, and many others. Data-driven games are becoming the norm, where the scripting host takes over most (if not all) UI features and game state from top to bottom.
–
greyfadeMay 31 '11 at 16:22

@ProdigySim: even if it's hidden from normal users, doesn't mean that internally they don't use scripting engines. Basically game developers have two options -- create their own scripting language for models or use one of general purpose ones. Lua is especially good for games, as it's generally good for real-time systems.
–
vartecMay 31 '11 at 20:01

The reason is that you have much more control over everything that happens. If you were going to write photoshop in C#, you would have serious performance problems for some tasks. In a lower level language with more control, you can take shortcuts, optimize where needed for things that are more intense. Of course this assumes you are using C++ in unmanaged code, not C++ in .NET.

Adobe Lightroom, which is basically a subset of Photoshop, is written in Lua.
–
Jörg W MittagMay 31 '11 at 11:49

3

@Jörg: and the rest of it is C++. in fact that's probably the best combination available, C++ for the foundation, Lua for the rest (althought i still prefer C over C++ for low-level things).
–
JavierMay 31 '11 at 14:14

2

@Javier: Yeah, Lightroom is basically the image manipulation algorithms from Photoshop (which are probably written mostly in MMX/SSE assembly) and SQLite3 (which is written in pre-historic ANSI C for portability) glued together with Lua. Adobe also developed their own Lua IDE, completely in Lua. Does anyone know what graphics toolkit they use? AFAIR Photoshop predates pretty much all modern toolkits, so it's probably something home-grown?
–
Jörg W MittagMay 31 '11 at 16:07

3

no offense, but if you think ANSI C is prehistoric, you've been reading the wrong code samples
–
JavierMay 31 '11 at 18:37

Most of the reasons given are technical or "above the table"... here are business reasons or the "under the table":

distributing compiled code v.s. distributing source code. when developing in c/c++ you distribute the binaries. if you are developing in one of the modern languages, you distribute the source. it is difficult to sell the idea of obfuscators to management who have to answer to shareholders/investors so don't bother.

stupid users: at least in the minds of the management. they still perceive their users to be barely able to double click a "setup.exe". If you include the installation of an interpreter as part of the setup, they will shake their heads from side to side.

old developers: most people with experience have been around for a long time, and have not kept themselves updated. they program in C++ and not in the newer languages, because they don't know the newer languages.

I would argue you are distrubuting source code when you release a .NET application. Look at Visual Studio much of the interface is designed with WPF forms. Some of your points are of course valid, much of today's management were yesterday's developers, the bad news much of today's frameworks are unlikely to be valid because of the changes to computers today.
–
RamhoundMay 31 '11 at 13:09

Lots of people with lots of experience have gained their experience by keeping themselves updated. They tend not to learn hot new languages (like Pascal in the early 1980s) just because they're hot, but only if they have a use for them or they have interesting ideas (Haskell, for example).
–
David ThornleyMay 31 '11 at 14:35

I would extend the scope of the problem from GUI to software that is expected to be competitive. C++ imposes no tax on the target platform as it concerns processing power, installed runtime, frameworks etc. So it will work on more limited customer hardware than a similar solution written in a managed/interpreted language. In the case of a successful commercial software the cost of development (potentially higher in the case of C++) is amortized by the number of sales.

Additionally C++ usually offers direct access to system apis (like GUI) what gives the best opportunity to optimize utilization and differentiate itself from similar solutions.

You are mentioning browsers and games as examples. Both of these are pretty performance critical applications, so having them in a low-level language for speed makes sense.

Many other applications are less performance bound and could easily be written in other languages. C# in particular seems to be used a lot. (And Obj-C, but it does not really qualify as high-level I guess. Better than C++ though.)

However, there is a certain lack of frameworks for the latest programming languages. For example, there is no viable native GUI library for Python, really. Sure, you can use PyQt or PyGtk and they work well, but in the end, that is only interfacing with C code again. Again, C# (and arguably Obj-C) seems to be the exception and maybe, MacRuby or IronPython could change that game.

I think a lot of it has to do with the APIs for GUI toolkits. All of them have a C/C++ API, but not all of them have (say) Python bindings. And sometimes the toolkits themselves were written with C++ in mind, so even if they do have support for other languages they don't fully support them (e.g., they won't support a Python tuple as an argument).

C++ is statically typed. This allows to optimize code execution beforehand by having a compiler fit your abstractions to available system process on a given platform. Up to now, dynamic languages need an additional software layer (= the interpreter) which slows down access to system resources.

For a language to replace C++ or Java, it has to do what is sorely missed in these languages besides out performing them at their own strengths. Also, huge investments have gone into these languages. That means there is a standard C++ library on many platforms, which browsers, games and such programs can readily use. So there is bound to be some inertia. Languages tend to take off slowly unlike other pieces of software.

If you look at it, Anaconda (RedHat's installer program) has been around for 10 or so years, written in Python from the beginning. Python was not this popular when Anaconda was new.

Google's Go (golang.org) is evolving very fast. The compiler is yet to be bootstrapped. For its popularity to take off, its library has to stabilise, compiler should be bootstrapped, and, more people have to use it. I have heard one production program outside Google is written in Go and is reported to have had no down time yet in its life of just over a year.