I'm not attacking C++. I'm not "defending" C. What I am doing is trying to impart a little hard-earned wisdom for stuff like this. Using this particular bit of code is completely overkill and just utterly smacks of the modern attitude of C++-or-bust.

This is not a crusade - it is practical game-programming experience material. I've seen C++ used in large scale projects where everyone "thinks" they know how to use C++ because they grasp the basic concepts of inheritance and polymorphism. And I've seen that very thing become a complete and utter disaster, requiring entire rewrites of major (and majorly entrenched)systems.

This is gamedev.net, where lots of people come for advice. I see lots of poor advice given out here from time to time. My advice here is just this - seek simplicity, readability and portability when considering how to use a system. This particular case is just a great example of the opposite.

A _truckload_ of beginning programmers never get to the point of actually producing something they can look at and go "hey, that's cool!" because they get entrenched in ultra-formalism and conformance to whatever is new (C++, in this case). Take the simple route, learn to design simple systems and implementations and actually _make_ something. Worry about all the really crazy stuff later when you're really more qualified to judge just how "useful" a systme is.

Do I know how to use C++? Feel free to email me to discuss my qualifications :/

Edited by - daveb on September 5, 2000 8:56:37 PM

Please do not feel that I am attacking you - if it sounded that way I apologize but here is my point:

For what I need to accomplish, there is no 'simple' solution. Let me ask you, considering that I am using C++ and the STL container classes, how would you propose that I safely enable containment by reference instead of containment by value?

What looks difficult and convoluted to one programmer is elegance at its finest to another. A tad cliche but very appropriate.

Let me pose two questions:

You stated that:

quote:
seek simplicity, readability and portability when considering how to use a system

Can you please explain to me how C++ is less simplistic and harder to read than C?

Exactly how is C++ less portable than C?

How would you implement a Handle to a dynamically changable type?

The problem I'm having with you is not what you are saying but how you are saying it. You are not providing any concrete reasons as to why C++ is not suitable for game programming.

FYI:

Unreal Tournament and other high-profile engines are implemented in C++ and seem to have no problem being ported to other operating systems and platforms (consoles in particular ex. PSX2). Tim Sweeny doesn't have a problem with object-oriented languages and I would hazzard to guess that he is more experienced than you or I put together.

- Dire Wolf

Edited by - Dire.Wolf on September 5, 2000 9:21:47 PM

Heh. Dire - I wasn't replying to you. Sorry for the confusion

While its tough to put it in a nutshell, I'll give you a few proverbs.

One very natural use of C++, specifically overloaded operators is for 3d vectors and matrices, right? This isn't even really hardcore C++ but it gives you the idea. On a particular project I was working on we decided to go with the straightforward implementation of overloaded operators for vector math (add, subtract, dot product, etc). This was a 3 platform game. Once everything got up and running, everything worked great. Then we started noticing a _lot_ of extra code was being generated when we used overloaded operators. Turns out, because different compilers deal with returned references differently, for the code

c = a + b;

