next »

[drChengele]

I have talked with managers who flat-out exclaimed that they treat "knowledge of C#" in the resume "as an <EOF> statement."

That's just stupid. And sounds somewhat religious-fanatically.

Well, yes. I just wanted to let my negative experiences be known. It's funny that these are the very same people who usually follow the creed that the only thing that matters is a finished product.

Edit: also, feel free to count me in the SFML camp. If you are going C++, you owe it to yourself to see just how elegant the library is.

[JOBA]

Except for performance and portability, there isn't any intrinsic advantages of using C++.

That's a lot like saying that except for not dying horribly of asphyxiation, there isn't any intrinsic advantages of having oxygen in the atmosphere.

What I was trying to say is - C++ when compared to C#, Java, Python, D or any modern language, doesn't offer features that makes writing games easier.

Yes, it's beneficial to know C++, but if you're indie and are writing a game that doesn't require heavy number crunching (majority of indie games), I don't see why you should go with C++. And it doesn't have anything to do with team size either.

I have talked with managers who flat-out exclaimed that they treat "knowledge of C#" in the resume "as an <EOF> statement."

You mean several managers have told you this?
Ohboy.

[drChengele]

What I was trying to say is - C++ when compared to C#, Java, Python, D or any modern language, doesn't offer features that makes writing games easier.

Yes, it's beneficial to know C++, but if you're indie and are writing a game that doesn't require heavy number crunching (majority of indie games), I don't see why you should go with C++. And it doesn't have anything to do with team size either.

No argument from my side here. It's just that you said C++ "won't open any magic doors", and I thought I'd chime in with my two cents. I do, however, still disagree that team size doesn't matter. If you intend to work in small groups or alone, you can do it in C++, C#, or Game Maker, or in whatever you like. I do not discriminate against games according to language. Hell, I myself made prototypes in Visual Basic 6 for years.

You mean several managers have told you this?
Ohboy.

One of them said it; several more managers/senior programmers were thinking it, or worse. AAA industry has what can only be described as C++ tunnel vision. Fortunately I am not moving in those spheres any longer.

[Theotherguy]

Thanks for the discussion guys, but I would like to repeat that I know C++ fairly well already, and I was just looking for a windows-compatible framework for games. I've been working for a software company all summer programming robots and software frameworks in C++, but all of it was using proprietary tools in a strictly Unix environment.

One of the biggest reasons I wanted to start on C++ is that every time I make a game in C#, upon release droves of people complain about having to install the .NET framework, and have huge issues getting all of their dependencies in line. I thought that if I coded in C++ for multiple platforms, it would allow me to distribute my game as a neat little executable without much hassle.

[TheLastBanana]

Just for information, you used SFML 1.x  or did you try SFML 2.0 too? I didn't yet try this not-yet-released version so it's just to know if you already have seen interesting improvements on this side.

So far I've only used 1.6, but there are a few features in 2.0 that seem interesting.

[Average Software]

Yes, it's beneficial to know C++, but if you're indie and are writing a game that doesn't require heavy number crunching (majority of indie games), I don't see why you should go with C++. And it doesn't have anything to do with team size either.

There are very good political reasons for using C++, or any ISO standard language.  Java, C#, and D are controlled by corporate entities, and craziness can ensue.  There's all kinds of weird crap going on with Oracle (who just bought Sun, and therefore Java) regarding Java patents right now.

[Klaim]

One of the biggest reasons I wanted to start on C++ is that every time I make a game in C#, upon release droves of people complain about having to install the .NET framework, and have huge issues getting all of their dependencies in line. I thought that if I coded in C++ for multiple platforms, it would allow me to distribute my game as a neat little executable without much hassle.

That's the main reason I chose C++ for an open-source tool project to make sure it's cross-platform and stand-alone.

[Impossible]

One of them said it; several more managers/senior programmers were thinking it, or worse. AAA industry has what can only be described as C++ tunnel vision. Fortunately I am not moving in those spheres any longer.

