Good/Generic C++ Programming

Oh yeah, I should also mention that I learn quickly from example... so if you know of any code fragments (or entire open source projects) that demonstrate a good usage of C++ that would wonderful! Thanks.

ok before i say anything id like to point out that im in a similar situation and that im still not very confident in the whole design area, hence, what i say may be complete crap.

But with that considered heres what i came up with for the whole TextureManager thing in my current project.

TextureManager


ResourceManager


Anyway i hope thats of somehelp, if theres any errors sorry i wrote the code on the fly, but as i said i dont have much experience at the whole design thing so that may be absolute crap.

Quote:

Original post by swinchen Hello all, For the impatient here are the questions: I recently bought Design Patterns by the gang of four, and was just wondering what patterns I should pay close attention to in game programming? Are there patterns that show up in game development that are no listed? Are there certain patterns that I should try to avoid? What references do you suggest for C++ design, including advanced C++ usage such a template meta programming? What references do you suggest for good STL usage?

For template metaprogramming, I'd suggest "Modern C++ Design" by Andrei Alexandrescu. It's a reference.

About the patter, you shouldpay a close attention to all of them, but you might also want to read different opinion about some controversial patterns (for example, the visitor and the dreaded singleton pattern). At the beginning, you should even try to avoid the singleton pattern as it has a lot of drawbacks and is probably one of the most difficult pattern out there - it's apparent simplicity hides the fact that it is terribly difficult to use.

Quote:

Now for a little back ground: I am fairly comfortable with C++ syntax, and I have some decent reference material for when I get stuck. Admittedly my STL knowledge is quite limited...

You should definitely learn more about the standard C++ library - not only the containers, but the algorithm, the header and the stream library - because (a) it is part of the language itself (b) It Will Help You.

Quote:

but I feel like I have a decent grasp on the language. I have quickly learned that knowing the syntax does know make you effective at using the language. A good analogy would be this: I have spent a lot of time learning to use individual tools from a work shop... hammers, saws, drills, etc. And I am comfortable with each tool. Now I am dropped in the middle of a construction site and am told I should build a house. I do not know how to effectively use the tools to form a final product.

That's a pretty good analogy [smile] I'll reuse it (providing that its interface is clear enough, and that it does not come with additional dependencies).

Quote:

In C++ here is what I am trying to do: I am trying to design a CTextureManager... I am sure that if I could figure out generic programming it would be a CResourceManager. Each image can have multiple textures and I am trying to find a good way to store, search, describe the texture system. I am not sure I explained this real well, but it is the fuel for this entire post. If you have any insight, it would be greatly appreciated! Thanks!

A texture manager is not a resource manager. The goal of these entities are very different - not to mention that a resource manager does a lot more than a texture manager. They are separate entities (think: their behavior are different; to subtype a type, you'll want to make sure that their behavior is identical from a caller point of view. That makes core reuse inheritance unaccaptable, so you'll want to use the composition pattern instead, like Julian90 did (r++ BTW)).

Regards,

Quote:

Original post by swinchen I recently bought Design Patterns by the gang of four

well-spent money.

Quote:

and was just wondering what patterns I should pay close attention to in game programming?

Factory, Command, Template, State

A good grasp of eventing is also recommended, though it is not considered a design pattern iirc.

Quote:

Are there certain patterns that I should try to avoid?

Singleton

Quote:

I have quickly learned that knowing the syntax does know make you effective at using the language. A good analogy would be this:

You are a wise man. Nice analogy!

Quote:

Original post by Emmanuel Deloget For template metaprogramming, I'd suggest "Modern C++ Design" by Andrei Alexandrescu. It's a reference.

Better add C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond after because Andrei's book is slighly dated and lacks some other useful techniques as well as how one reduces compile-times and code bloat when doing template metaprogramming.

In my current project i use the singleton pattern quite extensivly.
All my managers use it, because i need references to them in all sorts of places in my code.



The convinience of singletons is, that you include the header-file of the manager to use and get it with a call to e.g. OVRenderer::getSingleton() anywhere in your code, without passing or storing a pointer or reference to the manager.

Another example:
My design of shaders (in my context shaders are material descriptions like in offline renderers) allow to implement their own rendering loop and therefore i need a reference to my renderinterface and hence i would need to pass a reference or pointer as an argument to the shader constructor. With singletons i can skip this step.


