G
Gianni Mariani
It started out as an ugly hack and it turned out to be very easy to do
but I'm concerned about wether I'm not seeing somthing so I'm asking the
wise ladies and gents of clc++ as to wether they turn to stone.
The problem goes like this. I have a class that uses an intrusive
reference count to manage the it's life-time. This class has multiple
interfaces e.g.
(using Austria C++ type smart pointers)...
struct A
: PtrTarget_MT
{
// ... things about A
};
struct B
: A
{
// ... things about B
};
In this system, it's good to know when all pointers to an objects B
interface have been released and it would be nice to do this automatically.
e.g.
Ptr<B*> l_b = new B;
Ptr<A*> l_a = l_b;
l_b = 0; // I'd like a special thing to happen in B here.
l_a = 0; // the object is now deleted as normal
With Austria smart pointers, you get to define a "PtrSelect" template
that can be used to select different behaviour for particular pointers.
template <
typename w_ClassRef,
typename w_First,
typename w_Secondclass PtrSelect
{
public:
typedef w_First type;
};
Where type here is usually a
template<typename w_ClassRef>
class at:
trTraits< w_ClassRef >
see:
http://austria.sourceforge.net/dox/html/classat_1_1PtrTraits.html
All that's needed here is to create a partial specialization of
PtrSelect based on B (like so)
template <
typename w_First,
typename w_Secondclass PtrSelect< B *, w_First, w_Second >
{
public:
typedef SpecialPtrTraits<B *> type;
};
and viola, any increments and decrements from only the B class is now
tallied separately to A, and B can do somthing special when no more
pointers to B exist (not necessarily delete, or anything else that makes
sense).
The pro's to this are:
a) no new mechanisms to learn
b) infrastructure to do this is quite easy
The cons to this :
a) Unsuspecting programmer might not quite understand the relevance of
dropping a pointer to B and might turn to stone once they see it.
Has anyone else done somthing like this ?
PtrSelect<> was put there to do exactly this sort of thing, but the
twist is doing in the same class (different interfaces). I'd resisted
doing it in the past but this time (in this particular application) it
appears to be the best solution (for thread safety issues).
Opinions ?
but I'm concerned about wether I'm not seeing somthing so I'm asking the
wise ladies and gents of clc++ as to wether they turn to stone.
The problem goes like this. I have a class that uses an intrusive
reference count to manage the it's life-time. This class has multiple
interfaces e.g.
(using Austria C++ type smart pointers)...
struct A
: PtrTarget_MT
{
// ... things about A
};
struct B
: A
{
// ... things about B
};
In this system, it's good to know when all pointers to an objects B
interface have been released and it would be nice to do this automatically.
e.g.
Ptr<B*> l_b = new B;
Ptr<A*> l_a = l_b;
l_b = 0; // I'd like a special thing to happen in B here.
l_a = 0; // the object is now deleted as normal
With Austria smart pointers, you get to define a "PtrSelect" template
that can be used to select different behaviour for particular pointers.
template <
typename w_ClassRef,
typename w_First,
typename w_Secondclass PtrSelect
{
public:
typedef w_First type;
};
Where type here is usually a
template<typename w_ClassRef>
class at:
trTraits< w_ClassRef >see:
http://austria.sourceforge.net/dox/html/classat_1_1PtrTraits.html
All that's needed here is to create a partial specialization of
PtrSelect based on B (like so)
template <
typename w_First,
typename w_Secondclass PtrSelect< B *, w_First, w_Second >
{
public:
typedef SpecialPtrTraits<B *> type;
};
and viola, any increments and decrements from only the B class is now
tallied separately to A, and B can do somthing special when no more
pointers to B exist (not necessarily delete, or anything else that makes
sense).
The pro's to this are:
a) no new mechanisms to learn
b) infrastructure to do this is quite easy
The cons to this :
a) Unsuspecting programmer might not quite understand the relevance of
dropping a pointer to B and might turn to stone once they see it.
Has anyone else done somthing like this ?
PtrSelect<> was put there to do exactly this sort of thing, but the
twist is doing in the same class (different interfaces). I'd resisted
doing it in the past but this time (in this particular application) it
appears to be the best solution (for thread safety issues).
Opinions ?