Reply With Quote
I have always preferred tightly wrapped ravioli objects embedded in a succinct stratification of lasagna modules.
You think I'm kidding?
Choice of code design
So I decided to realize what I should have done a long time ago and actually start professionally developing games.
I always coded in C for my serious projects and made use of module-type code design. However with the upcomming game I may be coding with a partner and so I am thinking of choosing C++ and have an independent-object-type code structure so code can easier be upgraded, replaced and worked on in parallel by many people. I don't know any C++ but the very basics of how to create classes. I am also uncertain if it ravioli code is preferable to lasagne code.
What you all think?
Last edited by lordmetroid; 08-26-2007 at 02:56 PM.
I have always preferred tightly wrapped ravioli objects embedded in a succinct stratification of lasagna modules.
You think I'm kidding?
I was a late comer to C++ and still tend to write projects in what could be described as C with classes.
Short example, I will use a class to manage moving and firing different projectiles, but inside that will be a struct array and an ID enum. Pure C++ heads would use inheritance and have a class for each projectile type. I find that a bit silly tbh, as you never know what you're looking at, but I know that's just me, no flames plz.
To actually answer your question, I'd suggest learning enough C++ to code like that above, as other "purer" c++ coders can still deal with that whilst inheriting their own diamonds of death to their hearts content. You can decide later if you're happy staying like that or want to adopt more of the oop mentality.
Well, not needing to know the actual type is kind of the whole point.Originally Posted by Applewood
Here we go. You musta missed the bit that said this was just me and no flames plz. I know yours wasn't a flame, but this is how they start.Well, not needing to know the actual type is kind of the whole point.
FYI, I'm happy to have data-hiding help me avoid globals-related bugs and stuff, but the way I program I like to see where everything is. When it's 8 levels deep in inheritance it garners no faith from me at all. Whenever I program in an SDK that's written this way I'm always waiting for my bit to explode later. Max SDK is a classic example - If I could see the data I want to export, maybe I could bloody well export it without needing to learn the entire system.
Functional C programmers coming to C++ need to see the code they're working with whilst they learn the subleties. (Or in my case don't learn them because they don't actually help you get games finished).
Cue: Inevitable and boring holy war about how C++ solves world poverty...
C++ is a horrible monster that needs to die a painful death and forgotten by any miserable coder that had the bad luck to cross with it, but it won't happen any time soon because there isn't any other C-with-classes-like language since most people prefer to go for a managed approach for new languages, like if all problems in the non-managed world are solved...
If i didn't had to use 3rd part libraries (yes, i use a few), if i didn't had to work with others at some point, if it was officially supported in gaming platforms (xbox, ps, etc) and if the development environments weren't so screwed up (official IDE) or very narrowed to some kind of applications (Lazarus), i would write all my code in FreePascal. It has all the niceties of C and Pascal combined, without being the horrible beast that C++ came to be.
Another option would be Objective-C, if it's object oriented part didn't used an alien syntax...
I don't know what's up with all those people hating C++. They are usually used to another language and didn't learn how to code proper C++ apps. Just a grab a good book about C++ and another about Design Patterns and dedicate two or three months to learn everything you can about the language, making all sorts of apps along the way. The syntax and rules of a programming language can be learned quickly but knowing where to apply design patterns and learning how to design good classes takes some time. Learning UML is also useful when you are working on a big project because it allows you to see how everything is going to work. If you are not even comfortable with the way C++ works (classes, objects, inheritance, templates, polymorphism), I really doubt you'll be able to code proper Java programs, or even complete flash apps.
Nothing wrong, it's just that the language sucks :-). While it began with good intentions, in the way it became an overbloated monster with all sorts of little problems and special cases (you know, like the fact that 'new' in older compilers -before 1998- used to return zero when there was no enough memory and newer compilers raise exceptions - of which the behavior is unexpected if you actually disable exceptions from your compiler - so using proper C++ code written for earlier compilers isn't going to work with the newest breed, not to mention that such behavior doesn't really promise much for the language's compatibility with the future).
According to Wikipedia, C++ "It is a statically typed, free-form, multi-paradigm, usually compiled language supporting procedural programming, data abstraction, object-oriented programming, and generic programming.". So what's the proper way for writing programs in a language that is made to be programmed in many different ways?They are usually used to another language and didn't learn how to code proper C++ apps.
There are two issues with saying something like this. One is that you assume that whoever dislikes C++ doesn't actually know about the language and how to design a program. This is wrong, because in order to have an opinion or something (whether this is good or bad) you first must understand and learn that "something". So while there indeed are people who dislike C++ while knowing nothing about the language, there are other people who have a deep understanding of it but still dislike it because, well, it's a mess :-).Just a grab a good book about C++ and another about Design Patterns and dedicate two or three months to learn everything you can about the language, making all sorts of apps along the way.
The other issue is that you assume that people have to use C++ and they have to learn some "proper" (which due to the language's nature isn't really possible to define) way to program it. So why someone who programs C++ like if he was programming BASIC (i know such a person), Pascal, Java or some other "non-C++ language" is able to deliver the requested software with the way (s)he programs, has to spend three months (at minimum) to learn a mess of a language only because it happens to be the fourth most popular one? (java is the 1st)
Of course you probably think that i'm contradicting myself for saying that last thing, but really i'm stuck with C++ only because my teammates use it. In fact, where i work i try to NOT use C++ wherever possible (for example since i'm the only guy working in the tools, i use Lazarus for developing them... i feel more comfortable there and i'm more productive, so why not?).
That applies to most languages, not only C++. Even in Java where the language (and the API) somewhat forces you to use classes, in many cases you can just dump a shitload of static functions in a static class and call it a design.The syntax and rules of a programming language can be learned quickly but knowing where to apply design patterns and learning how to design good classes takes some time.
I can't comment on UML, i might check it out at some point when i have a lot of free time and comparable will, but from people who know UML and i respect their programming abilities, i've heard that it's a total waste of time.Learning UML is also useful when you are working on a big project because it allows you to see how everything is going to work.
Of course the same people dislike Java, while i like it, so you never know.
Sorry Applewood, what you did is like going to the center of an overcrowded beach with a huge speaker, yell "you are all morons, but i let's don't give much care about it, ok?" and expecting that noone will react :-P. Such topics are not flameproof by nature :-).
Anyway, just to offer a bit on the discussion here. I would recommend to stick with whatever you are most comfortable with. If that's pure and plain C, then stick with it. C is a powerful and simple language so you won't have problems working with it. Modular programming can applied to C as well, you don't have to use C++ for that (you don't even have to do OOP, just break your modules in self-contained libraries).
Now if you want to learn C++, do one step a time and just learn the traditional "C with classes" method. Don't overdo it with C++ities, because you'll lose the ball and instead of fighting with that damn algorithm that doesn't want to work, you'll fight with the language. For example, keep templates, rtti, operator overloading and complex, multiple constructors out in the beginning.
Yes there is - the D Programming Language - I like it!
That's just your pro C++ bias coming out - seriously, you love it and you know it ;-)
I'm sticking to the non-managed languages for core development because of the mess managed code can cause (different headache and one that I can't control as well). I migrate everything to scripting languages or data when possible. i.e Data-driven design.
For the record, I think OO is bunk. I much prefer design patterns rather than force a pure data-hiding / object-knows-how-to-do-everything-on-itself paradigm. When I see a character class drawing itself(with DirectX) or performing physics on itself I kinda pull my hair out...
This is why I risked my opening statement even though I knew it wouldn't stand alone.When I see a character class drawing itself(with DirectX) or performing physics on itself I kinda pull my hair out...
We had a grad start a while back and he was basically pretty decent at a fair few things, but he did all his projectiles and stuff like you say above - they all have a .move, a .draw etc. When I first saw he coded this way, I showed him how to unlearn that shit and do it 'my' way and our games frame rate stopped grinding when you let rip on the guns.
I can cope with anyone using any paradigm they're happy with, as long as it actually works properly!
Are you saying one shouldn't use the inheritance feature of classes at all? Or, do you mean that it is good to code in such fashion that one restricts inheritance to such an extent that one can easily keep track of what inherit what, right?
Yes, restrict to where it only absolutely makes sense to would be my advice, at least to get started. When you're more comfortable with it, you can decide then whether you want to use more of this feature.
It's not like it's a requirement though - I almost never use inheritance and my apps run just fine and maintain well - it's a personal preference as there is both an up and a downside ime. Given it's use is optional, I'd suggest putting it in the "learn later" pile and start getting on with the basics.
There are lots and lots of yummy things in C++ that could've been in C if they thought of them at the time - it's not *all* about OOP. C++ is a good environment to work in imo, with stuff like default arguments, constructors and my personal favourite; operator and function overloading. This one sounds scary but it'll change your life for the better! Every language should have this. You'll see why when you compare a C matrix/vector class with a good C++ one.
This is funny because a fewer of the things you've mentioned I don't particularly like in C++ - way too many gotchas in assignment operators and copy constructors and sometimes in overloading.
I love the STL - but that beast needs to be tamed on the console side. I love pure virtuals for creating "interface" classes (ala Java - which is a cleaner C++). I love templates even with the code bloat. I despise RTTI and C++ exceptions - they work, but add too much bloat in a high-performance game.
So how shall I structure my code? Is there any need for header files like in C and if so what shall be put into those files?
In the past I coded like my projects with multiple layers of header files like so, http://www.nopaste.com/p/aB1j88xdN Shall one do the same think in C++?
Oh, I quite agree. Whilst the features are nice, the syntax for them is an abortion and, I suspect, one of the reasons why people shy away from the language. I think they're tried too hard to make it look like vanilla c. Probably because in the early days it was indeed a c preprocess. But it isn't anymore!This is funny because a fewer of the things you've mentioned I don't particularly like in C++ - way too many gotchas in assignment operators and copy constructors and sometimes in overloading.
A "pure" cpp programmer won't have header files. You just have source and they're included lke headers in other dependencies. Basically, the source goes in the class definition itself (which to you would mean the header).So how shall I structure my code? Is there any need for header files like in C and if so what shall be put into those files?
I can't abide that though. I still use header files in the c style way, putting class prototpyes in the header and filling out all the functions using :: all over in a matching .cpp file. Because then you can still look in the headers for info without getting swamped with code. It's a pure productivity decision that goes against the grain of accepted wisdom as header includes are admittedly a pita. Forward class refs are nicer in cpp though so it's not as bad as c and I know I'm not the only one to work this way. In fact all our new guys have said they prefer this style.
Again though, pure horses for courses - your mileage will vary greatly from mine or anyone elses.
Speaking as someone who's kind of morphed from C to C++ and now to C++ but with design patterns, I can honestly say that from personal experience, the way to go is to where possible, use the patterns and forget being a slave to the language.
Design patterns kind of work in any language, but in particular I've recognised a bunch of cases where I've seen inheritance used when a totally different setup should have been used (and a certain design pattern would have explained WHY).
The projectile one is the classic. Given the number of weapons and projectile types we had in worms, the inheritance model we used for it got REALLY nasty. Something like 120+ weapons etc.
Now I've seen the old school C + assembler version of the same code and that was function pointer table crazyness to look at, but simpler to comprehend than the inheritance version (because as Paul mentions, you dont have tons of hidden code).
What do you know, with the design pattern version of that same problem, you dont have the horrible looking code of the old school version OR the inheritance hiding problems of the second method. WIN!
So, learn C++ from a C coders perspective, but absolutely make sure you learn design patterns and use them. That way the C++ you learn actually works to your advantage instead of just making your code harder to follow.
www.mindflock.com - social AI-based games
Multimethods tend to help in these situations. Not possible to do in C++ though.
C or C++ doesn't matter too much...but is it a good time to learn C++ while doing your first game? I'd recommend getting the first one done, then see how things go after that. Porting C code (assuming well designed/written) is generally easier to port to C++ rather than the other way.
Jim.
Not much to add here except that I've written a ton of stuff over the years in C, it works and I can debug it. I've had experiences where myself and others have had to drill down to the bottom of C++ code and I've hated both the syntax and all of the things that make C++ more obscure in those cases. I never looked back on those experiences and felt that I fully understood what the code was doing and I don't see where any time was saved. So, for me, picking the parts of C++ that I like and coding like a caveman C programmer are the right choice.
Sounds like I should read up on design patterns after I wade through my pile of new books.
I picked up the book "Headfirst design patterns" from our library at work, its for java, but the patterns are pretty generic and cover more code architecture issues.
Thinking in patterns just helps you plan C++ code so that its not completely unreadable/unmaintainable.
I suppose I think of patterns as the kind of things people SHOULD get taught instead of all the C++ syntax crap. Thinking of how to architect code to be readable and maintainable is surely more important than making sure that you can write some nested template syntax or some such.
There's a site online that talks about the various design patterns (google design patterns and you should reach it), but I highly recommend getting a book on it, amazon will undoubtedly have a good un!
Anyone recommend a good patterns book?
From what I hear, steering clear of the "gang of four" book is a good thing.
Anyway, I'm not really bothered about languages so much, in that I couldnt give a naff about it if it gets the job done, other than its such a pain in the arse debugging some code especially when it gets all spaghetti and dependancy ridden (torque I'm looking at you
I could go on
www.mindflock.com - social AI-based games
I have had the Gof4 book since it was released. What's wrong with it (just asking).
Oh no, you're wearing a flame-resistant overall! Does this mean I have to be constructive? Nonetheless, please don't code in that way you describe. Anyone can use any facility to do horrible things. C++ can be a great tool to improve code readability and reusability, you don't have to use all features just because they're there, and more then that, you don't have to use them badly
Wow, so much hate, and the "sucks" keyword to boot... Well, you're supposed to program C++ as any other language, with restraint, judicially, elegantly. No-one has decided for you how to solve a problem or which problems can be solved. I consider myself an advanced programmer, and for me, C++ offers me the most complete tool chest. And I'm relatively certain most of you would enjoy reading my source code: patterned where appropriate without excesses, succinct without being terse, self-explanatory, logical and well-commented. Languages don't kill comprehension, people with languages kill comprehension.
Also, C++ and OO has let me decouple my game logic from my presentation, my engines are multiplatform even to the extent that I can transparently switch renderers etc on the same OS. Though possible, this is incredibly much harder i pure-C, VB etc.
Hairy, havent read the GOF book, but I heard its quite terse in style. I really dont like reading technical books that are that way myself.
I was really going off the various comments I've read round the net and on amazon's listing of the book.
www.mindflock.com - social AI-based games
There's a large, happy middle ground between "diamonds of death" and switching on type ids instead of using polymorphism.
Read Scott Meyers' books "Effective C++" and "More Effective C++" for some best practices. "Design Patterns" is also a good book re: OO design, and the examples are coded in C++. "Refactoring" by Fowler is very good one as well - the "Bad Smells in Code" chapter alone is worth the price of the book.
You can really get yourself in trouble if you don't know what you're doing with C++, but you can also write some very elegant and efficient code if you do. It takes some time and effort to learn how to use it the right way.
Last edited by MedievalElks; 08-27-2007 at 05:03 AM.
I agree. I am in the "use C++ to write C" camp. I like namespaces, default arguments, constructors. These are things that make my life easier. I don't use operator overloading, exceptions, STL. I use features in C++ that C could offer but doesn't.
Yes, absolutely. Just like in C, public interface goes into the header, implementation into the source file.
Posting Permissions