In my current state of knowledge the benefits of singletons outweigh their restrictions.
I am just starting programming and i know that i know nothing and therefore i would like to hear some opinions of why to avoid singleton patterns ;)


For some interested in the usage and implementation of singletons:
(currently using Linux, gcc4.03)

Full credit goes to the guys of the Ogre3D project http://www.ogre3d.org

Header of OVGeometryManager


Body of OVGeometryManager


Header of OVSingleton

Quote:

Original post by hoLogramm In my current project i use the singleton pattern quite extensivly. All my managers use it, because i need references to them in all sorts of places in my code.

If you do, you have a serious design problem. Refactor.
"All sorts of places" should not need access to these things.

Quote:

The convinience of singletons is, that you include the header-file of the manager to use and get it with a call to e.g. OVRenderer::getSingleton() anywhere in your code, without passing or storing a pointer or reference to the manager.

The convenience of robbing a bank is that I get a lot of money here and now. That doesn't make it a good long-term strategy. [wink]

Quote:

My design of shaders (in my context shaders are material descriptions like in offline renderers) allow to implement their own rendering loop and therefore i need a reference to my renderinterface and hence i would need to pass a reference or pointer as an argument to the shader constructor. With singletons i can skip this step.

Yes, but why is it a good thing to skip that step?

Quote:

I am just starting programming and i know that i know nothing and therefore i would like to hear some opinions of why to avoid singleton patterns ;)

Basically because even though they're convenient, they make a mess of your code. You said it yourself. All sorts of places in your code need access to various managers. That shouldn't be the case, but it happens very easily when you use singletons. Normally, you try to *avoid* globals, because then you can control how and when resources are accessed, you can refactor much more easily, and you can actually *see* which resources are required for any given function, because it doesn't pull in random global variables.

That's the short version... I'm sure others will be happy to provide the long, advanced explanation [grin]

Quote:

Original post by hoLogramm In my current project i use the singleton pattern quite extensivly. All my managers use it, because i need references to them in all sorts of places in my code.

Frankly, you shouldn't. You transformed the singleton pattern in a OOified global, which is not its goal at all. At this step, you should read Washu's Singletonitis articles (my journal has the links to the top; You can also go directly to Washu's journal - the 3 parts of the article were written in April).

Quote:

Original post by hoLogramm The convinience of singletons is, that you include the header-file of the manager to use and get it with a call to e.g. OVRenderer::getSingleton() anywhere in your code, without passing or storing a pointer or reference to the manager.

But in this case, there's a huge drawback to the convenience: all your code is now dependant upon your OVrenderer, which is no longer used locally. I can think of two reason about this
1) your OVrenderer class is a god class, meaning that it probably violate the single responsability principle.
2) the OVrenderer class is used locally (in in a limited subset of classes) but the classes that are using it are deeply trenched in the code (either because of a deep class hierarchy or because of an overmisuse of the composition pattern). Such code smells, but it's going to be harder to see where the real problem lies without studying it (to get a proper feeling about this strange smell thing, here are some code smell metrics to help you).

Quote:

Another example: My design of shaders (in my context shaders are material descriptions like in offline renderers) allow to implement their own rendering loop and therefore i need a reference to my renderinterface and hence i would need to pass a reference or pointer as an argument to the shader constructor. With singletons i can skip this step.

Just tell me that you don't use a singleton just to bypass this step [grin]. More seriously, your statement tells me that you are probably in case 1 above. Your renderer seems to do papa and mama, and you should consider a refactor based on the different responsabilities that your renderer is currently handling.
Here are, for instance, the methods of my own renderer (DX based):

class renderer{public:  // ctor and dtor - can't do much without them  bool tie_resource(resource *res);  void clear();  bool begin_scene();  void end_scene();    // there are multiple overloads of the draw method.  // none of them takes a resource object as a parameter  // resources are bound to the device using resource_type::bind()  // where resource_type inherits resource (resource does not define  // a bind() methods, since my resources are heavily generalized and  // not all of them are bindable. I may explain this later, when I'll  // get more free time.   bool draw(/* params */);};

Needless to say, my neither my resources nor anything depends on this renderer class.

As you can see, the sole responsability is to handle the draw operations. Setup and state are handled outside the renderer - remember that the fact that the renderer references a IDirect3DDevice9 instance does not mean that no other object can reference the same instance.

I forgot some methods, but none of them are very important wrt the design.

The only exception are these xxx_resource() functions. tie_resource() ties a particular resource with this renderer and allow its creation in the context of this renderer (in return, tie_resource() calls a private virtual method of resource).

Quote:

In my current state of knowledge the benefits of singletons outweigh their restrictions. I am just starting programming and i know that i know nothing and therefore i would like to hear some opinions of why to avoid singleton patterns ;)