instead of generating 6 adds and 3 stores, was creating a temporary vector to represent C, loading 6 elements out of a and b, doing the adds, storing the result in the temporary vector (3 more stores, and _then_ loading those 3 values back and storing them again in the actual return value (c). That's 9 extra load/store instructions - which is a horrendous problem on a machine with 8k of data cache, like our particular lead platform was. And all of this was magically hidden from us by the magic of overloaded operators. The moral here : when you're looking at code using overloaded operators, you never know what you're going to get. Who knows what c = a + b means if you're using overloaded operators?

To be fair, this is a fixable problem, but if we had never noticed it, we could have taken massive speed hits because of the "wonderful" mechanism of returned references and overloaded operators. Think about how much worse a matrix * matrix operation was. =o


Another great example. We tried to implement our own string class. The idea was to encapsulate string operations and never have to worry about running off the ends of arrays. In principle, also a Good Thing. Turns out, because we were able to do stuff like adding one string to another (concatentation) and doing "==" for equivalency, we were constantly doing dynamic memory allocation. _Tons_ of it. Our game had tons and tons of debug spew, all of which used the string class. End result, hundreds of thousands of small to mid-sized news and deletes just loading a single level. All conveniently hidden within the string class. You know what happens when you run out of memory on a console system because of fragmentation? Your game stops, and you've just shipped a game that crashes. Whee.

I won't even _get_ into the issue of how templates cause plenty of compilers to choke, or how even default constructors can add tons of processing overhead to functions with large static arrays of class objects.

Now, realize, these are just two examples. I'm sure there have been successful implementations of both of the above examples. But the point is, you had industry veterans who had shipped multiple AAA titles, and they _thought_ they knew C++, yet it was slippery enough to have crazy problems like that sneak in. And yet all of those issues had never come up before when using straight C in the past.

My point here is, C++ is _not_ bad. But it _is_ deceiving. Its a seductive way of thinking and it makes you think you're an expert when you're not. So you start trying to cram all this unnecessary stuff in where much simpler methods could be used. In my experience, simpler == better == safer == game gets done sooner.

How would I implement a Handle to a dynamically changeable type? I wouldn't. I would try and re-think my need for this dynamically changeable type and break it down into a simpler case. Maybe something like :

                    #define ANIMAL_TYPE_CAT   0#define ANIMAL_TYPE_DOG   1struct animal {   int     type;   // see ANIMAL_TYPE_* defines above};            

If you really can't let go of classes, make that struct a class. That's not the point. I really think in this case, its a better idea to systematically simplify your problem instead of trying to use "advanced" C++ features to prop it up.

Edited by - daveb on September 5, 2000 9:35:01 PM

In regards to your string class, did you ever consider overloading operator new ? That way you could implement your own memory management routines specifially specialized for strings.

You and I are coming from two different worlds. I work on game programming as a hobby and write corporate software by day (it can be quite boring) and therefore our needs are different.

Personally, I''ve spent a bit too much time debating with you tonight and now I''ve got to pull a ''late-nighter'' Still, I thank you for your input and yes, I did start with C programming. When I transitioned to C++ I constantly asked why things had to be so difficult (mainly templates and specialization). Then again things seem much clearer now...

- Dire Wolf
direwolf@digitalfiends.com

quote:
You and I are coming from two different worlds. I work on game programming as a hobby and write corporate software by day (it can be quite boring) and therefore our needs are different.

You''re right. This is an important distinction. In my eyes, the problem is not C++. The problem is the application of the language to the particular problem of making _games_. I haven''t been convinced that the ways I''m seeing it used are really the best way to do things (when making games). I''m sure there are kinds of good reaasons to use C++/Java, etc for business/other applications. I''m sure those self-made billionaire high-tech guys out there would definitely agree

Scott Meyers'' "Effective C++" and "More Effective C++" are excellent sources for questions and problems dealing with c++ performance and avoiding c++ pitfalls. I think the "More..." book even has a smart pointer class. Also check this link:
http://ootips.org/yonat/4dev/smart-pointers.html

Mike

OK, I gotta jump in here.

Dave, I did as you suggested and checked out your credentials. I come from Dire.Wolf''s side of the programming biz, so I too have a much different perspective than you. I''m sorry that I can''t boast about my credentials (my company doesn''t like that). Suffice to say we''re a communications company on the Nasdaq-100, and have more than 5000 employees. And it''s NOT Microsoft.

What disturbed me about your initial post, in addition to its acidic tone, was this line:

quote:
Where I work, we''ve rejected _lots_ of potential programmers simply because they can''t see outside of the C++ box. Its really terrible. They don''t understand the significance of memory allocation, the significance of easy to read code, or the significance of _few_ layers of abstraction.

Is this really true? I''d venture to say you''ve let some great people go. Personally, I started on embedded systems in ASM, then in C. I do lots of graphics now, which is why I hang out here--many times my problems overlap with game designers. That and I''m a hobbyist. But let me tell you I''m firmly rooted in the world of OO C++ now. There''s simply no faster way to develop code.

Restricting yourself from C++''s new features is like cutting off your nose to spite your face. Without polymorphism, how do you get rid of all those switch-on-type statements? That kind of code is inefficient and dangerous--changes to the type must be propagated to many different parts of the code. Having code repeated anywhere is a heinous problem which leads to mistakes, and almost all of C++''s new features are designed to eliminate all repeated code.

OOP can be used to solve problems. Hamstring your interviewees all you like, but you might be passing up brilliant new entries in the workforce. In fact, why don''t you send them my way?

Very interesting discussion, and although I pretty much am on the pro C++ side, I have to save daveb got some important information out their (potential deceptions in c++ that can kill you), ONCE his posts started being about posting details and helpfull content and not worded like flames and rhetoric soory dave, but your first few post almost put me off enough to ignore the rest(because some of your anti C++ statments seemed fairly narrow midned - just like many newbie C++ advocates who say ... OO is better ... in a catch all sort of way), luckily I didn''t.

I want to say this. I have been programming gambling games (800x600x16 bit 2D DirectX games put inside a stand up cabinet) for about 3 years now (the first two were actually written in x86 assmebly for a proprietary OS, but that is long gone). And I have used C++ heavily (almost exclusively) for nearly 2 years. Our games use almost EVERY advanced feature of C++ (not for there own sake, but just that as we learned them we''d find 1 or 2 good applications for them), including fairly extensive polymorphism, the STL, template classes and functions, exception handling, and some crazy techniques - including plugable factories (READ THE ARTICLE ... it''ll show you something C++ can do for you that is truely useful). I know for a fact I pay a performance penalty for many features we use (for specific features, not C++ in general), and that occasinally in the past, our first solution worked, but was extrodinarily inefficient. But, with experience comes wisdom (at least if your paying attention), and now (just like the Guru C programmers) we know the costs of our C++ idioms, and can choose when using them is worth it TO US. Often doing a nicely laid out OO solution is more complex and longer to develop. But when we can see REAL reusability benifits (usually having to do with the C++ version BUILDING on an already tested base, where the C version would be MODIFYING similar code - which is more error prone in our experience -- or sometimes related to an OO solution in one module being much more WHOLELY plugable into another module (C is always plugable, but the glue code must usually vary more)).

I don''t have time to post near what I''d like to ... but anyway ... in parting I say ... until you have really dug deep and thought about the costs, use C++ and OO desigs, but keep it simple and avoid unneccesary work in the name of encapsulation or purity of design that you KNOW will never be reused (don''t design a supremely reusable WIGIT module if you know Program X is the only program that will ever need to use a widgit, and only in one, well defined, way).

Oh yeah ... to earlier posters who tried to suggest simple non-templated version - there was a MAJOR difference to this templated HANDLE class than the simpler solutions you proposed. This version is intended to provide TYPE SAFETY -AND- RESOURCE MANAGEMENT. Some form of typedef or universal pointer has ZERO type safety ... so just try and debug a case where you pass the wrong handle to function, and it blows up calling functions that don''t exist.

(I cannot wait until compilers are smart enough to allow you to set break points JUST BEFORE the call to a function - so when you know function A is crashing ... you set the breakpoint to stop at every CALL ... and you see WHO''s the last person to call it before crash, and what the parameters are)

Later

daveb:

I'm not sure about your credentials, but even having invented the IBM computer or single-handedly designing the entire line of Pentium processors would not make you good at C++ programming. If a 19-year, wet-behind-the-ears college student could have told you about all of those things and explained exactly why they were happening, would you have listened? (<-- that's my credentials - 6 months of college, and I'm proud of it! )


You could probably tell me a lot more about this, but here's my take (I don't have web space that allows direct-linking, so I can't post the pictures. besides, people can probably make better pictures with their imaginations than I could possibly draw ):

Let me tell you a story. A long long time ago, people used to code whole programs in one continual line of code. Sure, there were statements for conditional branching, and wonderful things called line numbers. (I remember typing in line numbers...ugh...add one line in the middle and...) They even had labels! Code looked like this:

(picture of a large blob of disorganized code)

Then, someone came up with a great idea: subroutines. That's right, you could take blocks of commonly used code, and put them into these subroutines, and even re-use common subroutines in different programs! Code looked like this now:

(picture of a poorly balanced tree of subroutines)

Finally, people invented functions. You could simplify common tasks, and even return a value to the function caller! This was amazing, as people were finally grouping code together according to its use!

(picture of loosely grouped (but balanced) functions)

Amazingly enough, programming was becoming quite nice. You didn't need line numbers or labels (very much), and you could pretty much code the way you liked. One of the best languages of this time was C - it was close to assembly, while providing just enough abstraction to be much more useful than a macro language. Programmers liked it, and over a long period of time it matured into a stable, portable, common language. People became quite adept at making libraries, and even semi-large software projects in C.

However, progress doesn't stand still for long. Eventually, people figured out that functions were important because they operated on data. Finally, someone came up with the most unbelievable idea! - Let's group functions according to the data they use!! The process was called classification, and used classes. This is called Object-Oriented Programming (OOP).

People were already doing it a lot in C without realizing it. You've heard of modules, right? Well, that's a grouping, or classification of functions according to the data on which they operate. Look at the standard libs you've got things like time.h, file.h, etc. Look:


/* display.h */

typedef struct _tagRGB
{
byte red;
byte green;
byte blue;
} RGB;

typedef struct _tagRGBA
{
byte red;
byte green;
byte blue;
} RGBA;

typedef struct _tagDISPLAYMODE
{
byte mode;
short width;
short height;
byte bpp;
byte refresh;

void* next;
} DISPLAYMODE;

static DISPLAYMODE current_mode;

void set_display_mode(DISPLAYMODE* dm)
{
/* set the display mode, clear the screen */
}

void find_display_modes(DISPLAYMODE* head)
{
/* build a linked-list of available display modes */
}

void clear_screen_rgb(RGB color)
{
/* clear the screen to the specified color, using the current mode */
}

void clear_screen_rgba(RGBA color)
{
/* clear the screen to the specified color, using the current mode */
}



Software was growing even more complex, and people wanted language support for it. C++ has it on the language level, allowing you to put these functions and data structures in a "class," of which many instances can be created easily and efficiently - not unlike the C/assembly concept of data structures.

Here is the same module, re-written as a class in C++:


class display
{
public:

struct mode
{
int width;
int height;
byte bpp;
};

struct rgb
{
byte red;
byte green;
byte blue;
};

struct rgba : public rgb
{
byte alpha;
};

display();
~display();

set(mode& dm);

find(std::list&ltmode>& modes);

clear(rgb& color);
clear(rgba& color);

private:
mode current;
};



You probably knew all of this before I was even programming, but I wonder if you've looked at it this way? Classes aren't anything new - it's just language support for what people have been doing for ages. Yes, when you introduce new features like user-defined operator overloading, virtual functions, etc. they are a bit abstract. They allow you to control interaction between modules (classifications of functions and data) in new and different ways.

I agree that there has been a lot of hype about C++ - as I've said on other occasions I think it does more harm than good - but that's no reason to believe that people are there to trick you, or that everyone wants to convert to C++ code for no good reason. The other people that responded to your post before I am now listed some of the benefits that come with knowing the language. Yes, you have to know the language. A language that can do both low- and high-level constructs is going to be a bit more complex than a language that does only low-level constructs. I don't mean that you can't do multiple instances of modules in C - it's just tricky and IMO more trouble than its worth because the language doesn't provide direct support for it.

So, yes, if you've been placing all your code in modules in C, then all of your code belongs in classes in C++. People who say "most programs don't need classes" don't know why classes exist, and what they do. Sure, they may know that classes can have functions and all that - they may even know about the different modes of access, etc. But if they don't know why classes exist, they won't get much out of using them. Classes are a way of organizing code; they don't magically make better code or anything even close to what some people might claim. It's a tool. If you are willing to put enough into it to get something back in return, then do so.

If you don't know how it works, don't use it. What you don't know _can_ hurt you, as you have found out the hard way.


- null_pointer
Sabre Multimedia


Edited by - null_pointer on September 6, 2000 9:44:37 AM

vladg pushes his way through the angry mob ganging up on daveb and screams “Let me have a go!”

quote:
By daveb:

You throw this class in front of a 1 or 2 year guy with little exprerience and his eyes are going to cross.

That’s a poor argument. If the guy is any good he’ll pick up a C++ book, trace through the code and figure it out. If he can’t learn he has no business being a programmer. And he is likely to introduce a score of bugs with or without C++. Sorry if that sounds harsh but I believe that programming is a meritocracy.

quote:
A good # of C++ compilers are not going to get the code right.

It’s a valid point but it’s an issue with a platform/compiler not with C++ as a language. If you plan on porting to one of those platforms you have to live with its limitations. It’s a business decision (bigger market vs. shorter development cycle) and got nothing to do with programming.

quote:
I would just love to see a shift in the mentality from C++-is-king to C-is-king-with-some-C++-on-the-side.

There is no spoon… err... no king. A language is just a tool for a job.

I understand were you are coming from, Dave. If you are developing for platform with poor support for C++ standard – C++ is a bad choice. If half of the team is new to C++ - developing in C++ is risky and you are likely to miss your deadline. And I agree with all that. What I do not understand is how you jump to:

quote:
There just can''t be a legitimate reason to use something that complicated.

Functional programming is not the be-all and end-all of programming paradigms. Most of the people on this board (me included) are hobbyist game developers, and I would only encourage them to explore OOP and generic programming and anything else they want. Hard-earned wisdom must be earned, if it’s imparted it’s called religion or ideology. Real wisdom is not a “Foo-is-king” meme, it’s knowing why under certain conditions Foo works better than Bar.


Sorry for this long rant, I felt it was important.
Dave, no offence, ok?