Minecraft Forums

Quote from nickguletskii

for game programming I recommend you don't use any Microsoft-addressed products such as DirectX because I'm a freetard

FTFY. *trollface*

"easily replaced"? No. Not when the project already uses it. Starting a project from scratch of course it's just as easily to choose, say, SDL (as long as you don't want to ever support joysticks) or IrrLicht. Makes it easier to port to other platforms.

Although, since the only real viable "other platforms" would be mobile devices (android, iOS) which would need to be redesigned for performance (slower processors, less RAM) and input (touch-screen versus keyboard/mouse/joystick), which would typically amount to pretty much a rewrite anyway, the gains one would receive are questionable; Particularly since many free libraries wouldn't be saleable on such marketplaces due to their licenses.

GNU C++ (what you are most likely referring to) has better standard support.

This is mostly because. MSVC tends to give the programmer the benefit of the doubt a lot more. This isn't necessarily bad or good (and I believe you can pass in switches that change that behaviour),A really good example of this is with templates, where with g++ you have to preface the template variable with a typename, such as template <typename T>, whereas with cl you can just have template <T>. To my recollection since you can't actually have anything else there aside from typename (I believe class works, but only due to backwards compatibility with early draft compilers; template <class T> is equivalent to template <typename T> and since typename (again, as far as I'm aware) is really the only option I see no reason to enforce it. (No reason to require what can be inferred). Though come to think of it, this was a rather old version of cl (possible VS 98).

Doing some more googling and testing with VS 2010's compiler, seems that Microsoft's C++ compiler is C++03 compliant as much, if not more than, g++. one advantage is that you don't get internal compiler errors on trivial segments of code like you do with g++.

with g++ the one advantage you get is portability- a la' you can use the same compiler to compile to several platforms. But as noted that can be of questionable utility unless you desire, from the get-go, to compile to several platforms; also, if you restrict yourself to the C++'03 specification, your code will compile equally well to both compilers anyway so it doesn't really matter, as long as you don't bake-in reliance on a given framework (for example, you obviously aren't going to be compiling an MFC or C++/CLI application in g++, and it would be foolish to expect it). Even if you rely on a Open GUI framework such as OpenTK, GTK++, or Qt, you're still coupling your application with the framework. Basically, when it comes down to it, you are going to have to either do some coupling or you are going to have to write your own framework- such as abstract class implementations- to delegate various tasks to other frameworks. Just choose whatever framework meets your goals. if your goal is to be cross-platform, find a framework that provides that. If you want ease of programming as well, balance that consideration. As for the compilers themselves, though, it doesn't make a huge difference; As an IDE, however, Visual C++ blows pretty much any other IDE out of the water for any sort of serious development.

Most of the compliance issues in either g++ or cl- and they both have them- are pretty much pointless, like the acid3 test; the compiler does the right thing in the normal case (for example, template <typename T> of course works with MSVC), but doesn't do the "right thing" (presumably, refuses to compile) if you do the wrong thing. The consequences of doing it the "wrong way" are fairly trivial, and easy to avoid. People who rely on their compilers to determine their code "standardness" are going about it the wrong way anyway. Also, With the cl compiler, you can simply use the /Za switch to disable extensions so you don't "accidentally" use them; and the /Zc:forScope,wchar_t option to enforce C++ standard scoping rules (no leniance, that is- you must specify the redundant 'typename', it's the 'law!') and have wchar_t as a native type rather than a compile-time typedef (again, as per standard). I'm not as familiar with gcc/g++ but a preliminary look at some of the man pages for gcc and g++ confirms that it does indeed provide switches to enable various non-standard extensions.

Just thought I should also add that I can't stand C++ and think it is one of the most disgusting, hodge-podge, and badly coordinated 'updates' to an existing language to support a new programming paradigm ever created. It lacks any form of intellectual coherence as far as it's design is concerned. C++ is an appropriate language for system-level programming, much like C, If you want to do system-level programming but want OOP abstractions for some reason. However, I don't feel that C++ is an appropriate tool for general purpose applications or games; it just doesn't make sense.
In general purpose development, the number one rule is that you don't optimize prematurely, but the entire philosophy of C++ is based on microscopic optimization at every opportunity before you have any evidence that it is even worthwhile. (micromanagement of memory using malloc()/free() for example). What makes the entire affair ironic is that it frequently ends up being slower than Java or C# as a result of those basic assumptions, making it nothing more than a waste of developer time. On top of that, we have the aforementioned issues regarding standards. I don't think there is a compiler in existence that implements every last iota of a C++ specification to the letter. If nobody can implement a language successfully, even after several decades, that's a sign of a bad design.

For your average rich/fat client LOB application, Windows is the way to go. In that case, the ideal platform is CLR, simply by virtue of having a vast ecosystem of libraries and languages to use, major choices being C# and VB.NET. Both are fine, I side with C# because if I was to use VB.NET I'd get confused as **** when I tried to maintain my legacy VB6 applications. Of course you can also use Java, but it suffered over the years from horrible GUI and a language development process that was lethargic at best and idiotic at worst "We don't want to add closures because it's a fad" (Um, hello, JAVA was a ****ing 'fad' when it was introduced...). Even so, it's better than developing fat-client LOB apps and most games than C++.

On the server, if you are writing C++ CGI gateway applications- just kill yourself. I'm not even going go into all the ways that is ****ing wrong.

Basically, if you are writing a embedded OS for a device, or creating your own Operating System, C++ might be ideal, (but C itself is often the better choice, depending on your specific use case). But let's face it. Very few people actually do that.

TL;DR of the above: Nobody writes LOB Applications using C++. And those that do don't for very long because the workload is simply unmaintainable for no benefit. And the fact is that the large majority of software written today is LOB applications, either on the client or server-side.

</random rant that came out of nowhere>

Perhaps not such a good example. "template <int T>" also works, as does "template <int>", and "typedef char T; template <T>". Another variety is "template < template<typename> foo > class bar : foo<loltype>". Early versions of Microsoft's compiler could unambiguously interpret "template <x>" because they didn't support all forms. The more recent ones do, and won't compile.

Yeah, I probably should have mentioned that was a test done with VS6.

Oh wait, I did mention that. Funny that... (however thanks for the clarification regarding newer versions).

Quote from tjmonk15

I have to say, that I disagree with you about CLR/Java being as fast as C++/native. I can not really think of any instance where a well written C# App would out perform a C++ App.

I wasn't just talking about how fast the code runs. I was also talking about how fast it comes into being.

I'd rather have a program that performs adequately in 3 weeks than one that runs a few percentage points faster in three months, and from what I've heard from my clients, they really don't give a flying **** what language I use, so I'm going to use the one that requires the least work. Anything else would be just plain foolish.

Especially in the context of writing games, native outperforms IL languages hands down.

IL compiles to native code on the fly. (Though that depends on the platform). And let's not forget about ngen, which can turn a IL executable into a native-code executable for those people who think anybody cares about the trivial differences in execution time that result, which can easily be improved with better algorithms.

Seriously, if you want your program to run faster, look at your code and the algorithms you use, not your choice of language platform.

This is one of the reasons, most of the popular/good open source/free game engines are written in it.

No, the reason is that the industry and the companies involved in the industry have so much sunk cost in developing in-house libraries and tools designed for the language; open source games mostly use C/C++ simply because they all fork the Quake III source in some fashion and Quake III was written in C. (since Doom III's source has recently been GPL'd we can expect some wonderful Open Source clones of that too, goody)

Now, don't get me wrong. Poorly written native code can very easily be out performed by well written IL code. And even more, it is much easier to write BAD code in native c++. But, if you write the code correctly, you will see a rather significant performance gain uses native languages.

Which brings us back to the time investment. Are those significant performance gains worth the effort? For me, it depends on what the client wants. And since the database is always the bottleneck it never makes a difference what language I use anyway. I enjoy programming, but I don't enjoy doing more programming than required. For example, LINQ may not be optimized for execution speed, but it sure as **** speeds up my development time. Not using it because of "speed concerns" would be, as I noted, a premature optimization. Don't optimize until it becomes clear that it's needed, or if it's common sense. The display on my current program, for example, needs to refresh the list from the database every few seconds. A stupid way to do that would be to clear the list and repopulate it. Instead, I enumerate the records and change items that already exist in the list, add new ones, and remove those that were deleted. Functional, algorithmic changes that had a definite impact on the applications usability, I cannot say the same for the differences there would be had I chosen C++, or C++/CLI for this project. Though I can guarantee I would have a hell of a lot less spare time.

And when it comes to RAD, java and C# win hands down.

Err, yes. this was sort of my point. Like I said, I'd rather be able to get a client a program that they can mess around with and comment on in three weeks rather than force them to wait 3 months.

But the trade-off is performance.

I disagree. I've yet to see a definitive benchmarks that actually makes the use of C++ worthwhile over C#. That said, I can see it being used for some things, again- systems level programming, stuff that needs to deal with, say, a device; best way to deal with those is often to write a dll and/or .so library and use Platform/Invoke to run that.

My main point is that, for the most part, the choice of language used for any project is purely irrelevant. Back when processors were hella-slow, and you only had one of them, sure- one could see measurable performance gains by using C/C++ as opposed to FORTH (forth was an interesting tech nonetheless, but somewhat ahead of it's time). On the other hand, one can argue that you can see measurable performance gains by using hand-tuned assembly, and plenty of people used to do that! The same argument between C/C++ and VM-driven languages was waged between ASM wizards and C/C++ programmers. C/C++ won, not because it's faster, but because it alleviates a ****ton of workload over even the fastest Assembly programmer, even if the results can be measurably slower. I feel the same is true for C# (and similarly themed languages) which lift burdens and allow you to focus on what you need to do. In much the same way C++ makes it so you don't have to construct your own dispatch vtables in C structures, or C makes it so you don't have to hand-code your loops using JMP instructions or write prolog/epilog code for function calls (quick what's the difference between a FAR PASCAL function call's epilog/prolog and a near CDECL call?), C# takes some of the "programming taxes" that C++ charges and pays them for us. Whether there is a price, and whether it is worth it, people can argue that until the cows come home. But for me, I'd rather not pay taxes. Very few people complain when governments lower tax rates, and yet when language developers do the same, the results seem quite different.

I think maybe some programmers enjoy those taxes. Good. They can pay them with their spare time, not mine.

This is actually why many games use C++ for the lower level stuff- because they can port it to multiple platforms, use different compiler flags, etc. on the same codebase, then use a VM-driven- or in some cases, a scripting language - for things like NPC AI, actions, event flags, and pretty much all the game logic. Usually only the engine itself is written in C++/C, and if an independent developer is writing a game engine, they are doing it wrong anyway. You don't write a game engine, you write a a game, and let the "engine" grow around that. Unless you plan to be able to make an engine to compete with all the other available engines, just write a game. Not an 'engine'.

Quote from AgentCat

Visual C++ is C++ but more Updated for example:

Hello World:Visual C++
Console::WriteLine("Hello World");

For goodness sake... understand a subject before you post. That's C++/CLI, using the CLI extensions (which I believe were submitted to the ECMA, and may have even been approved, I can't recall) that Visual C++ provides (IF requested) to provide a way for C++ code to interface with managed code.

I would prefer doing Regular C++ because thats the Original Programming Language.

.
Good news! You have to take an extra step to enable CLI anyway. Also, even with it enabled, the latter example would work.

Quote from Dandistine

I don't mean to nitpick one statement, but malloc() and free() are both C functions.

And C++ is a superset of C, therefore everything C has, C++ has.

C++ "replaces" these with the operators new, new[], and delete.

Which use malloc() and free() under the covers. My point wasn't specifically about the functions being used- On windows people can just as easily use LocalAlloc() and LocalFree(), or the IMalloc interface if working with COM... my point was that Manual Memory management is not something that a person writing a Line Of Business application, database front end, or in most cases, a game, should have to deal with; add to that the fact that most people just write abstractions around them anyway or follow a cargo cult style of some sort and it sort of defeats the purpose of "manual" memory management, whose advantages are questionable at best outside a memory constrained system. (embedded, for example)

C++ is not quite as bad as you make it out to be provided the programmer is sticking to C++ and not mixing C functions with their C++ counterparts.

Again, C++ is a superset of C. In what way is it bad to mix C functions with their C++ counterparts? Where is this outlined in the specifications? Is it only passed on by word of mouth, as a sort of urban myth?

Here's the thing. People keep talking about how C++ is "faster". OK, maybe it is.

But you know what else? A Lamborghini is fast too. But you aren't going to get to work any faster with one- You just pay more insurance, maintenance, and upgrades.

Quote from nickguletskii

1) Indie developers seem to like to deploy to many platforms.

No more than other developers, from what I've seen.

I don't see why I would want to use DirectX over OpenGL.

Well, it's based on interfaces/concrete classes rather than a state machine. Some might prefer it that way. Than again, it uses COM, which generally blows any advantage like that out of the water.

Ideally, one could simply use one of the many frameworks that can delegate to either tech; then you can let the users choose. I've found both D3D and OpenGL's usability in applications. to depend quite a lot on how well the driver functionality for each is implemented. One major advantage for D3D is that it "comes with" the rest of DirectX, so you get Direct3D as well as DirectGraphics, DirectMusic, DirectSound, etc. Of course that sort of functionality is outside the scope of OpenGL (and well it should be, really) and OpenGL itself has been used as part of similar packages of game-related functionality that "work" cross-platform... most of the time. (such as SDL) Working cross-platform the majority, or even just some of the time, is still a lot more than DirectX technologies work cross-platform, which is pretty much not at all.

So we just come back to the evaluation of purpose- if you want a cross-platform library, choose a cross-platform library. If cross-platform compatibility doesn't matter, than you can survey your choices based on other requirements. The important thing is to know what you want and what you need; if you don't know that, than you can't know what a good choice would be.

Quote from Zalvager

If you're making something serious, then I suggest that you make an engine. Especially if it's 3D!

<NEVER> write your own game engine.