41–50 of 127 posts
Don't let them scare you away... C++ is fine if you use what you need and take the time to actually understand the tools you're using.
Why is C++ suddenly "fine" when you have no other options? There could easily be a language with all the close-to-the-metal advantages and none of the baroque, redundant complexity of C++; why must we be content to use the same language as everyone else in the industry, rather that scratching this itch and building a newer, more productive one?
My use of other languages has therefore gradually increased - I currently use Clojure where I can, but I'm pretty flexible (PHP being the only language on my blacklist so far).
For projects on which I'm a lone programmer, I'm free to use whatever language I want in theory; sometimes the customer has a preference, usually not, so the main restrictions are technical and legal:
I'd like to use Clojure a lot more, but for game dev, it's problematic. Performance is the least of my worries, as I can drop to Java or even JNI for the rough bits. It's also a fantastic choice for server-side programming on multiplayer games. However, the JVM isn't allowed on the iPhone, say, and unrealistic or disallowed on consoles. (the Nintendo DS has 4MB of RAM, for example; licensing/porting is an issue) For pure PC/Mac game dev it's probably fine, although if by any chance you want to port later, good luck.
There was a submission on HN a few months back about using Gambit Scheme for iPhone and Mac programming. Googling easily retrieves some useful information on this, but the general idea is that it compiles to C, and you can actually write Scheme functions with inline C/C++/Objective-C code, so you're using a 2-stage compilation process and retain full control while using a very expressive high-level language. I'm going to try this with my next iPhone game, as I'm not all that impressed with Objective-C so far. It looks extremely promising.
There are of course other languages which have compilers that generate C; I believe there are some Common Lisp implementations, although especially for game dev I'm not sure if there's any advantage in using CL over Scheme.
If using a full-blown Lisp feels too high level, there are some Lispy efforts that are essentially very fancy C preprocessors, e.g. BitC[1] or SC[2]. The latter is literally C with an S-Expression syntax; I'd be interested how compactly all of C++'s features could be expressed in such a language. Not that you'd want the arcane contortions of C++ templates when you have real macros.
Moving away from C a bit more, there are of course Forth and other languages in a similar vein.
As I've mentioned, I'll be going down the Gambit Scheme route in future projects, as it has a very nice interface to C/C++ (this is critical when dealing with game development oriented libraries - I'd probably make this the top priority in choosing a language for this purpose), it's very stable and mature, and it's a Lisp. I'll try and write a postmortem of some sort when the time comes.
My main worry is the behaviour of GC in an environment with hard memory limits (no virtual memory or paging), but if the allocator and GC are well written it should be less risky than explicit memory management.
[2] http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.htm...
Earlier quoted context omitted.
A lot of that "baroque, redundant complexity" comes from standards committee's refusal to make things easier on programmers at the cost of any smidgen of performance. And for certain tasks, like the highly competitive video game industry, uncompromising performance is exactly what the doctor ordered. You can always hire smarter programmers if you have to. On the other hand, it's hard to sell a game that runs or looks…
The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files. The complexity is redundant because they included features of C that they should have depreca…
It's confusing because there are two types of type-inference (run-time and compile-time). You do lose performance with run-time type-inference, which is what most interpreted languages use. C++ already has compile-time type-inference in the form of templates. They are...complex. But they're also faster than anything similar. There's a reason that C++'s sort is usually faster than C's qsort for complex types.
C++ doesn't have run-time type-inference and probably won't. The performance loss is too big to build it into the language everywhere, and unless you do that it's pretty pointless. You can tack it on with boost::any or RTTI, for example, but you'll generally find that it's not the correct decision from an engineering standpoint. Scripting languages have run-time type-inference built in everywhere -- but they do it at the cost of performance.
Now, as far as the problems of C++'s dependence on C...well, you're right. It's a feature of C++'s history. If someone could come along and invest the millions of man hours required in making a performance-critical high-level language without the C-baggage (and then market it!), it would be a great thing. But that's a pipe dream. The best we're going to do on that front is Java.
If you're writing your own game project you can use a sane, minimalistic and syntactically pleasing subset of C++ and gain all the pedal-to-the-metal advantages. Don't discard C++ because other people say it is terrible. Other people are usually wrong. Make up your own mind.
For example, the Keyspace code is organized into classes; we use inheritance and polymorphism; we use templates in a few select cases; but we completely avoid exceptions, operator overloading (actually operators) and the STL altogether (we implement our own containers). It doesn't matter what others think about this specific subset - it works for us, we work well in this formalism, make few mistakes and produce good code that runs fast.
Earlier quoted context omitted.
"Newer" isn't necessarily better or more productive. Especially given the monumental task of having to write a game without the benefit of any of the libraries developed over the past few decades. Perhaps the reason there are no other viable options is because C++ is pretty well suited to the task?
Why would you have to lose the libraries? .so files are .so files; it doesn't matter what language they were written in, as long as they expose an API that can be cleanly wrapped by your own language.
i haven't used either, just conjecturing based on what i've heard through the grapevine.
Earlier quoted context omitted.
Use what most developers are using for the gaming platform of interest.
Isn't that C++? (I'm not very learned, here, I'm really asking about this for a friend).
One route out of this local maximum could be CPUs optimized for garbage collection and a high rate of function call. I doubt we will see that any-time soon, though.
Earlier quoted context omitted.
The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files. The complexity is redundant because they included features of C that they should have depreca…
Type-inference is needed in C++ (and is already part of the next standard, you can enable the auto keyword with gnu gcc already). But it's needed for entirely different purposes than what scripting languages use it for: it's a feature for writing better templates. It's confusing because there are two types of type-inference (run-time and compile-time). You do lose performance with run-time type-inference, which is wh…
The pipe dream you are talking about has a tiny hope of coming true here: http://www.bitc-lang.org/
EDIT: replying to thras, below.
According to the very Wikipedia article you cited, there is no such thing as "runtime type inference". What you described as such is a way of implementing dynamic type checking: checking at runtime that the types of the various parts of an expression actually match. You should actually read your sources.
So, "type checking" isn't always performed at compile time.