Jump to content
  • Advertisement
Sign in to follow this  
choffstein

iterating through similar classes with std::list

This topic is 5133 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Alright. Here is the problem. I have a resource class, called CResource.
template <class resource> class CResource {
   private:
      std::string name;
      resource *data;
   ...
}
This allows me to register anything that is a class as a resource to my Resource Manager. My resource manager is simply three lists of CResources (std::list<CResource *>): the alive resources, the load que, and the dead resources. Now here is my problem: I have to be able to loop through these resource lists no matter what type of class the template is to be able to find certain resources by name. For example, if I want to load a texture class, I want to be able to loop through all three lists. However, within these lists there may be resources for mesh files, etc. So when I try to set my temporary CResource to the iterator so that I can check values, return it, etc...well, it wont work because they have different values. Does anyone have any ideas as to how this can be solved? I really want to keep my resource manager as "vague" as possible, so that anything that is a class can be considered a resource, and I am not stuck with lists of textures, meshes, etc. The only idea I have is that instead of using the template to create a set of data, instead use it to inherit from a class. So instead of the above code, I would use
template <class resource> class CResource : resource {
Would that work when I try to set my temporary CResource of one type to a CResource of a different type? Thanks for any help

Share this post


Link to post
Share on other sites
Advertisement
You derive all classes you want to be able to be stored from one base class and use std::list <BaseClassOfAllClasses *>. Then maybe with some RTTI cast them to their original type.

This solution may not be what you want and if you use RTTI it will also be slow. Slow especially if you use it as I think, you want to use it - list of sprites and others... Imagine dynamic_cast every frame for every sprite...

In my engine, I have a template class, which stores only objects of one type. So then I may use just Managed <Sprite> sprites; Managed <Whatever> whatevers;. I think, you should go this way. It's one class in fact. One templated one. You just have to create few instances to store whatever you want... I'm afraid that's nearest match of your idea [smile]

Oxyd

Share this post


Link to post
Share on other sites
I'd personally recommend going the inheritance route. Many of the functions wouldn't even need to be virtual, such as retrieving the name of the object. And even for virtual function calls, it's still just a simple vtable lookup. I [personally] think it would make your design much cleaner to use inheritence, and simply have a list for all types of resources, like you're wanting, rather than have a different list for each type. And I doubt that performance will be an issue. A vtable lookup is so minor compared to what is usually done after that lookup.

Share this post


Link to post
Share on other sites
Quote:
Original post by visage
Why dont you just say
Whatever whatevers
, instead of
Managed<Whatever> whatevers
? What is the purpose of the managed class?


Because, I'm stupid [smile]

The purpose of Managed class is managing my memory. It contains linked list of objects and when you ask it for some more (or less) memory (object count) it allocates the memory when it has time. It cooperates with TaskManager class, which assigns it some timespan, if the engine is running at, say, 400 FPS and you really only want 100 FPS (no point for running such fast) it gives some time to every instance of class Managed to preallocate some memory (or free some, if it has too much objects).

Basically, the only functionality I wanted to show you is it contains list of objects.

Maybe I should've said std::list <Whatever *> whatevers; as it would be less confusing. (Looks like, I forgot, you weren't familliar with my engine [smile])

I'm sorry for the confusion [smile]

@Agony: But Sprite class obviously does something totally different than, say, Texture class. And you store only Object *'s. Now - you want to get your hero texture. How do you dig it from the list? You have to take every object, and see wheter it is Texture type, if yes, dynamic_cast it and see, wheter it's the texture you want.

If you had two std::lists (std::list <Sprite *> sprites; std::list <Texture *> textures;) you just iterate thought the textures list and look at what it contains.

Of course having list of textures and searching for some concrete texture is probably stupid example, but I couldn't think of anything better [smile]

Oxyd

Share this post


Link to post
Share on other sites
If you need to search for resources by name, though, and if all resources have a name, then you shouldn't care about checking each one to see if it is a texture or a mesh or whatnot. Just check the name. If the name is the same, then just for safety's sake you might check to make sure it is of the type you're wanting. But you don't need to check every single item's type. Since the resource name's accessor shouldn't be virtual anyway, I don't see how inheritance will cause any slowdown. I could be missing something, though...

Share this post


Link to post
Share on other sites
If I were you I would create a base class containing the functions that all resources have in common:

class IResource {
public:
virtual void getName()=0;
...
};

And then create a templated class like this:

template <class resourceType> class CResource {
private:
std::string name;
resourceType *data;

public:
void getName() {
return name;
}
...
};




Quote:

You derive all classes you want to be able to be stored from one base class and use std::list <BaseClassOfAllClasses *>. Then maybe with some RTTI cast them to their original type.

Why would he want to cast them back to there original type when it makes much more sense to use virtual functions and a base class.

Share this post


Link to post
Share on other sites
Quote:

Quote:

You derive all classes you want to be able to be stored from one base class and use std::list <BaseClassOfAllClasses *>. Then maybe with some RTTI cast them to their original type.

Why would he want to cast them back to there original type when it makes much more sense to use virtual functions and a base class.


So you want to say, the base class would contain all interfaces of all classes? Say - you have Mesh class wich has load method. Then you have Sprite class which has no load method, but has render method. Thus the base class would have to have both load and render methods, if you want to prevent casting to original type.

Imagine you have 20 totally different classes and one super class, which contains all the interfaces...

Oxyd

Share this post


Link to post
Share on other sites
Quote:

So you want to say, the base class would contain all interfaces of all classes? Say - you have Mesh class wich has load method. Then you have Sprite class which has no load method, but has render method. Thus the base class would have to have both load and render methods, if you want to prevent casting to original type.

A sprite isn't the same type of object as a mesh, so therefore they don't belong together. You should group the objects into hierarchies that make sense. In this example, the mesh object shouldn't be stored in the same container as the sprite.

*sigh*

I'm not very good at explaining things, so I really don't know how to explain it any more. Just design it how you think you should; you'll eventually get what I'm talking about :/

Share this post


Link to post
Share on other sites
I think, you just said you mean the same as me [smile]

Have a std::list for sprites, then std::list for meshes, right?

This is what I meant [smile]. Obviously none of us is good at explaining things [smile]

Oxyd

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!