In all fairness, a lot of industry people would rather use another language besides C++.  There are round tables at GDC and countless threads and blog posts on the internet about ditching C++.  The problem is there still is no alternative that has none of the problems and all of the advantages of C++.  If you asked most game programmers in the industry what language they'd like to use many of them would say C#, and the rest would say either C, C++ or some random functional language (Haskell, Erlang and Lisp are popular choices.) Some people might say D if they are aware of its existence.

In practice almost all games now use multiple languages. Even if the core of the engine is C++ there is some almost always some scripting language embedded in any C++ codebase.  C# isn't very popular in the industry for game programming (although that's changing with mono AOT compilation), but it is widely used for tools programming.  I don't know of any managers that will throw out your resume if you have C# on it, and there are industry jobs where the majority of your work will be in C#, just usually not gameplay programming jobs.

Personally I'd like to have a highly performant JIT or AOT compiled dynamic language with built in support for data oriented design and concurrency.  Something like CUDA\OpenCL\DirectCompute meets Python or Lua :-p.

[Klaim]

I Totally agree with Impossible.

In fact, I made recent (personal) researches see what languages currently have the best chances to replace C++ in the game industry. I think that if it have to happen, D and Go are the most credible challengers as they both target the same kind of software : system programming. Now D is the most mature of the two but it's not mature enough yet to be used somewhere else than on computers (not on consoles).

Something tells me that C++ might be ditch out of game dev world only if console constructors don't support it anymore and support another language. At the moment, it's not possible at all.

If D or Go or another language get some way to work with C++ code (instead of only be able to work with C code) then we have a real challenger. C++ have too much code available (for free or not) starting with game engines and basic game engine bricks libraries.

[valkrin]

Now what i've been using C# for quite some time, there's plenty of things i miss in C++:
Fast compile times (C++, especially with some heavy boost template usage, compiles very slowly)

Code:

make -k -j N

Where N is the number of cores on your box.

That should compile any form of C++ code you have with light speed.

[BorisTheBrave]

That should compile any form of C++ code you have with light speed.

Nope, because the same thing applies to C#. C++ compilation units simply take longer to compile. At least the .h/.cpp separate means less recompiling than other languages.

Klaim: Neither D nor Go are credible challenges imho. Garbage collection makes them terrible for real systems work, and in general I don't think either has basically any maturity. D has been around longer, but the split versions/std libraries really make it juvenile in terms of other libraries available.

And given that C++ code cannot interact with other C++ code well, (templates and nonstandard calling conventions make libraries a nightmare), and a full compiler is needed to parse C++ I think the odds of a good interface between the two are slim, short of a rockstar programmer. Still, I could imagine someone wrapping popular libraries with C interfaces, like one does for dynamic language bindings.

[increpare]

Klaim: Neither D nor Go are credible challenges imho. Garbage collection makes them terrible for real systems work, and in general I don't think either has basically any maturity. D has been around longer, but the split versions/std libraries really make it juvenile in terms of other libraries available.

GC is optional in D, and to be fair for systemsy games programming stuff I think a lot of companies stay clear of STL...

[JOBA]

Now what i've been using C# for quite some time, there's plenty of things i miss in C++:
Fast compile times (C++, especially with some heavy boost template usage, compiles very slowly)

Code:

make -k -j N

Where N is the number of cores on your box.

That should compile any form of C++ code you have with light speed.

If you make snail go two, four or N times faster, it's just becomes a N times faster snail.

We could also delve into lengthy discussions about speeding up C++ compilation & linking times using ramdisks, SSD drives and RAID configurations; distributed compiling, reducing dependencies and using PIMPL idiom, etc.

It's just that I don't want to or have to deal with it if I'm using C#.
And I can just make gaems.

(And lastly create an installer which takes care of deployment (having .NET framework))

[valkrin]

That should compile any form of C++ code you have with light speed.

Nope, because the same thing applies to C#. C++ compilation units simply take longer to compile. At least the .h/.cpp separate means less recompiling than other languages.

