Thread: C++ in the modern world

Hi all - I am thinking of studying Computer Science at university in the uk (Masters Conversion) and was wondering if anyone can provide advice.....

the language is in C++ (which I like) and even though the programming skills and knowledge I will pick up are largely transferrable skills into other languages my questions are...

Where does C++ stand in the world of today and where does it look to be going?

Are there many jobs out there with a simply C++ role in mind?

Thanks!

One of the places where C++ still holds its ground is computer games where performance is often a key issue.
When required carefully written C++ can be as fast and sometimes faster than the equivalent C, but not as fast as hand crafted assembler.
However, outside the performance critical sections, most areas of the games industry moving away from C++.

Originally Posted by PetTastic

One of the places where C++ still holds its ground is computer games where performance is often a key issue.
When required carefully written C++ can be as fast and sometimes faster than the equivalent C, but not as fast as hand crafted assembler.
However, outside the performance critical sections, most areas of the games industry moving away from C++.

thanks - one of the reasons I like C++ is the speed and that it can be run more stand alone unlike Java - I also have interests in Linux so it would help to learn a language that is closely related...........

What languages is the games industry moving towards?

I've been out of the game industry for 6 years but script languages like lua for game content and maybe flash for front ends is getting increasingly common.
A large number of games use standard engines like Unreal so the amount of engine coding done these days a much smaller than in the past.
iPhone games use lots of objective-C, I tend to mix lots of C++ in with that for performance as objective-c uses a lot of late binding that kills performance.
Most web games are Java obviously.
C# for Microsoft platforms is used quite heavily as a tad faster than Java and MS support.

"When required carefully written C++ can be as fast and sometimes faster than the equivalent C, but not as fast as hand crafted assembler."


I would argue that most C/C++ programs now a days are faster then their equivalents written by hand in assembly: compiler optimizations are have come a long way. It is very hard to write code faster then a good compiler.

For the OP: C/C++ is the language of choice for fast, numerical computation. Games, high performance scientific applications, anything fast has to be written in C/C++.

edit: what's up with forum formatting?

I know that once a language is around it is very hard to die but does C++ still have a major role to play in the evolution computers for a many great years to come?

Originally Posted by computerex

"When required carefully written C++ can be as fast and sometimes faster than the equivalent C, but not as fast as hand crafted assembler."


I would argue that most C/C++ programs now a days are faster then their equivalents written by hand in assembly: compiler optimizations are have come a long way. It is very hard to write code faster then a good compiler.

For the OP: C/C++ is the language of choice for fast, numerical computation. Games, high performance scientific applications, anything fast has to be written in C/C++.

edit: what's up with forum formatting?

For embedded platforms or games consoles a good assembly language programmer can make the best compilers look very stupid. Even compared to compilers that use profiling data from real target runs as feedback.
I've worked with C++ code using thousands of lines of compiler directives to try and fix performance issues.

C++ has the following performance issues.
Very few compilers understand data and code cache behaviour on the target platform. (cache misses or undesired line flushes can cost thousands of cycles)
Limited options for function calling conventions, registers to be saved restored etc
Very limited fundamental data type descriptions (could pack 3 vars in one register if only it knew bit 7 was always zero)



But even the biggest budget projects can only afford to write tiny snippets of code in assembler it just cost too much to maintain.

Generally speaking, web games are written in Flash; extreme performance optimization is only worth doing in a very few, sometimes unintuitive, parts of the code; and Java's just-in-time compiler makes it run almost as fast as average C/C++ in most cases.

Anyway, from a student's point of view, C++ is a good language to learn not strictly because of its direct applications, but as the OP points out, because what you learn can be transfered to new languages. C++ covers most possibilities (whereas Java misses memory management issues, for example).

Originally Posted by MagiMaster

Generally speaking, web games are written in Flash; extreme performance optimization is only worth doing in a very few, sometimes unintuitive, parts of the code; and Java's just-in-time compiler makes it run almost as fast as average C/C++ in most cases.

Anyway, from a student's point of view, C++ is a good language to learn not strictly because of its direct applications, but as the OP points out, because what you learn can be transfered to new languages. C++ covers most possibilities (whereas Java misses memory management issues, for example).