That's one of the reason why there are people here that tries to give you meaningfull information about different pattern and techniques - to help you to see the pro and cons of these patterns/techniques (ie. see Wahsu's articles [smile])

Quote:

For some interested in the usage and implementation of singletons: (currently using Linux, gcc4.03) Full credit goes to the guys of the Ogre3D project http://www.ogre3d.org

Yeeeeeks!

I had an heart attack [smile].

The Ogre singleton is probably the worst kind of C++ singleton you'll find out there. One reason lies in the way it is created: the user have to create it manually. Another reason lies in the fact that C++ enables you to create a singleton whose uniqueness is enforced at compile time (reducing the risk of errors), while the uniqueness of the Ogre singleton is enforced at run time (meaning that you'll have to handle error cases by yourself, resulting in potentially clumsy code). Another reason lies in the fact that:

OVSingleton<OVRenderer> *renderer2 = new OVSingleton<OVRenderer>(OVRenderer::getSingleton());

will create another instance of your singleton - woops. The use of the copy constructor (automatically generated by the compiler if you don't provide it) kills everything.

I provide a safer singleton in my journal. You might want to use that instead (at least, you'll get rid of some of the problems of the Ogre "singleton" (I'm not even sure they should call that... thing a singleton [wink])

I don't say that singletons are bad. Their problem is that they appear to be very easy to use, but most of the time they are badly abused.

I am really sorry swinchen to take over your thread topic, but since it is about design patterns i am very interested in it :)

To Emmanuel Deloget:
Your post slipped in while i wrote this one.
Very big thanks of your resources and thoughts. ;) ++rating
I explained my renderer a little bit further down in this reply but it looks as if we have the same design. (creating-un/binding resources, render(), postRender(), renderGeometry(), ...)
I am very interested in your singleton implementation. I'll check you journal now regularly. :)

Quote:

Original post by Spoonbender Quote: My design of shaders (in my context shaders are material descriptions like in offline renderers) allow to implement their own rendering loop and therefore i need a reference to my renderinterface and hence i would need to pass a reference or pointer as an argument to the shader constructor. With singletons i can skip this step. Yes, but why is it a good thing to skip that step?

Well if i did not use singletons, i would have additional parameters in my constructors and forward declarations and pointers in my header files for every manager i am going to use. With singletons i have the header of my manager included in my cpp and nothing else. I hope i explained why in my point of view it is a good step to skip this part.

Quote:

Original post by Spoonbender Quote: I am just starting programming and i know that i know nothing and therefore i would like to hear some opinions of why to avoid singleton patterns ;) Basically because even though they're convenient, they make a mess of your code. You said it yourself. All sorts of places in your code need access to various managers. That shouldn't be the case, but it happens very easily when you use singletons. Normally, you try to *avoid* globals, because then you can control how and when resources are accessed, you can refactor much more easily, and you can actually *see* which resources are required for any given function, because it doesn't pull in random global variables. That's the short version... I'm sure others will be happy to provide the long, advanced explanation [grin]

Thanks for the explanation ;)
I am going to look for the long story ;)


I see this is going about design philosophies.
My own is that the application tells the renderer what scene it should render, the renderer then goes through all shaders and tells them to render themselves. The shader uses the renderer then to bind states, textures, framebuffer objects,... An easy task, because the shader knows all objects, which it is attached to (in a prestep the scene gathers all shaders it should use according to all visible objects and stores pointers to those in the shader directly) and i don't have to sort them by their textures, materials, hardware shaders, ... So the renderer delegates instead of fiddeling around with multiple pass-, multiple viewport rendering and different techniques (like using hardware shaders or the fixed function pipeline and so on ... it only binds and unbinds them).
In addition all objects have their own render function, so they know how to setup themselves.


For the global thing i did not quite get it, but the long story surely will help me to understand it.
With *all sorts of places* i meant where they are _needed and nowhere else_, since they are included only in .cpp's.
And a superior benefit of the singleton implementation over pointers is, that they can't be changed and ensure, that there only will be one instance of a certain type of e.g. manager around.
As long as no one named "Emmanuel Deloget" comes around and plays with the copy constructor. :D

