template <class T>
class cSingleton : private T
{
//...
};
template <typename A>
class ObjectManager : public cSingleton< ObjectManager > // <--- !!! "Expected a type, got 'Manager' " ?
{
//...
std::vector<boost::shared_ptr<A> > items;
}
struct Object
{
string name;
};
ObjectManager <Object> manager; // or should this become "ObjectManager<Object>::get()->add() etc?
// This on the other hand is allowed...
class MyClass : public cSingleton<MyClass>
{
//...
}
//and works like so:
MyClass::get()->add();
Nested templates c++... Possible?
Author
Hello,
I'm trying to wrap my head (and my various objectmanagers ) around a nested template problem...
Does anyone know how to solve the following?
The whole idea of my code was to avoid having multiple versions of the singleton class, and simply create a resourceManager class that can contain anything... Is it possible or am I doing it wrong? :D
Thanks for your time!
1) Try class ObjectManager : public cSingleton< ObjectManager<A> >
2) Oh god singletons
3) Oh god managers
2) Oh god singletons
3) Oh god managers
Quote:Original post by RasmadrakYou can't do that! You have ObjectManager<A> inheriting from cSingleton< ObjectManer<A> >, which in turn inherits from ObjectManager<A>...template <class T>class cSingleton : private T{ //...}; template <typename A>class ObjectManager : public cSingleton< ObjectManager > // <--- !!! "Expected a type, got 'Manager' " ? { //... std::vector<boost::shared_ptr<A> > items; }
Why on earth does your singleton class want to inherit from its derived class? Not to mention, singletons are evil [wink]
Author
Quote:
Singeltons are evil...
So I've heard... ;)
Anyway, the following did the trick:
Quote:
template < typename A >
class M
Manager : public cSingleton< Manager < A> >
I'm trying to create a threadsafe library and figure singletons was the best (most convenient?) way to go since there's only one interface with the world.
What's so terrible wrong with having...
TextureManager::get()->getTexture("sometexture.jpg");
ModelManager::get()->getModel("somemodel.3ds");
They're also mutex'ed so that only one thread can access it at the same time.
Maybe it's the coffee talking, but how would one handle smooth multithreaded loading/handling otherwise?
What is multithreaded about your code? Does the FooManager load Foo instances in a background thread? Or can the code be called safely from multiple threads? Or something else?
Quote:Original post by RasmadrakApart from the usual arguments against Singletons, you have created a nasty synchronization point by mutex'ing the singleton accessors.Quote:Singeltons are evil...
I'm trying to create a threadsafe library and figure singletons was the best (most convenient?) way to go since there's only one interface with the world.
What's so terrible wrong with having...
What happens when thread A requests a resource which thread B is still loading? At best you stall thread A until thread B finishes loading, neatly erasing any benefit of multi-threaded loading.
Quote:Maybe it's the coffee talking, but how would one handle smooth multithreaded loading/handling otherwise?Usually, with message passing, or a futures mechanism.
Author
Quote:Original post by rip-off
What is multithreaded about your code? Does the FooManager load Foo instances in a background thread? Or can the code be called safely from multiple threads? Or something else?
Both.
for example, in pseudo code as I'm developing this as we speak:
mainthread: modelManager.add"box.3ds"); //Return immediatly. modelManager.getItem("box.3ds")->isPhysical(true); if (modelManager->isLoaded("box.3ds") ) modelManager->render("box.3ds") ; //renders without textures if textures aren't loaded yet etc... worker thread: modelManager->loadItems(); textureManager->loadItems();phyicsThread: "check if new physical object requested" if (modelManager->isLoaded("box.3ds") ) physicsManager->insert("box.3ds");Each manager automatically unloads objects that's havn't been used for a while, and automatically loads new items.
Quote:Original post by Rasmadrak
I'm trying to create a threadsafe library and figure singletons was the best (most convenient?) way to go since there's only one interface with the world.
Singletons are often one of the worst solutions for creating a threadsafe library as there's only one instance that all threads must share, whereas it's often saner and more efficient for each thread to have have their own copies of things. And unless you're targeting D3D11+ only, your graphics APIs aren't thread safe anyways.
Author
So one would triple the memory requirement and synchronize all the data each loop? That doesn't makes sense to me. :)
Again, I havn't much experience in the multithreading field (yet)...
Again, I havn't much experience in the multithreading field (yet)...
Quote:Original post by RasmadrakDon't think about loops in multithreading - each thread has its own main loop, and they are running at different speeds. In general, synchronizing them kills most of the performance benefit of multiple threads.
So one would triple the memory requirement and synchronize all the data each loop?
Instead you probably want to pass messages between threads, such as LoadObject and ObjectFinishedloading.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