Yes in general, for big programs, there is very little difference between the performance of Java, C# or C++. Once you start waiting external events and devices or use multiple threads or use exception handling C++ is no faster.

C++ memory handling features are only of use at the lowest level, and are mostly used by junior coders to create memory leaks. :-D

True, but making such mistakes in an important step in learning how to prevent them later. People that learned on Java never had to worry about it, so they make memory leaks later when they move to C++ (or any other non-garbage-collected language).

Admittedly, they probably make fewer leaks than the students originally would, but that's not really the point.

but isn't that something that could be said to be attractive about C/C++ is the level of control you can have over a machine?

I agree with all the memory leaks stuff and personally I wouldn't like to tell a program how and what part of memory to use simply because it can easily create conflicts but the functionality is very good...

also - even though in real time when waiting on external events and devices C++ can be said to be no faster than Java (for example) isn't it always going to be more energy efficient as unlike Java it does not need to run an environment (the Java virtual machine) in order to execute the code...? (I hope I have got my facts right on this!)

The JIT for Java does compile to machine code, but only those parts of the code that need it. It's all a bit complicated, but the end result is that it's almost as fast as C++ in many case. Yeah, any fully-compiled language with a (very) good optimizing compiler will be strictly faster, but in most cases the difference are pretty small.

Of course, all this is only true with the more recent versions of Java. It was true that Java was pretty slow a few versions back, but most of what you hear about that recently is leftover from back then.

You also get JIT compilers for C++, but the problem with nearly all JIT compilers is they work on a bit of the source (intermediate code) at a time, and therefore only do limited large scale optimizations that need a view of the entire source.
This can include simple things like inlining functions that are only called from one place.

A JIT would inline any inlinable function that's called more than once (from one place or more), and if it's only called once, there's no need to inline it in the first place (the overhead would be tiny).

thanks......

