Level Editor Import Objects (Classes) - c++

i was working on making my own game tools in c++ to expand my knowledge on problem solving. But i was stuck thinking on the design of my level editor. I want to be able to import any header that by default will be assumed to contain one class and instantiate an object from it. Now i don't know how to allocate those custom classes on the scene as each class is considered different from the others so i can't use a vector to put them all there.
Now i wanted to know whether making a base class like EmptyGameObject and then making each class inherit from it will solve the problem.
But then i encountered another problem.
How do we construct a class depending on its name ?
like:
class name : CustomClass, imported from custom_class.h
thanks you for your help in advance.

Related

Circular dependencies and better ways to do it?

I really enjoy coding but currently every project I started has ended early due to the circular dependencies really messing with me and my head. I have been having problems, I am trying to make games, however due to my class structure I rely on some circular dependencies which cause problems in the end that almost always grow and go out of my control.
How I usually structure it:
class Game
class GameContext
class Window
class GameContext
class EventManager
class GameContext
class StateManager
class GameContext
I use this since I sometimes need to access for example the Window from the EventManager. In the end I always seem to lose it. Is there a better way for something like this that avoids circular dependencies? And if not how do you really go about thinking when you have to deal with them? I thought I understood them but clearly not.
What I am trying to archive is a centeral storage "Context" class which other classes could access but I do not know how to avoid circular dependencies in such a case.
To really show what I mean you can look at THIS, my latest failed atempt.
The problem I have with this current structure seems to be something to do with a dependency between the EventManager and the GameStateManager since in EventManager I get a error on GameStateID being undefined.
I managed to figure out my problem and it was more in the way of how I thought about it, I thought I wanted a structure like this:
class Game
class GameContext
class Window
class GameContext
class EventManager
class GameContext
But what I actually wanted was:
class Game
class Window
class EventManager
class GameContext
Where every every class except GameContext contains a pointer to a GameContext.
Also one of my problems was my understanding of forward declaration, I did not understand them and mixed and spread them everywhere because I thought it was magic.

How to see the analysis flow of cppdepend (eg. for base class should not use derivatives)

Im playing around with cppdepend,
and one thing bugs me:
It lists certain classes that violate "base class should not use derivatives". But I didnt figure out a way to see exactly where and how base class is using derivatives.
Can it be done?
BTW im using evaluation version on Win.
To check what methods used from base class ,the easy way is to select the base class concerned in the class browser,righ click and choose "Select Methods That I Use" , you will have also methods existing in derivative classes.

Mutual inclusion with singleton

I currently have a problem with mutual inclusion in a project of mine (C++).
Normally, if I had a mutual inclusion problem, I'd easily solve it by either forward declaration or redesigning the classes a bit. But this time, I'm stuck:
I have a class called Game, which creates and launches core game systems, where one of these is called GraphicsSystem.
In the Game constructor, a GraphicsSystem object is dynamically created and stored in a GraphicsSystem* pointer. Looks like this:
Game::Game ()
{
gfxSys = new GraphicsSystem(80, new Camera());
}
Now my GraphicsSystem class needs to access a Game class's method at one point to get the player object, which is stored within the Game object. The respective part looks like this (Game is btw a singleton!):
void GraphicsSystem::handleFrame ()
{
ElementList elements = Game::instance()->getPlayer()->getEnvironment()->getElements();
}
Now I tried forward declaration in both directions already, but that wouldn't satisfy the compiler. I could of course also just put the player pointer into the graphics system, but I really don't want to do that, since he doesn't belong there.
Is there any way to resolve this without me having to change the design too much? I'm really stumped right now, so I hope you guys can help me.
I'm using Visual Studio 2010 (Visual C++).
Thank you in advance!
Chris
Forward declare GraphicsSystem in Game.h. Include Game.h in GraphicsSystem.h if it needs it. Include Game.h and GraphicsSystem.h in Game.cpp. Include Game.h and GraphicsSystem.h in GraphicsSystem.cpp.
That should work based off the code you posted.
There are two main ways to break circular dependencies in C++.
1) Create a 'interface' class which lists the methods implemented by your real class and which your real class inherits from. Then you can include that instead of the declaration of the real class.
2) Pimpl - a class holds an opaque pointer to its real data, solving the problem of having to include declarations for the types of member variables.
I know this is going to sound dodgy, but have you considered holding a global reference to the initialized Game class?
I know globals are evil and so on and so forth, and I'm sure lots of people are going to rage, but in my personal experience I have succumb to Singletonitis with the Game class (among others) and found that sometimes it just simply isn't necessary.
The biggest question you need to ask yourself is "Who are you trying to protect your Game object from? and is there any reason why you need to request an instance each time you need the game class? I'm pretty sure that if your Game object wasn't initialized, you wouldn't be doing much else in your engine anyway.
Hope this might help you think about things in a different way, even though it's not answering your question directly.

