• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Vortez

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

17 posts in this topic

Hi, i've been programming in c++(well, mostly c) and delphi for almost 10 years now. I've started hearing about c++0x about a year ago, and i still don't get it. What's advantage would i gain from using it? I've heard that you can use rvalue as referance(pointer??), stuff like that wich seem pretty counter intuitive. My point is, is that new language extention just something to try to make c++ easyer for beginer to start with? Or will it just add even more complexity over a language that imo is pretty good as it is. The only thing i dont like in c++ is the lack of support for thread and networking, but that's easily overcomed if you create reusable class to manage this kind of stuff like i did.

So, as an hobbyist programmer, does it worth learning? One of my friend asked me what do i think about it, honestly i could't answer him since i have no idea what it is all about really. If anyone can explain to me some of the advantages of those new features, id like to know.

Thx for you're time.

Vortez.
0

Share this post


Link to post
Share on other sites
Here's a good reference for the new features/changes:

[url="http://en.wikipedia.org/wiki/C%2B%2B0x"]http://en.wikipedia.org/wiki/C%2B%2B0x[/url]

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.
2

Share this post


Link to post
Share on other sites
[quote name='Kaze' timestamp='1310782193' post='4835871']
Seems like its about 10 years too late to be useful.
[/quote]

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)
0

Share this post


Link to post
Share on other sites
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


"
0

Share this post


Link to post
Share on other sites
He's fine to have those beliefs, but game development [b]is[/b] "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.
1

Share this post


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

Share this post


Link to post
Share on other sites
[quote name='rdragon1' timestamp='1310796359' post='4835907']
... but game development [b]is[/b] "extreme performance computing", ...[/quote]
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.



[quote name='rdragon1' timestamp='1310796359' post='4835907']
I don't agree with the argument that managed languages solve many problems in game engine runtime development.
[/quote]
Depends on the features in that game engine, doesn't it? See above. [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]

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.
0

Share this post


Link to post
Share on other sites
[quote][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[/size][/color][/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.
0

Share this post


Link to post
Share on other sites
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.
-6

Share this post


Link to post
Share on other sites
[quote name='Ecofina' timestamp='1311101276' post='4837556']
But the consumer market is moving away from C++ in favor of other languages, especially Java.[/quote]
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.

[quote]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.

[quote] 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.
0

Share this post


Link to post
Share on other sites
[quote name='Ecofina' timestamp='1311101276' post='4837556']
Not entirely sure, but I believe that C++ altogether is obsolete.
[/quote]

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.
1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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<int, shared_ptr<...> >.

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.

2

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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?)
0

Share this post


Link to post
Share on other sites
[quote name='speciesUnknown' timestamp='1311737366' post='4840935']
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.[/quote]

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 ;)
0

Share this post


Link to post
Share on other sites
[quote name='speciesUnknown' timestamp='1311737366' post='4840935']
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.
[/quote]

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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0