What's the point of C++0x?

Here's a good reference for the new features/changes:

http://en.wikipedia.org/wiki/C%2B%2B0x

The "point" is simply that it's a next version of the language. It's not "extensions", it's simply an evolution of what C++ is from this point on. The C++ you know and love is "C++98" or "C++03". This version is expected to be "C++11".


I don't think a central focus is to make it easier for beginners to start with. C++ is a high performance systems programming language meant to be able to get "close to the metal", and there are simply tradeoffs to make where adding essential capabilities will indirectly make the learning curve steeper. That said, there are lots of other features (for example, lambda functions) that make obsolete current tedious conventions and replace them with something much more elegant, which will indirectly make the learning curve easier.

In short, it adds lots of stuff and changes the way lots of existing stuff is done. As a C++ developer for several years, I welcome the changes. It will result in less code that's more readable, and get rid of some of the nasty hacks that we've come to love. It will also enable expressing new things, and new idioms will appear, which will evolve over time and make C++ better.

Seems like its about 10 years too late to be useful.

Seems like its about 10 years too late to be useful.

Why? It's not like everyone has moved on to other languages. There's still a ton of C++ programmers and code lying around. Also, many things that are being standardized we have been doing in C++ for years, except in a nonportable way (for example multithreaded programming)

I was talking with Paul Deitel the author of one of the most popular/selling C++ book and he said to me in a email :


"
With the exception of extreme performance computing, it's my belief that managed-code programming is the way to go. And in many performance oriented scenarios, it's probably better to use the managed languages and throw more computing power at them than to try to squeeze performance by using languages like C/C++, which are much more difficult to program in correctly.
Best,Paul
Paul J. Deitel, CEODeitel & Associates, Inc


"

He's fine to have those beliefs, but game development is "extreme performance computing", and it's not acceptable to sit back and "throw more hardware at it".

For consoles, there is no "more hardware" - you have what you're given, forever. Also, most consoles don't support JIT compilation.

For PC's, it means your competitors will automatically have all of the compute power you gave up to be able to use a managed language and at least be able to run on lower spec machines or at higher frame rates, or both. With garbage collected languages, it requires significant amount of effort to make sure the garbage collectors don't kick in at "the wrong time" and freeze your game for unacceptable periods of time.

I don't agree with the argument that managed languages solve many problems in game engine runtime development.

As a lounge thread...
I am not excited about 0x. Ok, some features are cool but I don't plan to use them short-term. I'm considering some mid-term but they recently all took a serious blow. Most are just "meh" in my opinion. Among the most interesting:

[font="Courier New"]foreach[/font]: it's only a few years late (has been around as extension for a while but this is better).
lambda functions: the only feature I'm seriously considering. I wished they used a different syntax but it's personal opinion.
Object ctor improvement: at last. Perhaps they were waiting for us to send them cake.
[font="Courier New"]override[/font]: this reduces the potential for misuse and slip errors. Good, although I would have done it differently.
utf-8-16-32: it's only ... like 10 years late? Good to have this at last.
[font="Courier New"]int64[/font]: it's only 10 years late. Could have introduced 128-bit vector types while they were at it!
Better rand: ok, good. A bit late IMHO.

Only lambda functions are so good everyone should not go along without looking into them. Oldschool C++ is still good.

... but game development is "extreme performance computing", ...

That's not quite correct. Some areas of game developement are extreme performance computing. Game development as a whole has many levels of performance requirements. Casual games don't usually require extreme performance. Most indies games don't require it. Even many genres of AAA games don't require it.

I don't agree with the argument that managed languages solve many problems in game engine runtime development.

Depends on the features in that game engine, doesn't it? See above.

In the end, it's going to be as it's always been - cutting edge graphical games are going to need to use C++ in most cases. The only thing holding developers to C++ for everything is existing code bases and platforms they want to target.

[font="Courier New"]static_assert [/font]is beyond price. And it's a language construct, not a macro/template hack.

[font="Courier New"]constexpr, decltype, [font="Arial"]variadic templates, l[/font][/font]ate return type are, in addition to lambda, some of the more useful features, and each in their own way, priceless.

Reassigning the [font="Courier New"]auto [/font]keyword to something useful is a great convenience, especially in situations with complicated template hierarchies that you don't truly care about as long as the compiler can verify that the types are correct. Initializer list support is not something you absolutely need, but a great convenience, especially because they can be made to work everywhere, and the standard library implements them.

[font="Courier New"]sizeof [/font]and constructors finally work the way they should, [font="Courier New"]explicit [/font]finally works as it should, unions finally are allowed to work the correct way (as most compilers did anyway), [font="Courier New"]long long[/font] finally isn't a "non portable extension" any more. More expressive makeup is possible for default constructors, which admittedly is no big deal, but is nice anyway.
The standard library has seen a major overhaul with a lot of useful new (and improved) classes, such as smart pointers or tuples (and much in my opinion less useful stuff such as complicated math functions and random generators etc. -- still it makes the standard library more complete).

