Quote:Original post by deffer
Ok, in the end you would want to use only the managed resource, and remove the pure resource* from your game code. You might consider using boost::shared_ptr or boost::intrusive_ptr for that, as they are already written for this purpose and are written well.
If I'm reading you right, you mean that during every-frame usage of resources (like meshes for example) I will want to be using managed_resource objects to access the meshes, instead of using rmgr.get(string). This makes sense to me.
(Reading boost stuff...)
Quote:Sure:
managed_resource<factory> bar, foo;
bar = rmng.load("bar", "data/bar.jpg");
foo = rmng.load("foo", "data/foo.png");
and somewhere else:
foo = bar;
and at the end (releasing):
foo = 0;
bar = 0;
with all the ref-counting included all the time.
That's only a little off, the thing is that managed_resource is associated with the resource_manager at instantiation (ie, there is no default constructor, only a constructor that takes a reference to the manager, and either an std::string as a name, or a caretaker::locator to directly load the resource).
Your code would look more like this:
rmng.load("bar", "data/bar.jpg");rmng.load("foo", "data/foo.png");managed_resource foo("foo", rmng), bar("bar", rmng);
Elsewhere:
foo = bar; // I did implement this, surprisingly
Release is handled by the destructors of the managed resources. So there's no need for explicitly releasing anything. This isn't a problem, unless you destroy the manager before you destroy the last managed_resource that points to it.
What I was thinking was something more along these lines:
rmng.load("bar", "data/bar.jpg");managed_resource res;res = rmng.getHandle("bar");
Here, the return type of rmng.getHandle is a pointer to a resource handle that is contained by rmng, which includes a reciprocal pointer back to res. That way, res can be used sensibly, and if rmng is destroyed before res, the destructor of rmng will go and neuter res so it can't do any damage (it will just throw an exception when access is attempted).
The question is this: Is that preferable, to how it is now, where the manager throws an exception from its destructor if there are still managed_resources out there?
Quote:YAGNI ?
probably right. Maybe just one: a function that returns the locator of the resource at name.
Quote:Oh. Can you elaborate some more on this subject? How would you want to use this idea? Maybe a snippet of pseudocode?
Ok, so this whole project was born out of a need for a texture manager and a mesh manager, I didn't want to write two, when I couldn't see how the core manager functionality could change between them.
So lets say I have a file that contains a list of all the meshes I want to load:
Excerpt:data/my_mesh.3ds my_mesh name1 name2 ;data/your_mesh.3ds your_mesh ;data/our_mesh.3ds I don't share ;
So, it's pretty self explanatory, the first thing is the filename, and every word after them is a name for that resource, this can span multiple lines of course, because the list is terminated by a semicolon (;).
So here's the function I want to write for resource_manager:
void resource_manager::loadStream(std::istream & input){ caretaker::locator loc; std::string name; while(!input.eof()){ input >> loc; // requires that 'operator >> (istream&, caretaker::locator)' exists input >> name; while(name != ";"){ load(name, loc); input >> name; } }}
The problem is, that the locators for the textures include a description of what type of filtering to use. So that would have to be included in the extraction operator for those objects, and then the texture resource file would look like this:
Excerpt:data/textures/my_texture.tga TRI_LINEAR my_texture ;data/textures/font_texture.tga BI_LINEAR font ;
So I guess that that's ultimately in the hands of the person who implements the extraction operator for caretaker::locator, which is me anyway :D.
