What this approach can't do is to produce subviews of intermediate types as you also request, since typeid(x) returns a type_info object referring to the final class of x.
Does this help?
Well, it's better than my current version. Still it lacks the intermediate type views, and that's a must. So it helps showing me that I should have used multi_index from the start, but not how I can add this feature. Yet it's really nice to have an elaborate answer. After thinking a bit more on the "scope" improvement I was explaining in my last post, it turns out this is something I'll need to implement right now. So I'll add an even more complex feature to this container, that would be to add some kind of path (say GamesIDo/MyFirstGame/Level1) so that resources could be shared among several levels (as instance a character reaching the end of a level ... the entire level would have to be unloaded, whereas the character would need to be kept, so the character resource would be in GamesIDo/MyFirstGame/). Queries on this container could take an additional input path to speed things up. This is something actually missing for our whole industry. Cheers, SeskaPeel.