C versus C++

I am hoping to try my hand at OpenGL coding in C using Win32. This is partially because of efficiency and partially because it should be interesting. Anyway, I got to thinking about how C++ does it’s OOP stuff. I would think that object-oriented creates a lot of overhead. The only compiler I have right now is Microsoft Visual C++. I was just curious as to whether or not the compiler puts in all the C++ crap when I compile a program that doesn’t use OO. If I am going to have to put up with the overhead anyway, I might as well go object-oriented. I know this isn’t exactly an OpenGL question, but no one has been able to answer it so far.

Anybody have any ideas on this one? I’ve heard that many game companies create their products in C, instead of C++.

Will
Gantww@lipscomb.edu

II was just curious as to whether or not the compiler puts in all the C++ crap when I compile a program that doesn’t use OO.

If you compile C source with a C++ compiler no “C++ crap” will be thrown in.

I’ve heard that many game companies create their products in C, instead of C++.

C++ is rapidly gaining ground in the games industry.

While it is true that C++ adds some extra overhead, if you are careful in the design and granularity of the objects, this extra overhead can be really quite insignificant.
Even the guys at id Software (who have exclusively used assembly and C) have finally begun using C++ starting with their current project, Doom 3.

A couple of years ago I coded a DOS engine in C++ from the source of another in C.
C source was compiled with watcom, C++ with djgpp, and the size of the 2nd was bigger.
Ok, but performance was better: maybe using some oop lets you organize efficiently the code? I think yes.
I always preferred C++!
tFz

I’m glad to know that object-oriented techniques don’t impact performance to a large degree if coded properly. I had always assumed that it would have a more severe effect than it apparently does.

Next Question: MFC? Good, bad, or indifferent? I know that it does a lot of abstraction in regards to the message maps, windowing, etc. Should I just stick with STL classes and custom classes I write (if I code them carefully…) instead of using theirs?

Will Gant
gantww@lipscomb.edu

I thumbed through a game programming book recently called “Real-time game programming” that pointed out a number of instances where c++ code ended up actually being faster than equivalent c code. I don’t remeber the specific examples but I’ve always believed that speed is not something to really worry about when comparing equivalent c and c++ code.

I would avoid MFC like the plague, unless you are absolutely positive that you will never want or need to port the source code to another platform. I’d stick with STL classes, even those are not 100% compatible yet across platforms, but that just requires a bit of code tweaking so it ain’t that bad.

I’ll echo what DFrey said. His reason is perfectly good, but I’ll add this one (which will undoubtedly start a flame war):

In my experience, people who go hard care with MFC and think that MFC is the end all and be all of C++ design are adversely affected for the rest of their lives. MFC is a terrible example of C++ usage. If you need, only learn what you need, then quickly forget it.

My Cdn$0.02

I actually like MFC for a lot of things, but I wouldn’t use it if you are looking for the best possible performance. The things I like about it is that it gives an abstraction from the Win32 API, but you still have the ability to work on a lower level if you need to. It is a lot better than Borland’s OWL classes, IMO… those are just ugly. To VBish for my tastes. Anyway, for things that don’t require high performance and will make a lot of use of Dialog boxes, menus, etc. (like maybe a model viewer) I would definitely go with MFC. For something like a game or demo, where you want to squeeze as much performance as you can get, I’d stay away from it.

I’ll echo Deissum’s comments on MFC. It’s pretty good stuff, if performance isn’t an issue. It is fairly easy to use (and VC++ is willing to give you a hand) and more powerful than GLUT. I use it when I want to test various parts of code (like a landscape engine, or the animation code). Basically, I use it for anything that isn’t a full-fledged un-Windows program (by that, I mean a program that has a minimal use of the OS’s GUI services, like a game).

[This message has been edited by Korval (edited 04-25-2001).]

Ok, I’ll echo someones opinions too. I choose Dfrey and rts. MFC is very easy and very quick to program, but it just isn’t the best choice for gl applications in my opinion. Go with Win32 if you wanna get more polygons at a time outta your GPU. Don’t forget; the farther you get from your CPU native instructions, the slower your applications will get. Avoid high-level classes and libraries as much as you can but not necessarily all the time.

