What's the point of C++0x?
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<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.
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.
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 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?)
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
