Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been asked many times by my juniors about the areas in which C++ is widely used. I usually answer Operating Systems. Are there any other areas where its extensively used?
A quite large and probably quite definitive list of software written in C++ can be found at Bjarne Stroustrup's homepage.
Numerical computations: physics, graphical games, finance, statistics;
Bit fiddling: drivers, operating systems, networking, embedded devices;
Anywhere you need exact control of allocation of memory.
I wouldn't say Operating Systems actually. The Linux & Windows kernels are mostly C, with only userland stuff being C++ (granted, drivers could be written in anything). I'm not sure about Mach (OS X), but I wouldn't be surprised if it were mostly C as well.
C++ filled this wonderful nitch of "Object Oriented, but fast enough for dinky computers in the late-80s & early-90s". Accordingly, anything written in the 90s had a good chance of being written in C++; applications, drivers, games, whatever.
Today, new development seems to be done mostly in managed (JVM/.NET) languages. Not that there isn't any new C++ development; games, in particular, are still performance limited enough to use C++ in many cases.
In short:
Drivers
Games
LEGACY CODE
C++ is also used heavily in real-time financial market data software. Latency here is very important. C++ is great choice since it's almost the closest to metal.
C++ and C are used heavily in embedded systems since one can have deterministic control of memory and other scarce resources. I think most games (well at least the games I play) are still written in C++, probably because there exists large frameworks written in C++ which have been fully tested and are very capable.
it's used where you find it solve your problems efficiency. Compilers, writing Drivers ...
Currently it is in game development and performance critical applications. However, there is lots of older stuff written in C++ which was mostly written before Java and .NET were introduced, and this code still needs to be maintained.
Consider this: From the introduction of MFC until the introduction of the .NET framework, C++ was the preferred language for Windows development. So that should tell you something. Preferred by Microsoft that is, many developers still prefer it to .Net languages.
C++ is a language capable of systems level programming, but also due to the provision of extensive libraries it is used for applications programming also. I would guess that almost every application running on your Desktop PC was written in C++.
If you can get a library for anything, you can almost certainly get it for C++.
It is widely used in the games industry, and to some extent in the embedded systems domain.
So I would say - 'everywhere'. It is after all a 'general purpose' programming language.
I have seen C++ used quite heavily in GUIs, due to the object orientated nature being sort of natural for "widgets".
I once saw it used in safety-critical code for an aircraft. This still gives me nightmares.
Any application based on Qt will use it as Qt is written in C++.
Also, since KDE is based on Qt pretty much the whole desktop environment including the applications designed to work within it are therefore written in C++.
C++ in Operating Systems: No kernels (the core bit that really does all the nasty work like memory management and drivers ) that I know of are written in C++, just C. Linux is written in C and so is Windows.
See here:
What Languages are Windows, Mac OS X and Linux written in?
Applications ( non-kernel bits that make up an OS ) these days are written in whatever language seems best for the job.
You would choose C++ if the following were important to you:
You want to make heavy use of classes and inheritence
You only plan on working on one OS
You want reasonable performance
Your developers already know C++
You want to divide work on similar components to different people or teams ( you can give each time a class or interface to implement )
You can do all of the above with C, portability between platforms is still an issue ( C++ is equally platform specific as most C ) In C you have to be more strict make good use of static and dynamic analysis tools. It's easier to leak memory in C than in C++ too.
Most antivirus software are written in C++
Several major operating systems have been written in c++
Uncompromising low-level efficiency essential for C++. This allows us to use C++ to write device drivers
Much numerical, scientific, and engineering computation is done in C++.
Graphics and user interfaces are areas in which C++ is heavily used.
C++ is widely used for teaching and research
Games
In legacy code...
Even Stroustrup admits C++ has many mistakes, most inherited from C.
That is why C++0x is being developed.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
From what I know, even though the common OS have parts written in other languages, the kernel is entirely written in C.
I want to know if it's feasible to write a Kernel in C++ and if not, what would be the drawbacks.
There are plenty of examples of well-used operating systems (or parts of them) implemented in C++ - IOKit - the device driver subsystem of MacOSX and IOS is implemented in EC++. Then there's the eCOS RTOS - where the kernel is implemented in C++, even making use of templates.
Operating systems are traditionally awash with examples of OO concepts implemented the hard way in C. In the linux device model kobject is effectively the base-class for driver and device objects, complete with DIY v-tables and some funky arrangements implemented in macros for up and down-casting.
The Windows NT kernel has an even more deeply rooted inheritance hierarchy of kernel objects. And for all of the neigh-sayers complaining about the suitability of exception handling in kernel code, exactly such a mechanism is provided.
Traditionally, the arguments against using C++ in kernel code have been:
Portability: availability of C++ compilers for all intended target platforms. This is not really an issue any more
Cost of C++ language mechanisms such as RTTI and exceptions. Clearly if they were to be used, the standard implementation isn't suitable and a kernel-specific variant needs using. This is generally the driver behind the use of EC++
Robustness of C++ APIs, and particularly the Fragile base-class problem
Undoubtedly, the use of exceptions and RAII paradigm would vastly improve kernel code quality - you only have to look at source code for BSD or linux to see the alternative - enormous amounts of error handling code implemented with gotos.
This is covered explicitly in the OSDev Wiki.
Basically, you either have to implement runtime support for certain things (like RTTI, exceptions), or refrain from using them (leaving only a subset of C++ to be used).
Other than that, C++ is the more complex language, so you need to have a bit more competent developers that won't screw it up. Linus Torvalds hating C++ being purely coincidental, of course.
To address Torvalds' concerns and others mentioned elsewhere here:
In hard-RT systems written in C++, STL/RTTI/exceptions are not used and that same principal can be applied to the much more lenient Linux kernel. Other concerns about "OOP memory model" or "polymorphism overhead" basically show programmers that never really checked what happens at the assembly level or the memory structure. C++ is as efficient, and due to optimized compilers many times more efficient than a C programmer writing lookup tables badly since he doesn't have virtual functions at hand.
In the hands of an average programmer C++ doesn't add any additional assembly code vs a C written piece of code. Having read the asm translation of most C++ constructs and mechanisms, I'd say that the compiler even has more room to optimize vs C and can create even leaner code at times. So as far as performance it's pretty easy to use C++ as efficiently as C, while still utilizing the power of OOP in C++.
So the answer is that it's not related to facts, and basically revolves around prejudice and not really knowing what code CPP creates. I personally enjoy C almost as much as C++ and I don't mind it, but there is no rational against layering an object oriented design above Linux, or in the Kernel itself, it would've done Linux a lot of good.
You can write an OS kernel in more or less any language you like.
There are a few reasons to prefer C, however.
It is a simple language! There's very little magic. You can reason about the machinecode the compiler will generate from your source code without too much difficulty.
It tends to be quite fast.
There's not much of a required runtime; there's minimal effort needed to port that to a new system.
There are lots of decent compilers available that target many many different CPU and system architectures.
By contrast, C++ is potentially a very complex language which involves an awful lot of magic being done to translate your increasingly high-level OOP code into machine code. It is harder to reason about the generated machine code, and when you need to start debugging your panicky kernel or flaky device driver the complexities of your OOP abstractions will start becoming extremely irritating... especially if you have to do it via user-unfriendly debug ports into the target system.
Incidentally, Linus is not the only OS developer to have strong opinions on systems programming languages; Theo de Raadt of OpenBSD has made a few choice quotes on the matter too.
The feasibility of writing a kernel in C++ can be easily established: it has already been done. EKA2 is the kernel of Symbian OS, which has been written in C++.
However, some restrictions to the usage of certain C++ features apply in the Symbian environment.
While there is something "honest" about (ANSI) C, there is also something "honest", in a different way, about C++.
C++'s syntactic support for abstracting objects is very worthwhile, no matter what the application space. The more tools available for misnomer mitigation, the better ... and classes are such a tool.
If some part of an existing C++ compiler does not play well with kernel-level realities, then whittle up a modified version of the compiler that does it the "right" way, and use that.
As far as programmer caliber and code quality, one can write either hideous or sublime code in either C or C++. I don't think it is right to discriminate against people who can actually code OOP well by disallowing it at the kernel level.
That said, and even as a seasoned programmer, I miss the old days of writing in assembler. I like 'em both ... C++ and ASM ... as long as I can use Emacs and source level debuggers (:-).
Revision after many years:
Looking back, I'd say the biggest problem is actually with the tons of high level features in C++, that are either hidden or outside the control of the programmer. The standard doesn't enforce any particular way of implementing things, even if most implementations follow common sanity, there are many good reasons to be 100% explicit and have full control over how things are implemented in a OS kernel.
This allows (as long as you know what you are doing) to reduce memory footprint, optimize data layout based on access patterns rather than OOP paradigms, thus improve cache-friendliness and performance, and avoid potential bugs that might come hidden in the tons of high level features of C++.
Note that even tho far more simple, even C is too unpredictable in some cases, which is one of the reasons there is also a lot of platform specific assembly in the kernel code.
Google's new-coming operating system Fuchsia is based on the kernel called Zircon, which is written mostly in C++, with some parts in assembly language[1] [2]. Plus, the rest of the OS is also written mostly in C++[3]. I think modern C++ gives programmers many reasons to use it as a general programming environment for huge codebases. It has lots of great features, and new features are added regularly. I think this is the main motive behind Google's decision. I think C++ could easily be the future of system programming.
One of the big benefits of C is it's readability. If you have a lot of code, which is more readable:
foo.do_something();
or:
my_class_do_something(&foo);
The C version is explicit about which type foo is every time foo is used. In C++ you have lots and lots of ambiguous "magic" going on behind the scenes. So readability is much worse if you are just looking at some small piece of code.
I have been using C++ for a while now and I began to get interested in lower level system programming like drivers and stuff. Even some kind of primitive operating system could be very interesting project!
I have no clue where I could start. Are there any not-too-challenging things I could get started with and are there anything about C++ I should try to avoid like exceptions in performance critical code?
My current OS is Windows 7 if that matters much.
Writing Windows device drivers in C++ isn't impossible, there are not many CRT functions that you could use to get you into trouble. The new operator is unusable for example, you don't have to fear a std::bad_alloc. Unless you replace it, that cuts out a rather large swath of standard C++ library classes.
But that's not really the point of a device driver, it is rather important that you make it as small as possible. C++ pays off when you write complex code. You explicitly do not want to write complex code in a device driver. Debugging it is redrum.
Linus really likes C in the kernel. There's a good reason for that.
C++ doesn't provide quite all of the tools you will need to actually implement a full operating system in it. There are a few machine specific things that cannot be done in c++. These things are handling and raising interrupts, controlling the MMU, controlling access to supervisor cpu instructions, and a handful of other small odds and ends.
Fortunately, these things are few enough that they can be written in assembly language accessed from C++.
Have a look at osdev.org (lots of questions that will pop into your mind when considering developing your own OS are answered here).
I would strongly suggest you start by hacking existing open source device-drivers and kernels, which you can really only do in Linux or *BSD. The experience will also give you a good sense of whether you're cut out for this kind of programming.
I have heard the recently open sourced Symbian OS is written using C and C++. Not sure which parts of it are done with C++ as I have not read the code base. Consider looking into it.
Kerneltrap.org has some very good discussions about why the Linux kernel does not have C++ in its code base. Consider reading that as well.
Symbian OS is written in a variant of C++. Of course, there's assembly code for low-level things, but that is all wrapped up. You cannot use exceptions, and for real-time drivers you cannot do normal things like dynamic memory allocation, not even in C.
I recommend C Programming Language and assembler. I'm not sure if it's possible to low-level much with C++.
With RoR, Java, C#, PHP etc.. what do people use C++ for these days?
You're comparing apples to oranges. Languages such as PHP, Ruby, and Python are scripting languages. They a) are interpreted, and b) don't provide the kind of low-level memory access that C++ does, and thus aren't suitable for things that need to talk directly to hardware. Java and C# both run in a runtime environment on top of a particular platform and for the same reason aren't always the best choice. In all of these cases, things such as garbage collection can get in the way of speed and performance.
Languages are just tools; you choose the best tool for the task at hand. Just because higher-level languages make many tasks easier for a particular application domain doesn't mean that lower level languages don't have their place.
C++ is the preferred language when the user experience is more important than
development cost.
Performance. When Users time is valuable enough to spend some extra development hours.
Stability. Other languages may quick whip up something of descent quality.
But If you want it flawless, C++ is a better choise. As usual in c++ it is both
easier to get it totally wrong and totally right, depending on your skill and time available.
Ease of use. You can deliver a single binary that works everywhere. No need
for inexperienced end user to fiddle with installling runtimes and
interpreters, worring about VM versions and GC tweaking.
Users resources. Just because the user has 2gb of ram doesn't mean that she
wants our program to use all of it.
Usability. If you want specialized non-standard streamlined user interface.
Something that seems to have been overlooked so far are projects where there is already a substantial C or C++ code base. Most programming work is not going into creating brand new programs. If you are so blessed as to be creating something completely de novo, great, but that's not the common situation.
It's possible to mix languages, of course, so you can have the old C++ core program with additional code written in some other language. But, this is not easy, for a number of reasons:
There's the impedance mismatch between the languages themselves. Try to send a C++ std::multiset to Perl. It's kind of like an associative array, but not really. You end up using lowest-common-denominator data structures, avoiding anything that's specific to only one of the two languages. You then lose out on some of the features you were trying to gain by mixing languages.
You have to spend a lot of effort to define some kind of API between the two parts of the program. Most programs are not already architected to have such a layer. Refactoring and packaging the old core functionality to provide this is not easy, and it's ongoing work as the program's scope expands.
You either have to integrate the interpreter for the other language into the old C++ core, or you have to run it as a separate program and arrange for coordination between these two different programs. They must start up and shut down together, they have to maintain their IPC channels, etc.
Having overcome all the above, you will frequently find yourself needing to write code for both halves of the program. You will always have some delay while your brain makes a kind of mental context shift between the two languages. It never drops to 0 delay. This soaks up some of the superior productivity of the higher-level language. This is especially bad when working on a new feature in the high-level code that requires adding something to the old C++ core, so you're constantly bouncing between the two. It can be done, but it's a drag on productivity, the main claimed advantage from switching to some other language.
Two of the most common usage of C++ I would think are graphical interfaces and video games programming.
Almost everything on the desktop (except paint.net)
Everything on the server that RoR, php etc is running on top of (any language that can't write it's own compiler is probably written in C++)
Anything embedded smaller than an iPhone
Anything with a lot of computation - that isn't in Fortran ;-) Yes I know C# performance has improved, anybody got round to rewriting LAPACK, BLAS or NAG in it yet?
edit -
Is there a badge for most comments?
This is why SO doesn't work for discussions. Notice the order of comments change as they are voted. If you want to have childish arguements there is always reddit.
Anything where performance is a high priority. Garbage collection, HTML rendering, animation, games, intensive computation...
And from personal experience Computer-aided Design (CAD) plugins/addins are also C++, especially if you want to target multiple CAD systems (e.e Pro/Engineer, SoludWorks, CATIA, UG, AutoCAD etc).
Backends to projects. Many projects are written in multiple languages, where all the backend operations are written in C++ where APIs to other languages are provided.
The best project I can think of that does this is GNU Radio. Basically, how GNU Radio works is that all the DSP blocks (modulators, filters, etc) are written in C++. However, you make your radio using python, that is you connect the blocks together in python.
While other languages have come along. Many poeple who have used C++ in the past aren't just going to jump bandwagon with Java or C#. Linux all well and good in it's own right, but the majority of the computer Market still belongs to the Evil Empire. Java is NOT the dominant language there, no matter how much the religeous zelots claim it to be. Actually in small business apps, VB is king. I think I saw one figure giving it 58% of internal development for GUI front ends. C# is picking up momentum, but I suspect it primarily from the younger crowd who are less set in there ways. You can argue till your blue in the face virtues of a new language with someone who's been using a language for 15 years, and they just won't care. "Oh that's neat." and they turn back around and continue typing their C++.
Edit:
OS development, C maybe C++.
Tool & Langauge development, C maybe C++.
Industrial control, C, C++, Labview in somecases, FPGA development and NO trendy languages.
Embedded alot of C, some C++ and some assembly required.
(The IPhone is a general purpose palm computer, with phone capability. Not special
purpose computer designed for a singular purpose.)
PS3 C, C++ and some assembly required.
XBox360 Some C#, mostly C++ and some C and again some assembly required.
GPU Programming? It ain't PHP that's for DAMN sure.
Windows Programming C++, C#, and even some C still, VB.
Edit:
#Jeff L:
The Cult following that many these language have, I find irrational and distasteful. I start edging away from anyone who waxes poetic about ANY language, it's just mental. It's not a matter of opinion that professionally sold applications AREN'T written in Java for Window, it's fact. I'm sorry, but it's true. Maybe in the IT world it's useful, but not for shrink wrapped Windows software. I write embedded software, and the "feature" of not having pointers means that in order to do any practical work there or on OSs and device drivers requires hacks that violate the language it's self. There are cases where you have to "fly without a net" and the interpretive languages are designed SPECIFICALLY not to let you do that.
And not to be too argumentative with, but the heritage code base is a hard issue to get around. While we write new code in C and C++, I can't even get management PAY to upgrade old code written in Fortran or Ada to C or C++ forget Java that requires a whole new coding standard and butt loads procedures and documentation have to update, that cost even more. And unless the only software you write is GPL and freeware, who's paying for it is the primary concern. And in many cases "if it's isn't broke don't fix it" doesn't even apply, "if it's broke and no one bitching, we're not paying to fix" is managements choice.
Any project that needs direct hardware access, like drivers, operating systems
Any project where better performance is a competitive advantage, like games, simulations
Any project that needs a small footprint, like embedded systems
Check out the click modular router. Written completely in C++ (with some C where necessary)
A lot of micro ISVs are (enthusiastically) using C++ for almost anything you can think of.
It isn't maintained regularly, but here is a list of apps written using C++ Builder. I was pleasantly surprised to see WinRAR and Partition Magic.
I just interviewed with a company that has C++ programs using VS5.0 as they keep planning on phasing the C++ apps out, so updating is not needed. After 12 years you would expect that they would just upgrade their compiler.
If you want to use DirectX the you have to use C++ now, as MS dropped support for a Managed DirectX API.
As was mentioned, in the embedded world C++ or C is the primary languages.
If you work in a system that cannot crash, then you will may use C or C++ and just don't use new or malloc, but use arrays, so that you won't have any memory leaks, which can be a likely reason a long running process may run out of memory and crash.
If you are going to do a great deal of kernel level programming then C or C++ makes more sense as there will be some functions to call that will be incredibly difficult to call from C#, for example.
We do these projects in c++:
Simulation
Game
GIS tools
if you need performance, you should use c++...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Will learning C++ help me build native applications with good speed? Will it help me as a programmer, and what are the other benefits?
The reason why I want to learn C++ is because I'm disappointed with the UI performances of applications built on top of JVM and .NET. They feel slow, and start slow too. Of course, a really bad programmer can create a slower and sluggish application using C++ too, but I'm not considering that case.
One of my favorite Windows utility application is Launchy. And in the Readme.pdf file, the author of the program wrote this:
0.6 This is the first C++ release. As I became frustrated with C#’s large
.NET framework requirements and users
lack of desire to install it, I
decided to switch back to the faster
language.
I totally agree with the author of Launchy about the .NET framework requirement or even a JRE requirement for desktop applications. Let alone the specific version of them. And some of the best and my favorite desktop applications don't need .NET or Java to run. They just run after installing. Are they mostly built using C++? Is C++ the only option for good and fast GUI based applications?
And, I'm also very interested in hearing the other benefits of learning C++.
yep, C++ is absolutely great. Check Qt. It has a great Python binding too, so you can easily prototype in Python, and when/if you need extra performance, porting to C++ is a mostly 1:1 translation.
But in fact, writing C++ isn't so hard either when you have a great platform, the worst part is writing all the class declarations :-)
If you want to build Windows applications that will run without frameworks such as .NET or virtual machines/interpreters, then your only really viable choices are going to be Visual Basic or C/C++
I've written some small Windows apps before in C++ code, and there is definitely a benefit in terms of speed and ease of deployment, at the expense of difficulty going up for development. C++ can be very fast, natively compiles, has many modern language features, and wide support. The trade off is that it's likely that you'll need to write more code in certain situations, or seek out libraries like Boost that provide the functionality you're after.
As a programmer, working in C++ and especially in C is good experience for helping you understand something just a tad closer to the machine than say, .NET, Java or a scripting language like VBScript, Python, Perl etc. It won't necessarily make you a better programmer, but if you are open to learning new lessons from it you may find that it helps you gain a new perspective on software. After all, most of the frameworks and systems you depend on are written in pure C, so it will never hurt you to understand the foundations. C++ is a different animal from straight C, but if you develop in C++ for Windows you'll likely find yourself working in a mix of C and C++ to work with Windows APIs, so it will have a trickle-down effect.
I wrote C++ windows apps for 10 years and switched to c# about 2 years ago to work on the latest product. I am embarrassed by how pathetic the C# app is. It takes 20 seconds to start up, you have to wait a second or so for it to switch between screens. I've used some third party GUI control library, and that leaks memory like a sieve! My app runs at 150 meg, and its doing hardly anything.
I am looking to go back to C++.
You can use MFC, it will be far quicker than .Net. Or, if you really want to burn, check out WTL - aLthough, there's not much documentation for that. I suggest you go with either MFC or Qt because you'll find plenty of good information and tutorials for them.
I can see that C# can be quicker to develop with, and maybe in some future version it will be quicker and smaller.
You will hate my answer:
The biggest bottlenecks in GUI development usually are not because of the language. After all most of the time in most applications the UI is idling, waiting for some user input. I can hear your screams already, but I said in most of the apps.
Let's put it this way: I am pretty sure that one can design a good UI on top of the .Net CLR. Learning C++ is a good thing, but will not solve the inherent problems of developing a good UI.
As always. It depends.
As long as you stay away from microsofts large Frameworks, as MFC, .net etc your applications can be blazing fast, but hard to code. Your benefit: You will really learn how windows is working behind its nice(?)surface. Just look into the initialisation code for COM-Objects and you know what I mean. You will never see such things in VB or C#
You have to program each button, each window and each control by yourself, sending silly window messages, however your applications are small, very small. This is an forgotten art:
Write small, fast programs
Good luck!
If you're committed to learning the raw, gritty details of Win32, then C++ will get you there. If you're not, then you'll end up using a bunch of wrappers anyway. For something like a small utility or especially something like a shell extension (where trying to use .NET will cause you problems anyway), C++ will let you write effective code with the absolute minimum in external dependencies. For a larger app, YMMV - a lot of the UI sluggishness out there comes from poor design: naive algorithms, an unwillingness to spin off non-trivial operations onto separate thread(s), reliance on badly-written 3rd-party components instead of custom controls... Mistakes easily made in any language.
Here is my honest answer to this.
First, I think every programmer should learn C/C++ just for the fact that by learning C++ you learn about programming. It is a systems-level language. You have to consider the finer details of memory management and so forth. I am shocked at how many programmers do not understand the foundational aspects of a programming language or computer system. By learning C/C++, you force yourself to understand programming at a more intimate level. On top of that, if you learn how to program in C/C++, you can program in almost anything.
That isn't to say C/C++ is always the right tool for the job. It can be a total pain to debug and take longer to write more meaningful code. However, it is perfect for those situations where you need absolute control of how a program executes.
This goes to say, I don't prefer C/C++ for UI programming. You still have to use a windowing framework specific to the OS you run on (MFC,Win32,Motif,GTK,QT,etc.). These frameworks don't lend themselves to easy learning curves. For at least Windows development, .NET is really the future of UI development (even though surprisingly MFC got a major overhaul for Vista that does stuff .NET doesn't even do yet). If you write your UI in .NET, it is easier to maintain and for others to maintain.
I typically write my UI in .NET and backend in C++.
Yes and no. It's all about optimization...And since C++ allows you to work on a lower level C++ is one of the best languages to write fast applications.
However those low-level mechanics implemented in C++ could be very annoying if you're used to more abstract approaches to OOP.
Testing your software in C++ is usually a long process.
If you are looking for speed anyway, C++ would definitely be one of the best choices.
C++ will indeed potentially get you a leaner, meaner and faster application (if you do it right).
However, the .NET framework is built for comfort from a developer point of view; a vast improvement over Win32 API or MFC, which may seem like hard work in comparison, So consider how you will implement the aspects for which your application depends on .NET (there are other frameworks available that may be easier than MFC or Win32 API), and also consider the costs and license issues of using such frameworks; for example the free VC++ Express Edition for example does not include MFC support.
If you know where you application is sluggish, C++/CLI may be a solution; allowing you to mix managed and native code to accelerate the parts that need it. However if it is the GUI that is intrinsically slow rather than the application processing; this may not be a useful path.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
C++ just sucks too much of my time by making me micro-manage my own memory, making me type far too much (hello std::vector<Thingy>::const_iterator it = lotsOfThingys.begin()), and boring me with long compile times. What's the single best alternative for serious real-time graphics programming? Garbage collection is a must (as is the ability to avoid its use when necessary), and speed must be competitive with C++. A reasonable story for accessing C libs is also a must.
(Full disclosure: I have my own answer to this, but I'm interested to see what others have found to be good alternatives to C++ for real-time graphics work.)
Edit: Thanks everyone for the thoughtful replies. Given that there's really no "right" answer to this question I won't be selecting any particular answer. Besides I'd just pick the language I happen to like as a C++ alternative, which wouldn't really be fair.
What about D Programming Language?
Some links requested in the comment:
Win32 Api
Derelict (Multimedia lib)
I wouldn't discard C++. In fact, I would consider adding Boost to your C++ library, which makes the language much more usable. Your example would become:
BOOST_FOREACH( Thingy& t, lostOfThingys ) {
// do something with 't'
}
Boost has tons of tools that help make C++ a better language.
C# is a nice language that fits your requirements, and it is definitely suited for graphics, thanks to the efforts of Microsoft to provide it with great tools and libraries like Visual Studio and XNA.
Real-time + garbage collection don't match very well I'm afraid.
It's a bit hard to make any real-time response guarantees if a garbage collector can kick in at any time and spend an undefined amount of processing...
I disagree with your premise. When used carefully and properly, C++ is a great language, especially for a domain like real-time graphics, where speed is of the essence.
Memory management becomes easy if you design your system well, and use stl containers and smart pointers.
std::vector::const_iterator it = lotsOfThingys.begin()) will become much shorter if you use
using namespace std;
typedef vector::const_iterator ThingyConstIter;
And you can shorten compile times significantly by breaking up your systems into reasonably self-contained modules, by using precompiled headers, or by using the PIMPL idiom.
Perhaps a hybrid approach. Python and C++ make a good combination (see, for example, PyGame).
Some variation of Lisp that compiles to machine code could be almost as fast as C++ for this kind of programming. The Naughty Dog team created a version of Lisp called Game Oriented Assembly Lisp, which they used to create several AAA titles, including the Jak and Daxter series. The two major impediments to a Lisp approach in the game industry would be the entrenched nature of C/C++ development (both tools and human assets are heavily invested in C/C++), as well as the difficulty of finding talented engineers who are stars in both the game programming domain and the Lisp language.
Many programming teams in the industry are shifting to a hybrid approach wherein the real-time code, especially graphics and physics code, is written in C or C++, but game logic is done in a higher-level scripting language, which is accessible to and editable by programmers and non-programmers alike. Lua and Python are both popular for higher-level scripting.
Let's not forget to mention the new 'auto' use:
auto it = lotsOfThingys.begin(); // Let the compiler figure it out.
auto it2 = lotsOfFoos.begin();
if (it==it2) // It's still strongly typed; a Thingy iter is not a Foo iter.
As a developer/researcher/professor of 3D VR applications for some 20 years I would suggest there is no alternative (except possibly C). The only way to reduce latency and enable real-time interaction is an optimized compiled language (eg C or C++) with access to a fast relaible 3D graphics library such as OpenGL. While I agree it is flustrating to have to code everything, this is also essential for performanc and optimization.
Sometimes, looking outside the beaten path you can find a real gem. You might want to consider PureBasic (Don't let the name mislead you). Here's some details:
PureBasic Features
Machine Code (Assembly) executables (FASM)
In-line Assembly support
No run-times needed (no DLLs needed,etc.) 1 executable file
Tiny executables (as small or smaller/as fast or faster than C++ w/out the runtime)
You can write DLLs
Multi-thread support
Full OS API support
Multi-platform support
Windows 95-2003
Linux
Mac-OS X
Amiga
2D & 3D game development
DirectX
OGRE
Generous Licensing
Inexpensive (79 Euros or about $112)
Life-time license (all future updates & versions included)
One price for all platforms
External Library support
3rd party DLLs
User Libraries
On-line Support
Responsive development team led by it's creator
On-line forum
One place for answers (don’t have to go all over the net)
Huge amount of sample code (try code out while in IE with IEtool)
Fast replies to questions
Bonus learning (alternative to learning C++)
API
Structures
Interfaces
Pointers
Visit the online forum to get a better idea of PureBasic (http://www.purebasic.fr/english/index.php) or the main site: www.purebasic.com
I completely agree with the mention of C# for graphics programming. It has the slight disadvantage of being a managed language and allowing the garbage collector free reign over your application is framerate suicide after a while but with some relatively intelligent pool allocations made early in the program's life any real issues can be avoided.
Several people have already mentioned XNA, which is incredibly friendly and well-documented and I would like to echo that recommendation as well. I'm personally using it for my hobby game projects and it has treated me very well.
XNA isn't the only alternative, though. There is also SlimDX which is under constant development as a means of providing a lean wrapper of DirectX in a similar fashion as Managed DirectX (which was, I believe, discontinued by Microsoft in favor of XNA). Both are worthy of research: http://code.google.com/p/slimdx/
There are no true alternatives for big AAA titles, especially on the consoles. For smaller titles C# should do.
C# is a good answer here - it has a fair garbage collection (although you'd have to profile it quite a bit - to change the way you handle things now that the entire memory handling is out of your hands), it is simple to use, have a lot of examples and is well documented.
In the 3D department it gives full support for shaders and effects and so - that would be my choice.
Still, C# is not as efficient as C++ and is slower due to overhead, so if it is speed and the flexibility to use any trick in the book you like (with pointers and assembly if you like to get your hands dirty) - stick to C++ and the price would be writing way more code as you mentioned, but having full control over everything including memory management.
I would say the D programming language is a good option. You can link to C object files and interface with C++ code through C libraries. D has garbage collection, inline assembly, and game developers have created bindings to SDL and OpenGL libraries, and are also actively working on new game development apis. I love D. Too bad my job doesn't demand it's use. :(
Like James (hopkin), for me, the hybrid approach is the best solution. Python and C++ is a good choice, but other style like C#/C++ works. All depends of your graphical context. For game, XNA is a good platform (limited to win32), in this case C#/C++ is the best solution. For scientific visualization, Python/C++ is accepted (like vtk's bindings in python). For mobile game JAVA/C++ can works...
If you are targeting Windows, C++/CLI (Microsoft's .NET 'managed' dialect of C++) is an interesting possibility, particularly if you want to leverage your C++ experience. You can mix native code (e.g. calls to C-style libraries) with .NET managed code quite seamlessly, and take advantage of .NET GC and libraries.
As far as concerns about GC impacting 'real time' performance, I think those tend to be overblown. The multi-generational .NET GC is very good at never taking much time to do a collection, unless you are in some kind of critical low-memory situation. I write .NET code that interacts with electronic derivatives exchanges, where time delays == lots of $$$, and we have never had a GC-related issue. A few milliseconds is a long, long time for the GC, but not for a human interacting with a piece of software, even a 'real time' game. If you really need true "real time" performance (for medical devices, process control, etc.) then you can't use Windows anyway - it's just not a real-time OS.
Lot of game engines can fit your need, I suppose. For example, using SDL or Cairo, if portability is needed. Lot of scripting languages (coming in general with easy syntax and garbage collection) have binding to these canvas.
Flash might be another alternative.
I will just point out Processing, which is an open source programming language and environment for people who want to program images, animation, and interactions.
Actually, it is a thin wrapper around Java, making it look like a scripting language: it has a (primitive) IDE when you can type a few lines of code and hit Run without even having to save the file. Actually it wraps the code around a class and adds a main() call, compiles it and run it in a window.
Lot of people use it for real-time exhibitions (VJ and similar).
It has the power and limitations of Java, but adds out of the box a number of nice wrappers (libraries) to simplify access to Java2D, OpenGL, SVG, etc.
Somehow, it has become a model of simple graphics language: there are several applications trying to mimic Processing in other languages, like Ruby, Scala or Python. One of the most impressive is a JavaScript implementation, using the canvas component implemented in Firefox, Safari, Opera, etc.
I vote c++0x. Partial support is already available in gcc-4.3+ using the -std=c++0x flag.
Would 'C' be too obvious an answer?
I have very successfully used C++ for the engine, with the application written in Lua on top. JavaScript is also very practical, now the latest generation of JIT based JS engines are around (tracemonkey, V8 etc).
I think C++ will be with us for a while yet; even Tim Sweeney hasn't actually switched to Haskell (pdf) yet, AFAIK :-)
Java and LWJGL (OpenGL wrapper) has worked well for me. If you're looking for more of a scene graph type library like Orge have a look at jMonkeyEngine which we used to create a google earth type application (see www.skapeworld.com). If you're sensible with object creation the garbage collection is a non issue.
If your target is a PC, I think you can try C#, or embed Lua in your C++ app and run scripts for 'high-level' stuff. However if your target is a console, you must manage your own memory!
Objective-C looks like a good match for your requirements (the latest version with optional GC), although it is too dynamic and Smalltalk-like for my taste.
XNA is your best bet I think. Being supported by the .NET framework you can build for a Windows or Xbox 360 platform by simply changing a setting in Game Studio. Best yet, all the tools are free!
If you decide to go with XNA you can easily get started using their quickstart guide
XNA Quickstart guide
It has been a rewarding and fun experiance for me so far, and a nice break from the memory management of C++.
Garbage collection is a must (as is
the ability to avoid its use when
necessary)
You can't disable a garbage collector temporarily. You would need a deterministic garbage collector then. But such a beast does come with a performance hit also. I think BEA JRockit is such a beast and then you should stick to Java.
Just to comment on your example; typedef is your friend...
typedef std::vector<Thingy> Thingys;
Thingys::const_iterator it = lotsOfThingys.begin()
Don't overlook independent languages in your quest. Emergence BASIC from Ionic Wind Software has a built in DirectX 9 engine, supports OOP and can easily interface with C libraries.
http://www.ionicwind.com
James.
The best enviroment for your project is the one you get your task done in the fastest way possible. This - especially for 3D-graphics - includes libraries.
Depending on the task, you may get away with some minor directx hacking. Then you could use .NET and slimdx. Managed languages tend to be faster to programm and easier to debug.
Perhaps you need a really good 3D-engine? Try Ogre3D or Irrlicht. You need commercial grade quality (one might argue that Ogre3D offers that) - go for Cryengine or Unreal. With Ogre3D and Irrlicht you might uses .NET as well, though the ports are not always up to date and plugins are not as easyly included as in the C++ versions. For Cryengine/Unrealengine you won't have a real choice I guess.
You need it more portable? OpenGL for the rescue - though you might need some wrapper (e.g. SDL).
You need a GUI as well? wxWidgets, QT might be a possiblity.
You already have a toolchain? Your libraries need to be able to handle the file formats.
You want to write a library? C / C++ might be a solution, since most of the world can use C / C++ libraries. Perhaps with the use of COM?
There are still a lot of projects/libraries I did not mention (XNA, Boost, ...) and if you want to create some program that does not only display 3D-graphics, you might have other needs as well (Input, Sound, Network, AI, Database, GUI, ...)
To sum it up: A programming language is a tool to reach a goal. It has to be seen in the context of the task at hand. The task has its own needs and these needs may chose the language for you (e.g. you need a certain library to get a feature that takes long to programm and you can only access the library with language X).
If you need the one-does-nearly-all: try C++/CLI (perhaps in combination with C# for easier syntax).
Good question.
As for the 'making me type far too much', C++0x seems to address most of it
as mentioned:
auto it = lotsOfThingys.begin()) // ... deduce type, just like in *ML
VS2010beta implements this already.
As for the memory management - for efficiency - you will have to keep good track of memory allocations, with or without garbage collection (ie, make memory-pools, re-use allocated object sometimes) anyhow, so that eventually whether your environment is garbage collected or not, matters less. You'll have to explicitly call the gc() as well, to keep the memory from fragmenting.
Having consistent ways to manage memory is important anywhere.
RAII - is a killer feature of C++
Another thing - is that memory is just one resource, you still have to keep track of other resources with a GC, so RIAA.
Anyhow, C# - is a nice alternative in many respects, I find it a very nice language, especially the ability to write functional-style code in it (the cute lambda -> syntax, map/select 'LINQ' syntax etc), thus the possibility to write parallel code; while it's still a 'standard curly-brackets', when you (or your colleagues) need it.
Have a look to Delphi/Pascal Object and some exemples :
http://www.delphigamer.com or http://glscene.cjb.net/
You can look at Ada. There is no garbage collector but this language is oftenly used for real-time system needing high reliability. That means less debuging times for your 3D applications.
And, you can also look at Haskell, if you don't know the functional paradigm this language will look weird to you, but it's worth a bit of your time. Tim Sweeney (EPIC Inc) is considering this language as a C++ alternative.