Thread: Structuring .cpp's and .h's

  1. #16
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    I'm not even going to get into 'how you should layout your source code' because my stuff has tons of functionality laid out in a completely disorganized mess.

    I will say, however, that I want to psycopathically murder the inventors of the C++ programming language.

    In certain terms I wholeheartedly agree. C++ is often deemed as a higher language than C yet the more you use it the more you realize that it can be higher, as long as you are willing to write the low-level base classes and functionality in a way as to be usable and efficient.

    A lot of times my code gets to be a huge mess and so I feel your pain Bob. C++ is awesome but man it's also so friggin annoying.

  2. #17
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    >> In the case of Singletons, I prefer using namespaces.

    I don't understand your reasoning for that.
    Namespaces are a way to, well, name a space. As far as I'm concerned they are not part of OOP; they're not something you really use in a design unless you know you're going to be colliding names with the STL or another library.

    How the hell do they function as a Singleton? I guess you could have a global (namespace level) variable and a function to work it like a singleton but then it's just a whole bunch of C-esque clobber wrapped in a name.
    Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.

    - Mike McShaffry

  3. #18
    Registered User
    Join Date
    May 2006
    namespace Whatever {
        /* typenames and function declarations */
        /* here you can have globals */
    You might not like this because it is not OOP but this is still a good replacement solution. I'll translate a passage of my French version of Bjarne Stroustrup's The C++ Language about namespaces.

    "A namespace is a mechanism allowing one to make logical groupments. That is if some declarations can be associated following some criterions." (p.188 ch. 8.2)

  4. #19

    Join Date
    May 2005
    You know, a class is also, technically, a namespace. The only difference between a namespace defined using the namespace keyword and a singleton class is that at least with a singleton class you have an object that you can use to communicate through other constructs of your engine (e.g. if you do ultimately have a very OOP design...I don't like OOP designs but it also may help people understand their layout's sort of a personal choice if you're an amateur programmer).
    I'm not immature, I'm refined in the opposite direction.

  5. #20
    Registered User
    Join Date
    May 2006
    My point is that you do not need to go all-OOP.

  6. #21

    Join Date
    May 2005
    I keep things pathologically simple...the simplest design that works is always my path of choice. I choose ugliness and simplicity, with only very very basic object oriented constructs. Granted, everything I do is object oriented, but only in nature (it would make just as much sense if everything I am showing you was just a bunch of functions in .h and .cpp files).

    So, lets look at a few of my classes, I've got a few biggies:

    -texture manager

    and a few others which I won't post. Collectively, these classes make up the data and functionality which make up the engine. None of these are singleton classes, I could technically create more than one instance of each, but I don't (no need).

    In my main module, I create these objects, globally. Through them you can access and manipulate data. When I want to access these objects, I either use the extern keyword and/or pass them into a helper function as a parameter (Yes, I know, a lot of this is particularly inefficient and slow, e.g. accessing global variables, esp through pointers, is probably the most inefficient computationally speaking).

    This is at the top of my main module:
    //All of the main game engine variables
    GLRenderer	*gpGLRenderer			=	new	GLRenderer(50000,50000);
    TextureManager	*gpTextureManager	=	new	TextureManager;
    FPS_t		*gpFPS					=	new	FPS_t;
    Frustum		*gpFrustum				=	new	Frustum;
    BSP			*gpBSP;//		=	new	BSP;	
    TextManager *gpTextManager			=	new	TextManager(500);
    PhysicsManager	*gpPhysicsManager	=	new	PhysicsManager(100.0f, 5.0f ,METER(5.0f));
    Here's how a hovertank accesses the engine functionality to be able to render itself (adding a ms3d model to the renderer, along with some debug stuff, on top of doing a frustum test):

    #include	"Hovertank.h"
    #include	"GLRenderer.h"
    #include	"Quake3BSP.h"
    #include	"Frustum.h"
    #include	"TextManager.h"
    #include	"PhysicsManager.h"
    #include	"FPS.h"
    #include	"GameExport.h"
    extern	GameExport		Export;
    extern	BSP				*gpBSP;
    extern	GLRenderer		*gpGLRenderer;
    extern	Frustum			*gpFrustum;
    extern	TextManager		*gpTextManager;
    extern	PhysicsManager	*gpPhysicsManager;
    extern	FPS_t			*gpFPS;
    void	Hovertank::Render()
    		Matrix4x4	final_render_mat;
    		final_render_mat	=	CurrentState.mMat_Orientation;
    That's the design I use...brute and ugly but ultimately very useful and reusable, easy to design and maintain, etc. I started my design where *everything* required for the engine was in a single interface, but because of that build times went through the roof (change one thing that uses the engine or is the engine functionality to itself and nearly everything in the project is completely rebuilt, whereas with this I can create a palette of the functionality I need).

    Last edited by BobMcGee123; 06-05-2006 at 10:13 AM.
    I'm not immature, I'm refined in the opposite direction.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. linking .c's and .h's in a project file
    By dezz101 in forum C Programming
    Replies: 6
    Last Post: 09-12-2008, 08:02 AM