Re: [Algorithms] Managing Pointers - Part II

[Igor K. <ig...@ob...>]

La PoPsY TeAm sur GDA !
La famille s'agrandit... :)

Igor.


----- Original Message ----- 
From: "U2 PoPsY TeAm" <u2...@fr...>
To: <gda...@li...>
Sent: Monday, July 29, 2002 12:39 PM
Subject: Re: [Algorithms] Managing Pointers - Part II


> if you have an Meta definition in your Base class you could introduce this
> notion in the MetaObject ( and include the Manager into the Meta Object in
> fact ).
> In the MetaObject you will doing something like this
> 
> MetaObject:::AddPtr( ptr )
> {
>     If( PtrManaged )
>         m_list.add( Ptr )  .
>     else
>         GetParentMeta()->AddPtr( ptr ).
> }
> 
> id MetaObject:::GetId( ptr )
> {
>     if( ptr not in the list )
>         AddPtr( ptr )
>     return Id ptr from the list
> }
> 
> in this case when you want to generate the Id for your object you should
> call the Ptr->Meta, so even if your Ptr is a resource the Id will be
> generated by the MetaObject ( who is a TextureMetaObject in your case ).
> 
> after that  make :
> 
> Ptr<T>::operator( const T* src )
> {
>     m_TargetId = src->GetMeta()->GetId( src )
>     ... // ref count etc...
>  }
> 
> i hope this will help you :))
> 
> ---------------------------------
> U2 - PoPsY TeAm
> http://www.popsyteam.org
> ---------------------------------
> 
> ----- Original Message -----
> From: "Jim Offerman" <j.o...@in...>
> To: <gda...@li...>
> Sent: Monday, July 29, 2002 11:39 AM
> Subject: [Algorithms] Managing Pointers - Part II
> 
> 
> > Hi,
> >
> > I've rounded up the basic implementation of my ownership-managed
> > pointer scheme using two template classes: PtrManager<T> and Ptr<T>.
> > Ptr<T> has a static instance of PtrManager<T>, so that there is a
> > PtrManager instance for each type of pointer.
> >
> > I originally intended to have a single PtrManager class that would
> > manage all pointers of all types, however, the main problem with such
> > a solution is that you tend to get a *very* big list of objects
> > (possible several thousands) that needs to be searched quite
> > frequently - namely whenever a 'raw' pointer is assigned to a smart
> > pointer, i.e.:
> >
> > Ptr<Obj> p1 = new Obj;
> > Obj *o = p1;
> > Ptr<Obj> p2 = o; // Need to search the list of objects here.
> >                  // for existing references to o by the system
> >                  // (in this case p1).
> >
> > Having a seperate PtrManager for each type of pointer greatly reduces
> > the cost of the search, since there will typically only be a
> > (relatively) small number of objects of a given type.
> >
> > However, this introduce a problem with derived classes, i.e.:
> >
> > Ptr<Texture> p1 = new Texture;
> > Ptr<Resource> p2 = p1;
> >
> > In my current implementation, both the PtrManager<Texture> and
> > PtrManager<Resource> instance will assume control of the texture
> > instance that is being referenced by p1 and p2.
> >
> > This is obviously heading for disaster. So, what I need is a mechanism
> > of telling the PtrManager of type A that a certain object is already
> > managed by the PtrManager of type B. And it has to be bulletproof.
> >
> > Having a
> >
> > Ptr<T>::operator(const Ptr<S> &s)
> > {
> >    mTargetId = Attach(dynamic_cast<T *> s.GetTarget(),
> >                       PTR_NOTMANAGED);
> > }
> >
> > Solves part of the problem, however the hard one to solve is the
> > following case:
> >
> > Ptr<Texture> p1 = new Texture;
> > Texture *t = p1;
> > Ptr<Resource> p2 = t;
> >
> > I cannot think of a way of telling the PtrManager<Resource> instance
> > that the texture referred to by t is already being managed by the
> > PtrManager<Texture> instance (since they don't even know of each
> > others existence) without having all objects in a single list.
> >
> > Ideas anyone?
> >
> > (If the problem is unsolvable, I can live with that... just thought I
> >  should check...).
> >
> > Jim Offerman
> > Innovade
> > www.innovade.com
> >
> > www.jimofferman.nl
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Dice - The leading online job board
> > for high-tech professionals. Search and apply for tech jobs today!
> > http://seeker.dice.com/seeker.epl?rel_code=31
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>