Personally, so far I prefer C, mainly because C++ is the same except for OOP. All the other differenses are non-consequential. OOP is useful, but I have not had a need for it so far. Unless you specifically are going to use OOP, I suggest you stick with C instead of C++. I also prefer GLUT, for 2 reasons, 1 is that it is much easier to set up a program in GLUT, 2 is that it is totally cross platform. I use a win98/Linux rig, dual boot. If I am going to create a program, Id want everyone to be able to use it, not onle Win32 PCs. Maybe GLUT is slower (im not sure thought), however, GLUT is only used for a tiny bit of a program (initialisation and keyboard control), this tiny part of the program, even if a little slower, will hardly have any impact at all on the total speed of the whole program. I think it is worth trading a LITTLE performance, for ALOT of ease of use.

Hmm. I don’t want to launch into the whole imperative / object orientated debate. However, I will say this: OOP isn’t a tricky feature which is nice to have but is frivilous in all other repsects. It ins’t like having a funky LCD display on your cd player that looks pretty but is ultimately useless. OOP is a methology of programming; It is, no less, an important prorgamming paradaigm.

There are other programming models: C/Pascal/BASIC are imperative; C++/Java/SmallTalk are object-oriented; Miranda/NESL/Lisp are functional; Prolog (and precious little else=) are Logical. My point: OOP isn’t just a funky addition, its a way of coding.

… i could say more, but i won’t. FEH.

cheers,
John

Originally posted by Psyche:
Ok, I’ll echo someones opinions too. I choose Dfrey and rts. MFC is very easy and very quick to program, but it just isn’t the best choice for gl applications in my opinion. Go with Win32 if you wanna get more polygons at a time outta your GPU. Don’t forget; the farther you get from your CPU native instructions, the slower your applications will get. Avoid high-level classes and libraries as much as you can but not necessarily all the time.

If you want to code optimized GUI/message handling routines, go ahead. I’d however recommend spending time on optimizing stuff that takes time to execute, like rendering and math intensive stuff like collision detection. If you’re spending more than a couple percent of your execution time initializing GUI classes and handling messages then optimize all you want, however this has never happened to me yet, so I optimize other stuff. Don’t worry about whether it’s optimized or not if it isn’t slow, go with what’s gets the job done fast. If that happens to be MFC or some other high level GUI library, so what? It’s not like the GUI is a performance bottleneck anyway.

instead of thinking whether to use C or C++ it’s better to get used to say Ocaml 3.00… nothing better released so far… simple, functional and fast language…

Harsman, I agree with what you’re saying mostly but don’t forget that you’re rendering on a Winbloze device context and if that device context is lagging or not optimized, it will slow your rendering context down along with it. But of course, depending on your projects size and complexity, this might not be the case at all and whether using Win32 or MFC would not make a difference in that case.

So you can use ML to make OpenGL programs. Usually is it good to hear that you can do GL programs with some other language… but ML?
ML is the elites own little toy that they use to make little toy programs.
No hesitation - ML is the only alternative for the “real” people the other is for the half-monkeys.
No hesitation about how they behave and what rights they have.

All that is just stupid, sick and disgusting.
You should not look up to dirt like that!

Well, surfing the web i found this interesting fact on Gamedev (i think, not sure thought). It says that the id software team has been using C as their language of choice, and only recently moved to OOP. The first game they are going to do not in C is Doom3, that means that Quake3 was dont in C, and not C++. I find this rather interesting.

ive been using c++ for ages but mostly avoiding certain c++ things templates/multiple inheritence

why? heres a nice example of doing the dotproduct with templates.

			// Vector dot product
			//
			// Specialized for Nx1 matrices (i.e. vectors)

inline const T dot(const matrix<N, 1, T> &m) const
{
T result = (T) 0;
for (unsigned int i = 0; i < N; i++) result += _data[i] * m.data()[i];
return result;
}

Hey, with the discussion of glut and mfc and the rest, I thought I might offer my dinky little wrapper modules (called MonkeyLib…) I wrote for Win32 games using OpenGL & DirectX… Dosen’t do much but the core window setup and exposing some simple functions like PlaySound and LoadTexture; but it’s a spiffy little transparent wrapper, just add the core files to your project and start your MonkeyLibMain() main loop…
http://www.areth.com/monkeylib.htm

Very, very free and hacky but perhaps useful…