When designing around a policy system an important step is decomposing the operations the thing you are designing does so you can seperate it out.
So, lets look at a texture manager and see what we can decompose it down to, operations wise.
Image loading
The act of moving the image information from its medium to memory. The word 'medium' is key here, as the data could be coming from any where, the manager doesn't care where it comes from just that it can be loaded some how.
Image data passing to API
Once loaded the image data needs to be transported to the image API of choice. For OpenGL and D3D this would involve uploading the texture data and getting back a handle to it some how.
Texture storage
This is how we map the incoming data's path to the texture object returned from the previous step allowing us to perform lookups.
Freeing of the texture data
This controls how and when textures are free'd up for reuse.
Returning a texture object
Of course, the caller requires a texture handle of some sort from the callee.
The problem comes from the policies needing to know about each other to some degree, if not their process directly but the types involved.
For example, the Image data passing to API needs to know what Image loading returns so it can extract the information from it and pass it to the API in question.
There are ways around it, for example, we could mandate that your Image loading policy exposes a method which can return a char * to the data so it can be passed to the underlaying API as well as extract other information if needed. However this doesn't feel overly gracefull, for example if you just returned a simple struct with the data in then the rest is overkill, however not doing so means that your Image data passing to API policy needs to know something about the data you'll be passing it.
The problem kinda gets worse when it comes to the texture object. If this is a user provided then it has to be able to know what the type returned from the API uploading function is so it can store and/or interact with it.
Now, that could be provided by the Image data passing to API policy however this would tie the two together, which means your texture object's functionality is now tied into the Image data passing to API policy.
Finally, the Texture storage policy needs to know what we are storing so it can store it AND the Freeing of the texture data policy needs to have an idea so it can know how to clear things up.
A slightly tangled mess indeed.
I'm sure a solution must exist, it might well take some scribblings on paper for me to work it out of course [grin] but these interdepenacies look a slight pain.
Of course, in computer science all problems can be solved by adding another layer of abstraction...
Or maybe I should take another look at how I decompose things and see if I've done it right..
More to follow, hopefully a bit quicker than before [smile]
First of all I think it's wise to set a standard 'format' which you will use internally. This is the format you will use to communicate between the different policies (so it better be well designed [grin]).
The loading policy loads from medium into the raw data part of that format.
The API specific policy will load that format into the API (and also clean it up on destruction). Incidentally, this means that your internal format might need a member for policy specific data, which is no problem if you use typedef.
The texture object I'd define yourself again and not allow the user to adjust it (at least for the first iteration).
The trick to using policies correctly is to define the interface rigidly and not care what the internals do. I think this project would lend itself quite well to using them, so just keep going, start implementing and you'll get there.
(For info: my logging system uses policies to define how a message gets formatted, and where it gets 'written' to)