Programming Language

Started by
63 comments, last by OldMan__ 19 years, 7 months ago
Quote:Original post by tibi
Thinks I like about C/C++:

- great IDE VC 6/7 (win), KDevelop (lin)
- easy debuging
- very good help (MSDN)
- easy integration (libs[fmod, gui, maya, ...])
- multiplaform (Win/Lin/Mac/Unix)
- full control of memory
- fast and can use CPU specific futures
- that code you make now can be good for a cople of years
- standart api

I don't know about Python, but it's ironic that most of these things are done better by Java and C#:

- Great IDE:
After using Eclipse, Visual Studio seems primitive. Eclipse offers:
- Refactoring: for example, rename a variable, method or class, and all references to it with a 3 keystrokes. Or, select a bunch of statements and automatically Extract Method from them (replaces sequences of similar statements with the method call).
- Incremental compile: finds and highlights syntax and semantic errors as you type; you'll never have to press Build, wait for it, and then go through 20 errors - if there are no errors marked, you can just save and instantly run the program.
- Code generation tools: generate getters and setters, create constructor from fields, create stubs for unimplemented abstract methods, etc.
- "Local History" automatically stores diffs of each file from the past X versions; you can compare and replace a whole class or just one particular method with a previous version from local history with a couple of clicks.
The only thing that I miss from Visual Studio is the form editor, but how many forms will you make for each project? And anyway there is a free plugin in development for that, it's just a bit slow and buggy right now. I think Visual Studio 2005 will add in some of these features, but even then, a C++ IDE can't give you as much help as a Java IDE because C++ is a more complicated language. In C++ you have #includes that simply paste in a file's contents, macros that can change the meaning of a common piece of syntax, #ifdefs, etc. It's a lot harder for the IDE to parse this in real time and give you meaningful information. It's nigh-on impossible to have it compile-as-you-type.

- Easy debugging: Same thing is true with Eclipse, or with Visual C#. Debugging managed code that runs in a VM is probably easier because there are fewer unexpected things it can do.

- Very good help: Java API reference for Java, or MSDN for C#.

- Easy integration/libs: Sure.. In C++, every library seems to declare its own type of int, float, and string, and sometimes even writing code to convert from one data type to another is time-consuming. Furthermore, you must link all these libraries into your project. In constrast, the Java standard library provides GUIs, regular expressions, image I/O (including JPEG, PNG, GIF), GZIP or ZIP compression, easy to use networking, XML, database access, and many other useful API's, all very tightly integrated, well designed, regularly updated (since they come with the JVM), and easy to use. If you want to use an external library, it's easy to add a JAR file to your classpath or just drop it in the /lib/ext folder of the JRE.

- Multiplatform: C++ is only multiplatform in that there are compilers for it on different platforms, and there are libraries which have been ported to all these platforms. Almost any programming language is "multiplatform" in this way. With C# or Java or Python, you just copy a file from one computer to the other and it works. Furthermore, C# and Java declare sizes and signedness for their primitive data types (int, etc), as well as other behaviour such as the meaning of "i += i++", whereas in C++ there are many things left "unspecified" by the standard, and you must write code defensively to deal with this.

- Fast and can use CPU specific futures
It's true that C++ lets you do a lot by adding assembly code, but with Java, you can run an old program on a new Java Virtual Machine and take advantage of CPU instrictions that weren't even around when the program was written. How often this will really be useful is a different question though.

- That code you make now can be good for a cople of years
In Java, the code you make now will likely work better in a couple of years because of bug fixes in the standard library, updates to the JVM, etc.

- Standard API
The only standard API in C++ is the STL, for console and file I/O, memory management, math and some data structures. The .NET Framework API and the Java API cover many more things (see "easy integration").

I think the main reason that game companies stick with C++ is that they have existing code in it. Once you've written your graphics wrapper, I/O wrapper, networking wrapper, window framework wrapper, image loader, memory manager, RTTI system, etc, you can easily use C++ as a high level language. So you reuse your engine in future games, adding extra code to each part as required. If you are starting from scratch, however, as most people on gamedev.net are, you'd be a lot better off choosing a language and framework that already provides this functionality for you, so you can get on with the really interesting things that make your game idea unique.
Advertisement
C++ pro

We have nearly 2 decades worth of source code from our previous games, libraries and utilities on our computers written in it.
c++ is fast,easy and I have full control of my program. I also don't have to worry about relying on a .net frame work or anything else.
==========================blog: http://piccahoe.phase1media.comCompany:http://phase1media.com
Java and C# are 2 great languages but they are framwork dep. ,slow and eat a lot of memory.