All in all, I wonder why the vast majority of programmers is so terribly negative about C++0x. Yes it is late. Yes, talking of 0x in mid-2011 is stupid. Yes, it would have been nice to have the same things 5 years ago. Yes, there is always something extra that we could use. Yes, my neighbour says C# is so much better.

So what.

We have a major update for the C++ language at your hands, and it really works great. It's a tool, and the tool has been improved and extended in many ways.
If someone does not like the tool or thinks that another one is better, fine. If someone does not want to use the new C++0x features, fine. No problem there, really.

[color=#1C2837][size=2]For PC's, it means your competitors will automatically have all of the compute power you gave up to be able to use a managed language[/quote]

But you're ignoring the competitive power that using a managed language gives you: faster development time. Your competitors don't "automatically" have anything -- there's a time cost involved.

Not entirely sure, but I believe that C++ altogether is obsolete. Sure, there are some successful games written in them, but usually that is because they became successful after they were written, and have lasted for, oh, five years or so. But the consumer market is moving away from C++ in favor of other languages, especially Java. Just look at Runescape and Minecraft. Classic examples of successful Java games, and they give Java a good name. Every newbie game maker wants to make a Minecraft clone by "learning Java" now, and while most of them will fail, some will succeed and give Java an even better name. C++03 is irrelevant today, as C++0x will be. Dead language.

But the consumer market is moving away from C++ in favor of other languages, especially Java.

It is?

The explosive growth consumer market experienced in past several years was in mobile devices, but "consumers" were only found in Apple's ecosystem (as per revenues). All other mobile systems have mostly "users".

The other consumer market is web. Enterprises and B2B companies there use Java, but everyone else uses LAMP, Python or RoR stacks. There is precious little Java in consumer markets and all of it is limited to server-side. The only thing users see is either Flash or JavaScript.

One upcoming ecosystem is Android. That one uses Java-like syntax, but as Oracle likes to point out, that is not Java.

Just look at Runescape and Minecraft. Classic examples of successful Java games, and they give Java a good name[/quote]
They are also two. 2. One, two.

C++03 is irrelevant today, as C++0x will be. Dead language.[/quote]
Those languages have "only" two successes over past 15 years as well: PS3 and XBox. They also have one more: PC.

Not entirely sure, but I believe that C++ altogether is obsolete.

Ive been noticing a lot of your posts lately. You need to stop giving people advice that is untrue and has no back up proof. First you said dont use C because it "sucks", and now youre saing C++ is "obsolete". The fact that Minecraft was made in Java says nothing about the mainstream games industry. Game engines were and continue to be written in C++ for various reasons. The consumer game market is not by any means moving towards Java, what would even give you that idea? If anything, Java is one of the LEAST used languages in commercial level game development. If youre going to try giving advice, at least know a bit about what youre saying. It will benefit you and also the person who is listening to you.

And youre saying all "newbies" want to make a minecraft clone in java and will "fail". Are you not the person who claimed that making a WoW clone over the course of one summer with a few friends was reasonable? I am having trouble deciding whether you are intentionally trolling the crap out of this place, or just genuinely don't understand certain things.

Bear in mind as well that features such as r-value references are of tremendous use to library writers. Most of the advantages to adding these features to the language will benefit everyone who uses the standard library, without any additional effort or learning on their part. Likewise with varadic templates.

The point of c++0X is to add language features to overcome the problems with the other language features.
A few technical issues drove me away from c++ for small games, and I'm sad to note that c++0x doesn't solve any of those issues. I've determined that for small games, almost any other language with reasonable API's is a superior choice, and that for larger games, a C api DLL, with heavy use of c++ in the background to save time, and with a less performant scripting language for gameplay programming, is the best solution.

My list of problems with c++ are as follows:

Very limited ability to build a DLL for use with other languages. In practical terms, we are pretty much limited to the C api if we want language interop. This became a problem when I wanted to put a class library into a DLL; i found that it was almost impossible to have Engine.dll (c++) and Game.exe(lua) without Engine.dll using the C interface. I went through luabind and found that it was an incredibly intrusive and tedious task to bind up functions and methods and constructors and instances, and I got pretty confused when I tried to use it with shared_ptr. I looked at other scripting languages and their problems were similar in nature; they only really worked well with a pure C interface. The work required to shoehorn a c++ api into a C api and then bind this C api into an OO scripting language makes c++ counterproductive to use.

Memory management. shared_ptr is the only viable way to do this but I find that if one is using shared_ptr suddenly everything becomes a lot more complex, especially if one is using a library which performs template metahackery but does not explicitly support shared_ptr, as I found with luabind. I wanted to tag an object in the Havok physics engine with the shared_ptr to a game entitiy, but this is impossible; instead I had to do a hack using a static std::map >.

smart pointers don't live up to their expectations in that they do not really function properly as a determinstic garbage collection system. The biggest problem I found is the inability to pass anything a pointer to self (e.g. foo(this) from within a constructor. enable_shared_from_this does not function from within a constructor as all the binding is done after the constructor has been called. I also had a go at using intrusive_ptr but that was also a bust because of the boilerplate involved; I couldn't create a thread safe base class of IntrusiveRefCountedObject or anything similar without some serious work.

The compile model. 0x still relies on macros to help it compile. Circular references are an irritation. Having to modify the code in a file to make it compile faster (forward declaration, p_impl shenanigans, precompiled headers) is counterproductive.

Language level support for delegates. When I tried to use boost.function and boost.bind I ran into several brick walls, mainly due to a lack of compatibility with shared_ptr; boost.bind keeps shared_ptr alive basically forever. I don't think it would be that hard to implement delegates as a language level feature, but this is where the lack of an ABI kicks in. You cannot combine any of the various versions of function bind and shared_ptr / weak_ptr together; you have to use them from all the same version.

I don't think any of these problems will be ever solved to my satisfaction, at least not in my lifetime; most c++ programmers seem not to find any of these things to be a problem, but in fact, they welcome them as the side effects of what they see as good design decisions. Usually I am told that the way to solve these problems is to use more and more template metahackery or other language features, not use scripting languages and to use c++ as a scripting language instead, and I find that all this additional work one must do erodes the benefits of compatibility and performance.

C++ may have lots of active developers, but many of those are of an age that such a big change is not something they will be able to adapt to - because C++ has been around a long time we have lots and lots of legacy apps and legacy developers.
The section of C++ written for new apps by young, learning developers is relatively small, so on that basis the "it's too late" is a reasonable argument even if not a conclusive one. I personally don't see this becoming the "default C++" because we've had so long to settle on a stable variant, regardless how cool it is.

The DLL issue certainly is a pain in the ass, but that's basically a flaw in the way DLLs were designed so many years ago. Both GCC and MSVC use the COM-conventions for the order in which class methods are listed, so you can use these. That's just how C#-assemblies are doing this; the fact that this happens under water does not immediately convince me it's a better language.

As for memory management, I think managed is different, not necessarily better. There's one thing less to worry about, but it also never triggers the programmer to think about things like frame-to-frame coherence or memory fragmentation. Also, I use Lua fairly much and had quite some bugs that were terribly different to reproduce, just because the releasing of objects is not determinstic anymore.

In short, I thinks there's merit in both languages and there's room in this world for both managed and unmanaged to co-exist.
(P.S. Isn't it weird that in a day and age when light bulbs are banned for CO2 emmission, we increasingly just 'throw extra CPU' against a problem?)

When I tried to use boost.function and boost.bind I ran into several brick walls, mainly due to a lack of compatibility with shared_ptr; boost.bind keeps shared_ptr alive basically forever.

I'm not sure what you are really complaining about here... if you are using boost::bind to bind a shared_ptr into an object then the expected behaviour WOULD be for it to keep the object alive "forever" (or at least for the duration of the object returned by boost::bind) as you are making a copy of the shared pointer and increasing it's lifetime/scope.

Where smart pointers ever billed as a "determinstic garbage collection system"? I don't ever recall being sold them on that promise, just that they allowed me to stop worrying about life time of objects when sharing them around. (Side note, not direct at you; I've found people often reach for 'shared_ptr' without really thinking about the life time management they really want for the pointer. So you end up with shared_ptr everywhere and while you won't leak memory your object life times end up screwed over.). They were only ever 'smart' in that they would do basic reference tracking and clean up for you, beyond that they never really promised anything.

Don't get me wrong, I'm not saying C++ is prefect and there are plenty of things wrong with it when compared to something like C#, however at the same time I can't help but feel some of the complaints are less about the language and more about misunderstandings for the constructs used.

As for Lua and C++... well, Lua is written in C, it's not overly surprising that you need to do a fair chunk of work to get it to talk to C++; not even a standard ABI would help you here ;)

The point of c++0X is to add language features to overcome the problems with the other language features.
A few technical issues drove me away from c++ for small games, and I'm sad to note that c++0x doesn't solve any of those issues. I've determined that for small games, almost any other language with reasonable API's is a superior choice, and that for larger games, a C api DLL, with heavy use of c++ in the background to save time, and with a less performant scripting language for gameplay programming, is the best solution.

I'd tend to agree with this bit. I think after I move I might look into mucking about with performance implications of it, but I'll save that for then.

Does anybody happen to know the performance implications of say using p/invoke in C# or similar in other languages is? I think having parts of your program that can run constantly unmanaged while other parts of your program could interact with that layer in a managed fashion could have huge potential. That kind of reminds me of the "C++ is a bad language for game programming, what should we use instead?" roundtable at GDC a few years back. That would be a cool feature worth suggesting; being able to set certain functions or classes as managed vs. un-managed. Probably would have huge impacts towards how deterministic your unmanaged code could be in this kind of environment, but I still think it would be a lot of fun to mess around with. It's fun thinking of the possibilities/pitfalls at least

edit: now I'm thinking of tying this in with mucking around with DOD. Simulation/Rendering bits in C++, data storage probably in C++, and C# to perform more gameplay specific actions that could interact with the data without ever touching the simulation stuff.

I feel like the tricky part would be prioritizing data locks to the simulation bits so it doesn't slow down the performance intensive stuff.

double edit: HRM. in retrospect this is probably what we already do with any scripting language over our existing engines.