[Edited by - hoLogramm on December 19, 2006 8:54:25 AM]

Thanks all for the tips! r++ to all those who helped :)

To add to the analogy, with the knowledge of design patterns (small snippets of the blueprint) and knowing the basics of C++ syntax (tools), I should be able to go to the construction site and build stairs, a roof, the front porch, some walls, etc.

So seeing that I don't know the difference between a TextureManager and a ResourceManager it appears as though I don't really know what "stairs" and "walls" are so it would be impossible to take those components and build a "house." So I guess I need to ask what a good way to learn the major players are in a game-oriented framework? I think having a fundamental understanding of the components would make it much much easier to design and use them :)

Thanks for the book suggestions, I might put in a book pool order soon. Any suggestions for a good STL book/website? I have effective STL by Scott Myers, but I think I need a good introduction first because a lot of the stuff he goes over seems more advanced.

Directed to Julian90, or any who can answer:
Thanks for the code snippet, I have a couple of quick questions...
1) template::Resource>
class Texture = Texture <--- what is going on here? I haven't seen this before... is Texture also a class you have defined somewhere?

2) typedef Texture Texture; <--- I think I understand this... it just looks strange. You are doing this so that you can always use "Texture" as a type, even if change it from something other than "Texture"?

As always thanks for the help, this seems like a very interesting topic to me and I look forward to the learning process.

Quote:

Original post by hoLogramm Quote: Original post by Spoonbender Yes, but why is it a good thing to skip that step? Well if i did not use singletons, i would have additional parameters in my constructors

Yep. And that's usually a good thing. It forces you to think about your dependencies, to consider whether you *really* need access to everything just here. And it makes it possible, later on, to *see* what the code needs access to, because it's right there in the constructor. Yes, it's a bit of extra work initially, but that's unfortunately often true for good practices... [wink]

Quote:

As long as no one named "Emmanuel Deloget" comes around and plays with the copy constructor. :D

Well, what makes you think that won't happen? [wink]

Emmanuel I agree with everything in your post besides the below quoted text.

Quote:

Original post by Emmanuel Deloget Quote: Original post by hoLogramm In my current project i use the singleton pattern quite extensivly. All my managers use it, because i need references to them in all sorts of places in my code. Frankly, you shouldn't. You transformed the singleton pattern in a OOified global, which is not its goal at all...

From GOF about the intent of a singleton

Quote:

Ensure a class only has one instance, and provide a global point of access to it.

edit
but I do not wish to turn this into another singleton war.

Quote:

Original post by swinchen Any suggestions for a good STL book/website?

I learned the majority of c++ from this book and it is my standard reference too:
The C++ Programming Language by Bjarne Stroustrup
... if you don't already have it. It has many code samples in it.
http://www.cppreference.com
... i use it as my stl reference and has to every topic code samples too.

Quote:

Original post by Spoonbender Quote: As long as no one named "Emmanuel Deloget" comes around and plays with the copy constructor. :D Well, what makes you think that won't happen? [wink]

...common sense and lazyness of the user. ;)
If the managers are already provided for the user, i doubt someone does this kind of thing.

I could be wrong in this point and this is only a question, but even if the user instantiates a new renderer, would the OVRenderer::getSingleton() return the reference of the last instantiated renderer?
If yes, every part of the engine would use the newly instantiated renderer and resources and that would be fine for me, since the renderer works as intended.
If not, well then i have two renderers all sharing the same resources which would also be fine. :)
... and if not, and the user instantiates a geometrymanager and a renderer, then the renderer has no data to work with, but that would be the case with pointers/references too.

Quote:

Original post by dmail Emmanuel I agree with everything in your post besides the below quoted text. Quote: Original post by Emmanuel Deloget Quote: Original post by hoLogramm In my current project i use the singleton pattern quite extensivly. All my managers use it, because i need references to them in all sorts of places in my code. Frankly, you shouldn't. You transformed the singleton pattern in a OOified global, which is not its goal at all... From GOF about the intent of a singleton Quote: Ensure a class only has one instance, and provide a global point of access to it.

By considering the singleton as a global variable, you essentially forget half of its definition. Most of the code that use singletons are using it as a global variable (adding this uniqueness feature more for coolness than for anything else). I happen to think that hoLogramm uses it in this way (no offense intended, of course). The reason why I think this is that having tons of singletons that are used everywhere is a typical symptom of such a use.

