well im just trying to experiment with simplfying the use of OnLostDevice and OnResetDevice that come with some directx objects... since im using the intrusive_ptr for all Directx COM objects i thought id implement a function "OnResetDevice" into the intrusive_ptr class and with the help of boost::enable_if i could call the OnResetDevice function for the class types that needs it while in other cases its just ignored...

this way i dont have to worry if a directxobject needs to call OnResetDevice or not... i can always call it...

in a later stage i was hoping to create a global list of pointers to this class refering to all directx objects created and simply looping through this list and calling OnResetDevice... this way i only have to call OnResetDevice once.. and dont have to worry about everytime i define a directx object....

i know this probably isnt a very fast approach... but i dont think OnResetDevice and OnLostDevice are called very often... and this would save alot of hassle...

probably wont be possible...its just some thoughts and ideas... but i like to learn through experimenting...

This is a bad idea. First of all, is there a reason you're using intrusive_ptr and not CComPtr? CComPtr is designed to be used with COM interfaces and doesn't require you to involve the extra machinery for the intrusive_ptr implementation.

Second, you're combining the responsibilities of a pointer object and a resettable device object -- this is in violation of the Single Responsibility Principal.

You can use enable_if to do what you want without re-implementing intrusive_ptr, just make non-member functions selected via enable_if that either call OnLostDevice/OnResetDevice on a passed-in object or do nothign with the passed-in object, as needed.

And honestly, I would venture to suggest that perhaps you need to do better resource management if you need this capability. The implication is that you are trying to treat all "DirectX objects" as the same, and trying to centralize functionality where you don't know enough information to actually do anything useful. But that depends on the actual set up of your system.

well then i just dont know how to do this...

having to define a OnLostDevice and OnResetDevice for all classes that uses these "directx objects" seems weird... its just the same thing everywhere...

is there anyway i could decide if an object has one of these functions, create a global list of pointers to these objects and then call them simultainously with something like foreach()?

i guess were starting to change the topic a bit now.. but thx anyways...

::EDITED

Quote:is there anyway i could decide if an object has one of these functions, create a global list of pointers to these objects and then call them simultainously with something like foreach()?

What is the criteria for deciding?

C++ is statically typed. You know which object you're creating at creation time. You cannot do something like Class.forName(args[4]), so it's a non-issue.

When you create an object, determine whether it needs to be notified or not, and put it in appropriate vector that you then update at given time.

Quote:
having to define a OnLostDevice and OnResetDevice for all classes that uses these "directx objects" seems weird...

It's no more weird than having a "position" data member for all classes that have a position in space. Show me some examples of your classes -- ideally, some with and some without these OnLostDevice and OnResetDevice members.

Quote:
is there anyway i could decide if an object has one of these functions, create a global list of pointers to these objects and then call them simultainously with something like foreach()?

The best way to decide if an object has one of these functions is take a moment, think very carefully, and remember if you wrote one of those functions for the class.

The idea of resetting all device objects in one go is not a bad one. But what you're trying to do is "reset every object and if that object is really a resettable device object then reset it otherwise do nothing." This suggests an overhomogenization of your objects such that you no longer know what an object is, and you're tring to treat everything the same even though everything really isn't the same.

Presumably there is a interface by which all your objects are created -- this is generally done through a resource factory type object, so that the factory can, immediately after creating the new object but before returning it, install the resource in some cache so that it can avoid the expensive recreation process later on if needed.

The actual implementation of the creation of the resource, whether by hard-coding it into the factory or using more robust abstract factory implemetnations, must know the concrete type being created. At that point, it can be added the appropriate resource cache. The cache can maintain a list of those objects that are resettable, and those that are not. For example, you might derive all resettable objects from some abstract base class specifying the lost/reset functions, and the cache might have specializations of the "add resource" method that install the resource into the appropriate list -- either resettable, or not. Or you could do that manually.

Either way, the point is that you need to treat the objects as what they are. If they are different, stop pretending they're the same. It's inefficient and leads to poor design. An object that is resettable is different than one that isn't, and while the you can treat all resettable objects the same from the context of the reset process, you shouldn't even include nonresettable objects in that process. It suggests your code is in control, not you.

If you provide some examples of some of your objects and how they are created I can show you in detail what I mean in the context of your own code.