Thread: Include Problems

I was going to type something up, but then I remembered this faq entry.

Hopefully that will help; if not, you might have to get more specific (i.e., give an example of the problem).

I think you want to use extern variables. Something like what I posted in this thread, perhaps.

I took my class design patterns from several sources, but the two primary sources have been Borland and Microsoft.

For Borland I really liked how they setup OWL or their Object Windows Library. However, I did not like their use of constructors as many of them had far too many parameters.

Enter Microsoft and MFC. MFC is awesome. Nearly every object has a parameterless constructor that really makes it simple to instantiate the object. None of their constructors allocate memory or do anything that has a possibility of failing.

I like this design philosophy and have used it. Nearly all of my constructors are parameterless and my destructors are responsible for cleaning up. Some of my classes have shutdown functions or cleanup functions when the object needs to clean up prior to the destructor being called. This also allows the programmer to understand exactly when the object is going out of scope because prior to deletion he must call Cleanup, Shutdown, or something like COM's Release(). I like this pattern a lot because you can directly control object lifetime. Destructors are awesome but sometimes their code, usage, and cleanup strategy are somewhat hidden in the class code which makes it difficult to understand. By calling cleanup or shutdown the programmer knows that he or she can then delete the object safely. Granted you can call delete and if the destructor cleans up correctly it will work, but I like seeing this in code.

Code:

CObject *Object=new CObject;
Object->Create(...);
Object->DoSomething();
Object->Cleanup();
delete Object;

You can certainly see exactly what is happening with Object.

Even if this object is created on the stack you can still see the progression:

Code:

CObject Object;
Object.Create(...);
Object.DoSomething();
Object.Cleanup()

Obviously the compiler will pop the object off the stack at the correct time in this example.
Either way you can see exactly what is happening.

Constructors cannot return anything and some people try to circumvent this by setting some magic variable in the class. A better method to use if you absolutely must allocate memory or use some resource in the constructor is the exception mechanism in C++. I'm not a big fan of throwing tons of exceptions everywhere but sometimes they are quite useful. Just don't overuse them and you won't have every object throwing this or that which actually adds to the confusion rather than aid in removing it. MFC does suffer somewhat from overusing the exception mechanism. What happens is that the compiler then traces back to the exception code but it is not always obvious as to what threw the exception from the code trace. MFC often throws the exception which leads to another section of code which obfuscates where the error is coming from. Luckily the MS debugger in MSVC 6, 2003 and 2005 is smart enough to lead you back to your code showing what caused the exception. You would have to get deep into MFC in order to understand what I'm talking about here. OWL also had this problem.

Instead of using several global objects you could use the following form:

Code:

class CApp
{
  //Stick your 'global' object pointers here
  //Init them in the Create() or Init() function of this class
};

Then use CApp as a global object. So you have one global object which is the application and nothing more. You can gain access to the other objects from CApp if the design provides this mechanism. When all of the objects are in CApp you have encapsulated the entire application and thus can safely instantiate it and it's members w/o requiring tons of calls from the programmer and you can shut it down or clean up with one call to Cleanup. Then you can either allow the compiler to clean the object off the stack or you can delete it if you created it on the heap.

I highly recommend buying a book on coding designs and patterns. Everyone uses different and unique patterns but there are some very good basic concrete principles that are invaluable to you as a programmer to learn and use.

You don't get good at writing C++ classes overnight. Often you learn from your own horrendous objects and then begin to widdle the problem down to very simple, very compact objects and use aggregation and/or inheritance to make the object much more manageable.

Don't use aggregation just because you hate inheritance.
Don't use inheritance just because it's uber C++.

Aggregation: Derived is part of Base.
Inheritance: Derived is a type of the Base.

Let me use a car as an example.

A car has:

1. Tires
2. Engine
3. Passengers

Aggregation: Cars have tires (or a car has a tire). Makes sense.
Inheritance: Cars are tires. (a car is a tire) What?

Aggregation: A car has an engine. True.
Inheritance: A car is an engine. Perhaps to some gearheads, but not in our case. This does not make sense.

Aggregation: A car has a passenger or has passengers. True.
Inheritance: A car is a passenger or a passenger is a car. Umm, no not usually.

Ok so we have base class Car:

Code:

class CCar
{
  protected:
    CTire *m_pTires;
    CEngine *m_pEngine;
    std::vector<CPassenger *> m_vPassengers;
};

Now we want a sports car.

Aggregation: A sports car has a car. Not on this planet.
Inheritance: A sports car is a car. Yes as a matter of fact it is.

Which leads us to this design decision:

Code:

class CSportsCar:public CCar {}

Hope this helps and isn't overkill.

Is a = inheritance
Has a = aggregation

Ok it goes like this, the Module class is basically a place for a 'chunk' of code to go. This could be any thing from a rendering process or intilizations or some thing or any thing, and returns the pointer to the next one.

Code:

 class Module
{
protected:
	bool Registered;
	
	friend class ModuleHandler; //the Module and ModuleHandler classes are now friends, yay!!!

protected:
	virtual void Initialize()=0;
	virtual Module* Execute()=0;
	virtual void Shutdown()=0;
};

The ModuleHandler is the class that manages all Modules, it loops through them, makes sure they are registered, delets them at the program end, ect. Module Handler is also the only way to acess a derived Module. NOTE: the shut down part is not in there yet.

Code:

class ModuleHandler
{
protected:
		vector<Module*> ModuleList;
		vector<Module*>::iterator ModuleListIterator;
		Module* CurrentModule; //holds the current module of use
	    Module* LastModule;	  //holds the last module of use
public:
	
	ModuleHandler(Module* FirstModule)
		{
			CurrentModule = FirstModule;
			LastModule = CurrentModule;
		}
	
	void RegisterModule(Module* module)
		{
			if(module->Registered != true) //if this is false, the module is already registered 
                                {
	             ModuleList.push_back(module);
                                module->Registered = true
                                }
		}
	
	void ModuleLoop()
		{
			if(CurrentModule != NULL && CurrentModule->Registered == true)
		{
		
		CurrentModule->Initialize();					//initialize module
		CurrentModule = CurrentModule->Execute();		//execute module
		
		if(CurrentModule != LastModule)					//true, we have switched modules
		{
			LastModule->Shutdown();
			LastModule = CurrentModule;
		}
	
		}
	
	  else
	  MessageBox(0, "Module Not Registered", 0, 0);
	  }	

};