Washu makes this clearer so I direct you to his journal and his 3 part singletonitis article: part 1, part 2, part 3.

Quote:

Original post by dmail edit but I do not wish to turn this into another singleton war.

Be sure I will take care [smile]

Regards,

Quote:

1) template::Resource> class Texture = Texture <--- what is going on here? I haven't seen this before... is Texture also a class you have defined somewhere?

yep the second Texture in class Texture = Texture is a Texture class that youve written somewhere. Basically its saying we have a template parameter Texture with a default value of ::Texture (for convenience and so that we can easilly change it latter on or for testing, i.e. use a dud class that does nothing to test TextureManager)

Quote:

2) typedef Texture Texture; <--- I think I understand this... it just looks strange. You are doing this so that you can always use "Texture" as a type, even if change it from something other than "Texture"?

Sort of Texture(1) is the template paramater Texture which will always be a type the main purpose of the typedef however is so we can say TextureManager::Texture elsewhere in our code.

for example consider the following two code snippets

typedef TextureManager<MyTextureClass> MyTextureManager;// ...MyTextureManager texManager;MyTextureClass::SmrtPtr tex1 = texManager.GetTexture(texManager.GetTextureID("Explosion"));// 500 lines of code all using MyTextureClass

and this

typedef TextureManager<MyTextureClass> MyTextureManager;// ...MyTextureManager texManager;MyTextureManager::Texture::SmrtPtr tex1 = texManager.GetTexture(texManager.GetTextureID("Explosion"));// 500 lines of code all using MyTextureManager::Texture

And now say i decide i want to use MyOtherTextureClass instead of MyTextureClass which one do you think will be easier to change, the first snippet or the second?

Edit: fixed extra ;'s and nameclash in typedef

Quote:

Original post by hoLogramm Quote: Original post by Spoonbender Quote: As long as no one named "Emmanuel Deloget" comes around and plays with the copy constructor. :D Well, what makes you think that won't happen? [wink] ...common sense and lazyness of the user. ;) If the managers are already provided for the user, i doubt someone does this kind of thing.

Whenever you add a possible problem in your software, be sure that someone will abuse it and transform it into a bug [smile].

Quote:

I could be wrong in this point and this is only a question, but even if the user instantiates a new renderer, would the OVRenderer::getSingleton() return the reference of the last instantiated renderer? If yes, every part of the engine would use the newly instantiated renderer and resources and that would be fine for me, since the renderer works as intended. If not, well then i have two renderers all sharing the same resources which would also be fine. :)

Not in your case, because the compiler will provide a trivial copy constructor that will make a deep copy. however, static members are not considered during the deep copy, the static pointer will still point to the first allocated singleton.
You can also write my line of code in another way:

OVsingleton<OVRenderer> renderer2(OVrenderer::getSingleton());

In this case, it is even worse. What will happen when renderer2 will go out of scope? (I know: I'm evil).

Quote:

... and if not, and the user instantiates a geometrymanager and a renderer, then the renderer has no data to work with, but that would be the case with pointers/references too.

Your code may not break, but what about his code? When you create a library, you are also responsible for some of the error of the library client. You must make sure that most of the silly things he want to do are not possible - otherwise he will do it, and he will blame you. Clients are like this [smile]

I read Washu's journal and i agree, that i am a lazy person, who used singletons, just to have global access to them so i wouldn't have to pass pointers around.

What distracted me, was the reply from Ysaneya:

Quote:

Original post by Ysaneya I'm cured from Singletons. Especially since i discovered the hard way (at work) that Singletons caused some problems in the long term. To be more precise, like many people, i started an engine, thinking "hell, i'll never need more than one renderer. Let's make a Singleton". One hundred thousand lines later, a customer wants support for workstations with multiple graphics cards. Suddenly, i need many renderers, and my code is not designed for it. Lots of effort and countless hours/bugs to fix it. That was a few years ago. Since then, i never, ever, ever use Singletons. Actually i'd be surprized if there's even one of them in my code. I tell you, Singletons are the Devil. There will always be cases where your Unique instance no longer needs to be unique. Y.

The main and only true reason imo to avoid singletons is, that you can never say, that something has to be unique once and for all. Tomorrow the world looks different.

*sigh* I think the purpose of this post has gotten greatly distorted.

As i see it, this thread is about design patterns which are good and bad and we got the singleton one extensively covered.
If you have more questions just post them, we'll be happy to answer them.