Sign in to follow this  
Dragon_Strike

boost::intrusive_ptr wrapper

Recommended Posts

i would like to create a class wrapper for boost::intrusive_ptr which just ads a few function id like... it shold work just like intrusive_ptr just with these extra functions... is this possible? im having problem getting it working with the constructors... something like template<class T> class new_ptr : public boost::intrusive_ptr<T> { public: void NewFunction(){} }

Share this post


Link to post
Share on other sites
well i dont know how to be very specific...
i get alot of different compiler errors that has to do with the templates...
ill be more specific once i get home from my job...

try to compile a similar class and you'll see...

is there anyway to derive both public and private?

Share this post


Link to post
Share on other sites
I thought id post here since i had no idea how to derive intrusive_ptr properly...

i was hoping that someone just showed me how to implement the constructor... but on second thought that might be hard if i dont understand what i want to do...

ill make another try and post the code and errors this time...

ill be back later 2 day with that... thx

Share this post


Link to post
Share on other sites
Don't derive from boost::intrusive_ptr. It lacks a virtual destructor, meaning it isn't intended to be derived from. Use non-member functions if you want extra functionality.

Share this post


Link to post
Share on other sites
Quote:
then instead of writing a wrapper ill just rewrite the entire intrusive_ptr source code...


That's not what SiCrane suggested. He meant the if you want to implement extra functionality, you can do so with non-member functions. There's really no need to completely rewrite the class.

Share this post


Link to post
Share on other sites
Quote:

ok thx...
then instead of writing a wrapper ill just rewrite the entire intrusive_ptr source code...

That would be silly, wouldn't it?

What function do you want to add, and why? Either there is a better way to accomplish what you want without re-engineering an entire (rather complex) pointer class, or what you want to do is a bad idea anyway and you should find another way to do it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dragon_Strike
ok thx...
then instead of writing a wrapper ill just rewrite the entire intrusive_ptr source code...
Hm, that doesn't sound like a particularly good idea - it'll consume time and effort probably better spent elsewhere, and may very well leave you with buggy code (remember that the Boost libraries are widely used and have been thoroughly reviewed and tested).

What extra functionality do you want to add?

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this