Extend Class without changing its name

I have a situation: In a single Solution I have two Projects. I need to extend the Class:Foo used in Project:A so that I can add new functionality required in Project:B without changing its name. Problem is: Class:Foo already contains (i.e. has a) Class:Bar and is contained by Class:Goo in both Project:A & Project:B. In Project:B I am inheriting Class:Goo into Class:Goo_Ex; but I need to also extend both: Class:Foo and Class:Bar with companion functions.
To make it more clear - I could accomplish this using the following crude method:
/* Project:A-Class:Foo */
class Foo
{
.
.
.
# ifdef PROJECT_B
fnExtended();
# endif
};
but that would litter my code in Project:A.
A possible solution that I can think of is to use Inheritance and have Class:Foo_Global Inherited-[Only] as Class:Foo in Project:A and Inherited-[Extend] as, again, Class:Foo in Project:B; same for Class:Bar. But is their a more straight forward solution..?
I think your proposed solution (to hide the current Foo as some other class name and inherit from it in a new Foo class in both projects) is how you should do it.
This is a really abstract problem, and it's difficult to give you a good specific solution without more details.
The basic way of handling this is inheritance. But this requires some pre-planning. It means that when you refer to Foo in project A, you should use pointers or references. If you create a Foo (and need code from project A create Foo_Extended when it's part of project B) then you need to have a configurable Foo factory that will create objects of the appropriate type depending upon context.
The other way of handling this is templates. You never have the code in project A refer directly to the global Foo class. Instead it always refers to a template parameter. In project A that template parameter will end up resolving to Foo, and in project B it will resolve to some other class that has the needed functionality.
These are the two general ways of handling this issue in C++. And which you use depends a lot on the details of the context in which you're using them.
The way to extend you class is not to extend it! Just use a function taking suitable arguments instead.

Editing T4 poco template to implement custom interface

I am using the Poco generator with EF4 and I am wondering if it is possible to edit the T4 template to force all of my entity classes to implement a custom interface. Since the pocos get blown away and recreated each time the custom tool is run, I would have to add this upon each update - I would sure like to avoid that.
I realize I could create partial classes for each poco and implement the interface there, but I was hoping to avoid all that boilerplate code.
Any suggestions would be welcome.
I think I am getting closer to a solution. I am editing the tt template by adding the implemenatation to the signature that is generated.
<#=Accessibility.ForType(entity)#> <#=code.SpaceAfter(code.AbstractOption(entity))#>partial class <#=code.Escape(entity)#> : IEntity<#=code.StringBefore(" , ", code.Escape(entity.BaseType))#>
But I have hit a bit of a snag. Some of my entities have base classes (table inheritance) that I designated in the edmx design. I have need to force all the entities to implement an interface called IEntity. The IEntity contract has no methods so there really is nothing to implement. I will need to rely on all of the entities having a common base. This is due to a completely separate implementation of a custom validation framework. I am getting the proper signatures for most of the entities, however, the entities that already have a base class are throwing a wobbly because you cant implement an interface before you inherit a base class. :IEntity, BaseClass is not allowed. I need to swap those but am not sure how I would pull that off in the template.
On perusing the code in the CodeGenerationTools class that the T4 template uses (found in the include file EF.Utility.CS.ttinclude), I came across this function StringAfter(string value, string append). Therefore, the answer is quite simple, since you state all your entities have to implement IEntity, the following should do the trick:
<#=Accessibility.ForType(entity)#> <#=code.SpaceAfter(code.AbstractOption(entity))#>partial class <#=code.Escape(entity)#> : <#=code.StringAfter(code.Escape(entity.BaseType), "," )#> IEntity
In fact, I know it does because I've tested it :-)
After the T4 template is added to your application, it becomes part of your app and as any other part of the app, you can do whatever you want with it. If for some reason, you don't want to modify the VS added template, make a copy of it and update this to include only the interface implementation. The second way would produce another set of partial files with the custom interface being implemented.
Dont know if this is near what you need but....
I´ve created a Nuget Package that scaffold tiers from T4-templates.
There are default templates for all interfaces (Repository Pattern and UnitOfWork), but you can edit these templates yourself and re-scaffold your system.
To keep it short.. You just install the package (Install-Package CodePlanner) and then define your domainmodel.. And then run "Scaffold CodePlanner.ScaffoldAll"
Its open source (codeplanner.codeplex.com)
Demo: http://average-uffe.blogspot.com/2011/11/codeplanner-011-released-on-nuget-and.html
Edit: The codeplanner package is built for MVC3!
Regards
Uffe