I'm not claiming that C++ will compile faster than C#. I am claiming that using multiple threads to build will vastly reduce build times. C++ will always take longer than compiling dynamic languages, because well dynamic languages aren't compiled down to machine instructions. They are compiled down to bytecodes, in the case of C#, it is compiled down to CIL, which is later at runtime is converted to native code by the CLR. C++ compilation takes longer because it does more work, it compiles straight to native code. What C++ compilation does in 1 step, you do in multiple steps in C#. So you aren't really comparing apples to apples.

Ultimately the compile times for C++ have never been an annoyance to me. I find that a properly written make file that only recompiles what is necessary goes a long way to reducing build times.

[JOBA]

That should compile any form of C++ code you have with light speed.

Nope, because the same thing applies to C#. C++ compilation units simply take longer to compile. At least the .h/.cpp separate means less recompiling than other languages.

I'm not claiming that C++ will compile faster than C#. I am claiming that using multiple threads to build will vastly reduce build times. C++ will always take longer than compiling dynamic languages, because well dynamic languages aren't compiled down to machine instructions. They are compiled down to bytecodes, in the case of C#, it is compiled down to CIL, which is later at runtime is converted to native code by the CLR. C++ compilation takes longer because it does more work, it compiles straight to native code.

That's not correct.
Actually, you wrote it like C# does more work.

Bytecode just like machine code is ... well, just a code.
You replace each bytecode instruction with few machine code instructions and you get your native code.

Compiling straight to native code is not why C++ takes so damn long to compile.
It has to do more with compiling headers, templates and C++ being hard to parse in general.

What C++ compilation does in 1 step, you do in multiple steps in C#. So you aren't really comparing apples to apples.

Perfectly valid comparison. We compare compile times, not inner-workings of the compiler.
And the end result is that C# compiles MUCH faster than C++. Both full builds and incremental builds. (mainly concerned with incremental debug builds)

And iteration time (edit-compile-run) is drastically reduced. This is huge for me.

[valkrin]

Compiling straight to native code is not why C++ takes so damn long to compile.
It has to do more with compiling headers, templates and C++ being hard to parse in general.

Your probably right that the complexity of C++ is the primary contributer to longer compile times.

[Klaim]

Klaim: Neither D nor Go are credible challenges imho. Garbage
collection makes them terrible for real systems work, and in general I
don't think either has basically any maturity. D has been around
longer, but the split versions/std libraries really make it juvenile
in terms of other libraries available.

I consider them "potential" challengers, they are not NOW but they COULD be.
Currently D provide ways to not use garbage collection so that's not a
point and Go is built in a way that i think is not really "garbage
collection". In any way, they have a point in being designed for
"system software", not general GUI or web app. They have the right
"mindset" and that's the only way to be a challenger to C++.
Now maybe they will never achieve it. Some features of D makes me
think that they will, some other makes me think the other way.
We'll see in 7 years if they matured enough.

Anyway, without support from the game industry, all technical concerns
have simply no sense.

[BorisTheBrave]

Klaim: Neither D nor Go are credible challenges imho. Garbage
collection makes them terrible for real systems work, and in general I
don't think either has basically any maturity. D has been around
longer, but the split versions/std libraries really make it juvenile
in terms of other libraries available.

I consider them "potential" challengers, they are not NOW but they COULD be.

Then you have to consider what other languages are going to be like in 5-10 years time too. The world will be a different place then, but these proto-languages will at least have to contend with C++0x, scripting languages with enough plausible speed in them, and Java and .NET stacks so large that starting from a base of C will start looking faintly ridiculous.

It's a pity really, I also really liked the feel of D, and would love to see it go far.

[Klaim]

With C++0x yes, with scripting language or dynamic languages no because they are not system programming languages. They target easy expression and even with fast execution (like python) they dont allow memory manipulation by nature, that don't allow application-specific optimizations (on memory at least).
The fact that it requires at least 10 years for a language to achieve it's maturity (the point where you can consider it for a serious project) makes me think that it would be hard to have anything else fight with C++0x than D and Go in the coming years, and they are not there yet.

That said, I'll be personally happy only when we got modules in C++, in the following standard (C++15?)