I like NetBeans for Java IDE (it's so great) but it's so slow. (It's not going very good on a P4-2.6GHz).

Java don't have native support for OpenGL/DirectX (it's working on this :: can't make a hardware opengl applet)

C# is great but it's close related to MS tech. (C# is my next option after C/C++ and maybe with LUA for scripting)

what about python?
Quote:Hi guys, i dont want this to be a language war of any kind


You know, I can't remember the last time someone started a language war (deliberately or not) and *didn't* say something like that. And I'm not even limiting myself to the GD.net forums when I say that! ;)

So, here is my bitter, whiny, and probably flame-inducing input on the subject.

Why is everyone talking about Java like it's such a high-level language? :( "gomgom it does teh GC it r for scripting!!!11"

Java provides primitive types, static typing, the ability to make as much stuff static as you like, and JIT optimization of the compiled bytecode. Plenty of opportunity to escape the overhead that is stereotypically associated with the language. Real high-level languages don't really give you that escape. In Python, there is no way to express the equivalent of 'float' because every floating-point value is represented in a double - and then wrapped in all of Python's object overhead. The relative size of which is their justification for not providing access to floats in the first place (the 4 byte savings would be more or less pissing in the wind).

My judgement of things based on experience to date is that it's easier to treat Java as a "stererotypical C++"-level language as the other way around. Yes, there are very powerful things like Boost available for C++, but when something goes wrong even with a simple STL container, the compiler output can be very intimidating - you are shocked right back out of the illusion of working at a high level. Plus, there are limits to how prettily you can express those powerful concepts. (Consider weird hacks in Boost like the _1 variable.)
Quote:Original post by Matei
- Multiplatform: C++ is only multiplatform in that there are compilers for it on different platforms, and there are libraries which have been ported to all these platforms. Almost any programming language is "multiplatform" in this way. With C# or Java or Python, you just copy a file from one computer to the other and it works. Furthermore, C# and Java declare sizes and signedness for their primitive data types (int, etc), as well as other behaviour such as the meaning of "i += i++", whereas in C++ there are many things left "unspecified" by the standard, and you must write code defensively to deal with this.
C++ is also portable to systems for which a VM is unfeasable.

I'm not sold on the sized types issue. If I don't explicitly specify how many bits a value ought to occupy, I would prefer that the language assume that I don't care and decide what's best for me.

Quote:- ... with Java, you can run an old program on a new Java Virtual Machine and take advantage of CPU instrictions that weren't even around when the program was written.
Like LLVM? :)

Quote:- That code you make now can be good for a cople of years
In Java, the code you make now will likely work better in a couple of years because of bug fixes in the standard library, updates to the JVM, etc.

- Standard API
The only standard API in C++ is the STL, for console and file I/O, memory management, math and some data structures. The .NET Framework API and the Java API cover many more things (see "easy integration").
It also makes for a pretty bulky dependancy.

Quote:I think the main reason that game companies stick with C++ is that they have existing code in it. Once you've written your graphics wrapper, I/O wrapper, networking wrapper, window framework wrapper, image loader, memory manager, RTTI system, etc, you can easily use C++ as a high level language. So you reuse your engine in future games, adding extra code to each part as required. If you are starting from scratch, however, as most people on gamedev.net are, you'd be a lot better off choosing a language and framework that already provides this functionality for you, so you can get on with the really interesting things that make your game idea unique.
Absolutely. Migrating to a completely new system is inherently risky and expensive.

However, C++'s difficulty has led me to think that it may be best treated as an optimization that is best put off until some decent profiling can be done.
"There is only one everything"
We really seem to basically have the same opinion on the "why c++?" question (fast and lots of code already available). Also the low-level for engine, high-level (scripting) for game-logic doesn't seem to be controversial at all.

As someone has already pointed out above: won't it be "more efficient" (please don't expect me to define this) for a single-person project to start with some high-level scripting langauge to get things running, then do some profiling and rewrite the speed-critical stuff in c/c++?

I'm always horrified if i see one of my friends starting a game in c++ and it's obvious, that they simply wont get it ever finished.

i really cant see why java is supposed to be high-level... for me this means more than having a big standard lib but being able to use "builtin-high-level" functions for manipulating my data. just one example:

Java:
FileInputStream fstream = new FileInputStream(args[0]);DataInputStream DataInputStream in = new DataInputStream(fstream);while (in.available() !=0){   println (in.readLine());}


Python:
for line in open(args[0]).readlines():    print line


I think so far we mananged the situation well and the thread didnt become a language-war, and I brought the above example to clearify what i mean with "builtin-high-level". No way I think Python because of this is "superior" to Java.

edit: I have to check out Luna you guys are talking about.
Quote:Original post by sim27
As someone has already pointed out above: won't it be "more efficient" (please don't expect me to define this) for a single-person project to start with some high-level scripting langauge to get things running, then do some profiling and rewrite the speed-critical stuff in c/c++?


I won't ask you to define "more efficient," if I can assume you mean in terms of development time. :)

The methodology you describe makes sense. Many programmers use it in one way or another. I followed it to some degree with my graphical MUD project, which also happens to be my most ambitious game project to date. I programmed the server engine in C++ from the beginning, because performance was crucial; but one of the first components I implemented was an embedded script interpreter. From there, it was common for me to implement new features in scripts and move them to the C++ core when the script's performance was unacceptable. I also wrote the first version of the game client in Visual Basic, expecting it to be nothing but a temporary prototype, but so far it performs well enough and I haven't needed to port it.

Quote:
I'm always horrified if i see one of my friends starting a game in c++ and it's obvious, that they simply wont get it ever finished.


Most hobby games in general don't get finished, regardless of the language. I could also posit that a fair number of programmers who start with a high-level language will quit because certain features will require more optimization than they're capable of doing. :)
Post Extant Graphical MUD
Don't know if I've missed the boat on this thread? :(

I've been (don't laugh) a pro VB6 app. developer for 5+ years, and spent the last few months learning C++ using directx. At work we have just jumped into the whole .NET thing, but I don't know where to take my games programming, language-wise. Is it even worth carrying on with (unmanaged) C++, or should I be using managed C++?
But if I do that, what's the point in using C++ at all... I could be using C#, or even (gasp) VB.NET....?

I've always dreamt of switching to games programming for a living (mind you, I'm probably too old!), but does the possibility exist that by the time my C++ is good enough, the whole world will have abandoned it?



Quote:Original post by sim27
I am mostly interested in getting something up&running .. so no matter how hackisch and slow it might be, my (!) fun time starts when i get away from coding terrain-engines, loaders, shaders and that kind of stuff towards the game-logic side.


you could try just throwing APIs, wrappers, other people's (open-source) engines etc into c/c++
You'll have graphics, sound, network, input, etc very quickly. Thats what im doing at the moment.. then I go back once in awhile and work on my own graphics engine, or write my own socket wrapper.

This topic is closed to new replies.

Advertisement