More resource management troubles

I've refined my resource management system to use the factory pattern. In the design I opted not to use the templated factory pattern and instead am using the parameterized creation pattern.

Current design:

CResource - base class for all resources - resource classes derive from this class to extend resource functionality
CResMgr - resource manager class - maintains a cache of most recently used resources
ResCreator - creation class for all resources - no resources that can be added to the cache can be instantiated outside of this class
Resources are indentified in the cache via a random ID

There are several problems popping up and I'm not sure of an elegant way to solve them

If resources are identified by their ID and their ID is assigned at run-time, how do I account for objects that use the same texture? In the current system the duplicate textures would be assigned unique IDs and would occupy two locations in the cache. Since the IDs are assigned at run-time, a mesh object cannot know the ID of its associated texture and thus cannot know if its texture is already in the cache.
The only way to account for user created resources is to override the create function in a class derived from ResCreator.
The parameterized solution resolves to a switch inside of ResCreator::Create() and ResCreator::CreateFromFile().
Since ResCreator must be able to create all resources yet all resources must only be created from within ResCreator, ResCreator then must be friends of the CResource derived classes. I'm not a huge fan of friend classes but could not figure out another way to do this.

The first problem could be solved using strings or multiple IDs but I would lose the efficiency of a std::map. Since resources are located by their engine-assigned ID and not by their actual resource ID, attempting to find out if a resource existed in the cache or not would be quite slow.

Non-negotiables

Resources must have a centralized way of being created, destroyed, and added/removed to/from the cache.
The cache must maintain most recently requested resources
The cache must maintain the requested size, or very close to it.
The cache absolutely can never exceed the maximum size.
Identical resources should resolve to the same ID.

To illustrate here is an in-engine example. There is a mesh A that uses texture A that needs to be rendered and/or updated. Since this mesh uses texture A both the A mesh data and the A texture will be in the cache since the mesh class will request these from the cache. If they are not in the cache they will be created and added by the creator class. If another mesh B uses texture A it should ideally use the same texture as mesh A. It will NOT use the same mesh data since this causes a multitude of other issues.

Any suggestions?

How are resources identified in the original Create/CreateFromFile?

Regarding problem 4, that's exactly what friends are for. I wouldn't worry about it.

However, regarding problem 2, a creator function registration by resource type ID might be a more extensible solution. In that case, it would be the creator function that needs constructor access.

Quote:

If resources are identified by their ID and their ID is assigned at run-time, how do I account for objects that use the same texture? In the current system the duplicate textures would be assigned unique IDs and would occupy two locations in the cache. Since the IDs are assigned at run-time, a mesh object cannot know the ID of its associated texture and thus cannot know if its texture is already in the cache.

Generate the ID's based on the resource identifier (hash code). Then you don't have to deal with strings and you have unique integer IDs.

Generate a hash from the resource identifier...

I like it. No strings.

Why do we all hate using strings as identifiers? I don't know why but I despise using them this way and it seems most of us here agree.

It's slow. When you do lookup using strings, you need to do string comparison, which is O(len(s)).