Hmm… that is quite interesting…
so it would be better to use exception handling if you are initializing something at the very start of a program, or a user-define option change, rather than doing it every frame?
By the way, how compatible is C# with C & C++? I mean just library wise…do you have to get special rebuilt libraries just for C# (e.g opengl32.lib) ?
[This message has been edited by drakaza (edited 09-16-2000).]
Umm… you didn’t get the point.
Don’t use exception handling for normal flow
control AT ALL. Use exception handling only
for errors. Assume that each thrown
exception takes a full second. That’s not
true, but it’s a good assumption.
Can C# call system DLLs? I hope so, but as
I haven’t seen or used it, I wouldn’t know.
Thanks bgl, it’s much clearer now. I’ve got some more reading to do on error handling.
Also i thank everyone else too, for all your input! Enough from me.
bgl - could you recommend any good sources for learning x86 assembly? I’ve not written any asm since 68k back on the 'Miggy, but I keep meaning to.
I don’t agree that virtual functions should only be used to replace function pointers. A more common scenario is using them to replace a big conditional mess of different calls switched on a type code, which is also very worthwhile.
And sadly C++ is NOT “as portable as C these days”. It’s close, but it’s not there yet.
From what I gather, C# is a rehash of Java++
glBegin( GL_FLAME );
When I say about half of MS C++ is propreitary I mean: about half of MS C++ is proprietary!! If you look at the documentation it goes someting like
blah
blah
blah
blah
BEGIN MICROSOFT SPECIFIC
blah
blah
blah
END MICROSOFT SPECIFIC
Stuff like extra keywords for compiler hints, anonymous structures, crap type checking, errors as warnings etc…
I only have VC6 but larger MS version numbers usually mean more ****e in a larger space 
glEnd();
Well, when a company is worth $220 Billion, why not go further and create a little world for your company which will later replace all the other worlds out there?
bgl - could you recommend any good sources
for learning x86 assembly?
Sadly, no. I just disassemble and read. And
when there’s something really weird (like,
I time an integer multiply to take
FOREVER !?) I go ask the pros around here.
(the 16-clock multiply is 32bit*32bit on
Cyrix hardware, btw).
And sadly C++ is NOT “as portable as C
these days”. It’s close, but it’s not there yet.
Luckily, my code doesn’t have to run on
PDP-11s nor on NEC mainframes.
Windows, Linux, BeOS, MacOS and the modern
consoles all have good C++ compilers. So as
long as you don’t use compiler-specific
extensions, you should be all set.
And making your code go through MSVC++,
CodeWarrior and GCC with full warnings on
all is a pretty good cleaner-upper; usually
well worth the trouble.
Here I don’t want to begin a war between coding in C++ and C or Assembler but C++ is better than C because of objects (Comment: it is better if your way of thinking is OO, if you think procedural there is no need to learn C++ if you know C). A simple example is MFC. If you use MFC you simplify your like by 90% and MFC is C++. I made programs both in MFC and SDK and I know what I’m talking.
And I don’t think I need to learn Assembler (I know the basics - I had a course at school) because it takes to much time to write code in it for simple things.
NewROmancer
NewROmancer,
Bad idea to talk about MFC : most people who are using OpenGL hate it !
Anyway, I agree with you : when you understand what you are doing with MFC, it saves you a LOT of time !!! Of course, it’s useless for games…
Best Regards.
Eric
If not MFC then OWL, it doesn’t matter. The idea is that OO saves you a lot of time and if you know well the compiler you don’t have drawbacks in the performance.
Anyway hope that this thread will be closed because we will won’t ever get to a common point here about this.
NewROmancer
Originally posted by bgl:
Windows, Linux, BeOS, MacOS and the modern
consoles all have good C++ compilers. So as
long as you don’t use compiler-specific
extensions, you should be all set.
“Good”, yes. “Fully compliant”, no. On MSVC6 I’ve already been bitten by “Koenig lookup only works for operators” and “member templates only work if inlined in the class declaration”. There are others; see MSKB article Q243451 for the known list. You might say these are obscure features, but they are part of the standard and they’re part of the standard because every so often they’re damn useful. The portability issue is not just about proprietary extensions.
And making your code go through MSVC++,
CodeWarrior and GCC with full warnings on
all is a pretty good cleaner-upper; usually
well worth the trouble.
Agree 100%. (In theory; in practice I never seem to get around to it You’re a better programmer than I am, Gunga Din.)
I’ve done a bit more research.
It seems as though if your “game” objects are diverse, yet similar in structure and need a lot of manipulations, classes (from C++) seem to be the logical choice. In my experience, C++ seems to gain an advantage over C the bigger the code is,whereas (for the biggest difference) C seems to rule when creating the small-scale “brute-force” sort of applications that need grunt but are not visually updated every frame (e.g. compilation program) and also games which do not have a relatively complex data structure (because it takes a long time to create “clean”,structured code), but need a good speed.
Please correct me where I am wrong, but this is the conclusions that I am forming…I am as always open to suggestions
To drakaza:
you can write code that you can compile with c libc or c++ libs (the same code…).
I work with MSVC 6 (I worked with Borland products a lot also) and if you know how to write code in C++ is as faster as C (personally i think it’s optimized for C++ libs). The C++ is better because you write less code and you can structure your program better. And how many try-catch blocks do you use in a game? When you open a file …
NewROmancer
>On MSVC6 I’ve already been bitten
>by “Koenig lookup only works for operators”
>and “member templates only work if inlined
>in the class declaration”.
Schucks. I guess I’ve just been lucky 
Part of it is that I put C++ in shared
libraries, and thus necessarily have to
restrict my use of templates.
On the subject of “MFC saves you so much
time” – that’s not because it’s C++, that’s
because someone else wrote and debugged a
whole lot of code that you can just leverage.
You could write a framework in C which saved
the C programmer as much time.
Ergo: know what you’re doing. If you’re
tempted into doing something you don’t know,
resist, OR do it with the clear expectation
that it will be a learning excercise, not a
full-steam-ahead deadline-hitter.
drakaza, it seems this thread has blown up.
Your original question was about the portability of C++, and its advantages and disadvantages.
C++ has a final ANSI standard and is portable across platforms. The problem is when you use system specific code. To make your application portable, make all your system specific code in another source file. For example I have system_init() defined in both x_sys.cc and win_sys.cc, the Makefile will select the right module to compile into the main application. In win_sys.cc system_init() will use WGL functions to setup OpenGL rendering on Windows platforms, but in x_sys.cc system_init() will use GLX. The main application calls system_init() without a care.
Another issue is the compiler, some compilers like MSVS will try to get you to use compiler-specific features which will make your source unportable. I suggest you use gcc, and also get the GNU ports of make, sed and grep for Windows. In this environment you can switch platforms safely and have the same files work for any platform that gcc supports (which is about everything).
The major advantages of C++ is the ability to construct large programs with ease. C++ really shows its power when you have thousands of lines of code. But C++ doesn’t do anything that you can’t do in C nor in ASM for that matter, because it all comes down to machine code. People tend to choose C++ when you are working with a group of people on a large project. C++ is a tad bit slower than C because of the overhead. Then again, if you really need speed you do it in ASM. C++ also does name-mangling on its symbols so that it can do function overloading, this can be a pain to work with sometimes when integrating with C or ASM.
My suggestion is to stick with what you like to work in, there is no disadvantage by working in C over C++. Though if you are working with a team of people, you might find C++ to be a better choice.
Good Luck,
/skw|d
Thanks very much for that post, I’ve learned quite a lot more about C++ since I posted the first message, and now I think I am confident enough to begin experimenting cross-platform!
Yeah, this thread has mutated almost beyond recognition.
Again, thanks ALL!
[END THREAD]
There are some compatiblity issues with C++ in some of the new syntaxs presented in MSVC and GCC. At least I’ve examined that some new features (like multiple inheritance) are implemented diffrently. If you go to lokigames.com and look at the source code for the mjpeg player, it is done in some weird use of C++ (its weird to me because I learned C++ OOP before it was a complete standard) and didn’t compile in MSVC. And if you look at COM objects in MSVC you see that it handles it diffrently. I’m not sure which is the better way, and which is the hard way, but quite frankly I think they both suck, and don’t give me far enough control and give you a head ache in deciding how to use them effeciently. Like for example, when creating an renderer object and rendering data object, should the renderer be aware of how to render all kinds of rendering data, or should the rendering data draw itself using the renderer. I’ve seen people try to do it both ways, but it does not work right. I’ve opted to do it totally diffrent then that all together, and it took quite some time and breaking away from common usage of OOP, and creating callbacks (which are not handled easily in C++ OOP, try calling a random function from another object), and let the renderer decide what it can or cannot draw, and require that rendering data meet the requirements, the rendering object itself just takes in a large scene graph and optimizes itself as best as it can for it (An opengl render for example will convert all pictures in a scene graph into its own texturemap data), but then you have issues of interactivity, so you need some forms of callbacks. Other then callbacks, then there is arrays and inheritance, obviously you cannot have an array of objects of diffrent inherited types, unless its a pointer array.
In some ways I’ve considered coming out with my own language, and simply creating a converter to convert it to C++. The Qt gui library, does something similar, and another program called GOBI (or soemthing) does that for GTK+.
I’d say that C++ OOP is still complicated despite making it easier on the typing, it makes it harder on the mind. What they do in with multiple inheritance is cool, but that has its limitations as well, I like COMs usage of Interfaces, but it has problems as well, such as adding interfaces at runtime to an object would be nice as oposed to compile time, instead of inheriting interfaces, simply add it to it during runtime, like plugin/extensions etc etc. In the end you cannot really depend upon using C++'s OOP syntax to much, even if it is easy to do, you will always have to do things that are not text book examples of using C++ OOP. Its easy to over do it, moderation is important.