.....but to answer the question in black or white (I appreciate what you said about updated versions etc and the many other variables that can determine the answer) do you think C++ is more energy efficient than Java? (i'm looking for energy efficiency here - I know performance is a related issue but I want to know if a C++ program will generally consume less energy that Java)

and - can I use 2 compliers on a program, say the first one dealing with intermediate code and the second for more large scale optimizations?

Originally Posted by MagiMaster

A JIT would inline any inlinable function that's called more than once (from one place or more), and if it's only called once, there's no need to inline it in the first place (the overhead would be tiny).

JIT compilers normally consider each function on merit.
The aim is to remove the function calling overhead, so the compiler is looking for small functions with large numbers of parameters.

When people write nicely structured code they split big functions into lots of smaller functions that are only used once for readability. Most of these only have a few perimeters and are relatively large.
JIT compilers typically have problems with:

Code:

ProcessAllObjects()
    for(x....)
       ProcessObject(x);

The ProcessObject function maybe big and only has one parameter and is always called for inside ProcessAllObjects but could be called many times.

Originally Posted by fatman57

thanks......

.....but to answer the question in black or white (I appreciate what you said about updated versions etc and the many other variables that can determine the answer) do you think C++ is more energy efficient than Java? (i'm looking for energy efficiency here - I know performance is a related issue but I want to know if a C++ program will generally consume less energy that Java)

and - can I use 2 compliers on a program, say the first one dealing with intermediate code and the second for more large scale optimizations?

Efficiency is effected by coding style more than language.
Class granularity is often the biggest. Combining a group of classes into one can give big performance benefits. At the cost of readability and reuse-ability.
(factory + container + visitors+... => Manager class)

Other killers in C++ can be multiple inheritance (code keeps swapping 'this' pointer.)

Virtual base classes.

Virtual (or late binding) functions are much slower than direct function calls.

The "->" operator is much slower than "." with sid->bert->fred + jane->dick->fjj
being a killer.
sid.bert.fred + jane.dick.ff is two memory operations and an add.
The other using -> is two sets of 3 dependant memory operations with an add.

(A dependant memory operation is one you can't start until you have the result of the first)

If you are writing a program for Widows, C++ is a good choice. Many popular Windows programs are written in it: Windows itself, MS Office, Firefox, Chrome, WinRAR, WinAmp; game engines for major computer games: Half-Life series, FarCry, Crysis. The list may be continued...

What about "energy efficiency", I'd recall cell phones from around 2005. They were with MIPD 1.1. That was a sort on Java. So cell phone developers considered bytecode efficient enough to work on a cell phone. (They probably had some other considerations too.) But I have no clue which programming languages were used to implement firmware and Java VM for these phones.

If you are going to develop firmware for some very resource limited system, you'll use either plain C or assembly language anyway, since C++ compiler is too complex to make one for every embedded platform (As far as I know there are plenty of 'em). Moreover features of C++ like exceptions and STL are too resource consuming for weak processors. If you can afford exceptions and STL you can also afford Java.

thanks everyone, some good tips!

I am going to try and remember this stuff when I start writing proper to try and learn some good techniques for performance and low energy consumption.........

are many of the energy efficiency issues mentioned here the same if writing in C?

When micro computer came to be, in the 70's, you had low speed cpu, low & quite limited ram and low speed storage. You had to be quite efficient and concise in your coding to make a great piece of software, so most of it was done in assembly.

In the next generation, the cpu became faster and so did the ram and storage but still in limited quantity, albeit considerably more than what the first gen personal computer had. So a mix of assembly and of a compiled language like C/C++ or Pascal became the norm.

Next, came the era of stricly using compilled language. The hardware performance has now, for the most part, eliminated the need to code directly in assembly. Most modern compiler do an adequate job (read almost nmo performance hit) at compiling code.

Now today, we are going back to the start in a sense. We are back to using a mix of compiled and interpreted language, like we were using an assebly/compiled mix before. Many application today use a compiled backend and an interpreted/jit frontend.

Maybe the next step, with even faster hardware will mean that some day we'll only need to have real-time interpreted language since effeciency won't be that important anymore.

Originally Posted by BlasW

If you are going to develop firmware for some very resource limited system, you'll use either plain C or assembly language anyway, since C++ compiler is too complex to make one for every embedded platform (As far as I know there are plenty of 'em). Moreover features of C++ like exceptions and STL are too resource consuming for weak processors. If you can afford exceptions and STL you can also afford Java.

The STL is very highly optimized, and will generally be faster than your own implementation of the same structures.

I'm reasonably sure you can turn off extra stuff like exceptions in the code generation options too. I'm not sure whether or not most compilers will include such things if you're not using them.

The STL is very highly optimized, and will generally be faster than your own implementation of the same structures.

I disagree with that. My own measurements show that my custom implementation is usually faster. Additional layers (like iterators) slow down access and processing of data.

But generally I use STL because of its ease and safety.

I'm not sure whether or not most compilers will include such things if you're not using them.

As far as I know they don't. But there was a problem with templates. C++ compilers used to (maybe still do) generate implementation of every template function for every type present in program under certain circumstances.

I'm reasonably sure you can turn off extra stuff like exceptions in the code generation options too.

What's the point to use C++ if you can't enjoy all of its features?

Originally Posted by MagiMaster

Originally Posted by BlasW

If you are going to develop firmware for some very resource limited system, you'll use either plain C or assembly language anyway, since C++ compiler is too complex to make one for every embedded platform (As far as I know there are plenty of 'em). Moreover features of C++ like exceptions and STL are too resource consuming for weak processors. If you can afford exceptions and STL you can also afford Java.

The STL is very highly optimized, and will generally be faster than your own implementation of the same structures.

I'm reasonably sure you can turn off extra stuff like exceptions in the code generation options too. I'm not sure whether or not most compilers will include such things if you're not using them.

The STL is optimized for the general case, unless you know something special about your data then there is little to be gained by writing your own implementation.

However, if you know new items will only be added in bulk or only accessed in a specific order and never deleted individually, or something like that then there may be some gain from your own implementation.
*

Also, there are a number of different STL containers specialized for different types of access. You have to make sure you're using the right one for the job at hand to get the most benefit.

And I enjoy C++, but rarely use exceptions, so I could turn the off if given the option. (Of course, it'd have to be a user-specified option since some people do use exceptions, etc.)