A smart pointer and type forwarding

[Ney André de Mello Zunino]

Hello.

I have written a simple reference-counting smart pointer class template
called RefCountPtr<T>. It works in conjunction with another class,
ReferenceCounta ble, which is responsible for the actual counting. Here
is the latter's definition:

// --- Begin ReferenceCounta ble.h ----------

class ReferenceCounta ble
{
public:
virtual ~ReferenceCount able() {}
void incrementRefere nceCount() { count++; }
void decrementRefere nceCount() { count--; }
unsigned int referenceCount( ) const { return count; }
protected:
ReferenceCounta ble() : count(0) {}
private:
unsigned int count;
};

// --- End ReferenceCounta ble.h ----------

Classes whose objects are to be reference-counted must derive from
ReferenceCounta ble. E.g.:

// --- Begin Foo.h ----------

#include "ReferenceCount able.h"

class Foo : public ReferenceCounta ble
{
public:
void f() {}
};

// --- End Foo.h ----------

From now on, one can create instances of the smart pointer class and
use them as regular pointers. E.g.:

RefCountPtr<Foo pfoo = new Foo;
pfoo->f();

The idea of making the smart pointer behave like regular pointers is key
and is also the reason for this post. There is a situation where I have
found myself unable to make my smart pointers behave like regular ones.
It occurs when a given class holds RefCountPtr<Tas member variables.
For a regular pointer, one could do:

class Foo;

class Test
{
Foo* mFoo;
};

Therefore, I would like to be able to have:

#include "RefCountPtr.hp p"

class Foo;

class Test
{
RefCountPtr<Foo mFoo;
};

But, unfortunately, the compiler does not find it sufficient to know
that Foo is a class. Here is a relevant snippet of the /RefCountPtr<T>/
class template, showing its constructors, destructor and only member
variable:

// --- Begin snippet of RefCountPtr.hpp ----------

#include "ReferenceCount able.h"

template <class T>
class RefCountPtr
{
public:
RefCountPtr()
: object(0)
{
}

RefCountPtr(T* pointer)
: object(pointer)
{
if (object)
object->incrementRefer enceCount();
}

RefCountPtr(con st RefCountPtr& original)
: object(original .object)
{
if (object)
object->incrementRefer enceCount();
}

~RefCountPtr()
{
if (object)
{
object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
}

[Gianni Mariani]

Ney André de Mello Zunino wrote:
....

Error E2315 RefCountPtr.hpp 44: 'decrementRefer enceCount' is not a
member of 'Foo', because the type is not yet defined in function
RefCountPtr<Foo >::~RefCountPtr ()

As I understand it, upon finding the declaration of the /Test::mFoo/
member variable, the compiler goes on to instantiate the template for
the type /Foo/. Because the definition for /Foo/ has not been provided
(yet), it fails to compile the calls object->decrementRefer enceCount()
and object->referenceCount ().

The main point of my post is to try to figure out how I could arrange
the RefCountPtr<Tcl ass template so that type forwarding would suffice
when using it as a member of another class. The goal is to *reduce
dependencies* and to have the smart pointer behave like regular ones.

Note: if necessary, I can post the complete code of a simple test program.

It's important to have some example code that shows the error. BTW, the
Austria C++ smart pointer (at::Ptr<>)does all this and more so if you
want an example, go check it out.

Also, your ReferenceCounta ble class does dot handle copy construct and
assignment correctly and neither does your RefCountPtr.

>
Thank you,

[mlimber]

Ney André de Mello Zunino wrote:

Hello.

I have written a simple reference-counting smart pointer class template
called RefCountPtr<T>. It works in conjunction with another class,
ReferenceCounta ble, which is responsible for the actual counting. Here
is the latter's definition:

// --- Begin ReferenceCounta ble.h ----------

class ReferenceCounta ble
{
public:
virtual ~ReferenceCount able() {}
void incrementRefere nceCount() { count++; }
void decrementRefere nceCount() { count--; }
unsigned int referenceCount( ) const { return count; }
protected:
ReferenceCounta ble() : count(0) {}
private:
unsigned int count;
};

// --- End ReferenceCounta ble.h ----------

Classes whose objects are to be reference-counted must derive from
ReferenceCounta ble. E.g.:

// --- Begin Foo.h ----------

#include "ReferenceCount able.h"

class Foo : public ReferenceCounta ble
{
public:
void f() {}
};

// --- End Foo.h ----------

From now on, one can create instances of the smart pointer class and
use them as regular pointers. E.g.:

RefCountPtr<Foo pfoo = new Foo;
pfoo->f();

The idea of making the smart pointer behave like regular pointers is key
and is also the reason for this post. There is a situation where I have
found myself unable to make my smart pointers behave like regular ones.
It occurs when a given class holds RefCountPtr<Tas member variables.
For a regular pointer, one could do:

class Foo;

class Test
{
Foo* mFoo;
};

Therefore, I would like to be able to have:

#include "RefCountPtr.hp p"

class Foo;

class Test
{
RefCountPtr<Foo mFoo;
};

But, unfortunately, the compiler does not find it sufficient to know
that Foo is a class. Here is a relevant snippet of the /RefCountPtr<T>/
class template, showing its constructors, destructor and only member
variable:

// --- Begin snippet of RefCountPtr.hpp ----------

#include "ReferenceCount able.h"

template <class T>
class RefCountPtr
{
public:
RefCountPtr()
: object(0)
{
}

RefCountPtr(T* pointer)
: object(pointer)
{
if (object)
object->incrementRefer enceCount();
}

RefCountPtr(con st RefCountPtr& original)
: object(original .object)

Bug: You need to decrement the reference count before reassigning.

{
if (object)
object->incrementRefer enceCount();
}

~RefCountPtr()
{
if (object)
{
object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
}
.
.
.
private:
T* object;
};

// --- End snippet of RefCountPtr.hpp ----------

Here is one of the error messages output by the compiler:

Error E2315 RefCountPtr.hpp 44: 'decrementRefer enceCount' is not a
member of 'Foo', because the type is not yet defined in function
RefCountPtr<Foo >::~RefCountPtr ()

As I understand it, upon finding the declaration of the /Test::mFoo/
member variable, the compiler goes on to instantiate the template for
the type /Foo/. Because the definition for /Foo/ has not been provided
(yet), it fails to compile the calls object->decrementRefer enceCount()
and object->referenceCount ().

The main point of my post is to try to figure out how I could arrange
the RefCountPtr<Tcl ass template so that type forwarding would suffice
when using it as a member of another class. The goal is to *reduce
dependencies* and to have the smart pointer behave like regular ones.

Note: if necessary, I can post the complete code of a simple test program.

Several solutions come to mind:

1. *Declare* Foo fully before your use of it as a member of Test. Of
course, this doesn't aid in reducing dependencies.

2. Put the *definitions* of RefCoutPtr's member functions after all
instances of its use as a member. Absent the export keyword (cf.
http://www.parashift.com/c++-faq-lit...tml#faq-35.14), this
is ugly but not exceedingly dangerous since you'll get compile-time
errors if you mess it up.

3. Use non-intrusive reference counting such as that found in
std::tr1::share d_ptr (aka boost::shared_p tr), Loki::SmartPtr, or this
FAQ:
<http://www.parashift.c om/c++-faq-lite/freestore-mgmt.html#faq-16.22>.

Cheers! --M

[Earl Purple]

Ney André de Mello Zunino wrote:

The idea of making the smart pointer behave like regular pointers is key
and is also the reason for this post. There is a situation where I have
found myself unable to make my smart pointers behave like regular ones.
It occurs when a given class holds RefCountPtr<Tas member variables.
For a regular pointer, one could do:

class Foo;

class Test
{
Foo* mFoo;
};

Therefore, I would like to be able to have:

#include "RefCountPtr.hp p"

class Foo;

class Test
{
RefCountPtr<Foo mFoo;
};

But, unfortunately, the compiler does not find it sufficient to know
that Foo is a class. Here is a relevant snippet of the /RefCountPtr<T>/
class template, showing its constructors, destructor and only member
variable:

You should declare a destructor in Test and put its implementation into
the compilation unit, even if it is empty (which is probably will be).
Then your compiler won't attempt to call the destructor of your
RefCountPtr class.

Note that the type does have to be complete at the point of its
deletion.

Another alternative, that I used in my final version of the intrusive
smart pointer before I did away with it, was to use a second template
parameter and use that in the destructor. RefCountPtr< T, BASE_T=T >
and now BASE_T was the base-class from which you derive and it calls
methods through that. Only BASE_T has to be complete so in Test you
would declare as

class Test
{
RefCountPtr< Foo, ReferenceCounta ble mFoo;
};

Even if you don't want to use it, I would suggest you look at the code
for boost::intrusiv e_ptr (I hope you can decipher it) just to see how
they did it.

[Ney André de Mello Zunino]

Gianni Mariani wrote:

It's important to have some example code that shows the error. BTW, the
Austria C++ smart pointer (at::Ptr<>)does all this and more so if you
want an example, go check it out.

I will have a look at it. Thank you. And let me just clarify that the
reason I decided to create my own smart pointer class was simply as an
opportunity for improving my experience and not because existing
alternatives did not suffice.

Also, your ReferenceCounta ble class does dot handle copy construct and
assignment correctly and neither does your RefCountPtr.

You are right. I am infringing the "rule of three". I suppose that, in
the case of /ReferenceCounta ble/, I should make sure both the copy
constructor and assignment operator reset the reference count for the
new object, right? Is there anything else I should take into account?

As for /RefCountPtr<T>/, could you help me see what I am doing wrong in
the copy constructor? As for the assignment operator, I did implement
it, though I did not include the code in the original post. Here it is:

RefCountPtr& operator=(const RefCountPtr& original)
{
return operator=(origi nal.object);
}

RefCountPtr& operator=(T* pointer)
{
// Check for self-assignment and assignment from
// equivalent smart pointer
if (this->object != pointer)
{
if (object)
{
object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
object = pointer;
if (pointer)
pointer->incrementRefer enceCount();
}
return *this;
}

Is the implementation of the assignment operator for /RefCountPtr<T>/
also incorrect or incomplete?

Thank you,

--
Ney André de Mello Zunino
http://blog.zunino.eti.br/

[Ney André de Mello Zunino]

mlimber wrote:

Ney André de Mello Zunino wrote:

> RefCountPtr(con st RefCountPtr& original)
: object(original .object)

Bug: You need to decrement the reference count before reassigning.

> {
if (object)
object->incrementRefer enceCount();
}

I am sorry, but I could not understand your remark. Why should I
decrement the reference count? For example, suppose I have an instance
/foo/ of type /Foo/ being managed by an instance of /RefCountPtr<Foo >/
named /pFoo1/. So far, the reference counter on the /foo/ object has
value 1. If a new /RefCountPtr<Foo >/, say /pFoo2/, is created by copy
construction from /pFoo1/, I expect both smart pointers to refer to the
same object and, therefore, its reference count should go up by 1,
becoming 2. That is why I increment the managed object's reference count
in the copy constructor. Am I wrong?

Several solutions come to mind:

1. *Declare* Foo fully before your use of it as a member of Test. Of
course, this doesn't aid in reducing dependencies.

Okay. That surely works and it's what I have been doing. But, as you
mentioned, the dependencie issue is still there and the smart pointer is
still not behaving like a regular pointer.

2. Put the *definitions* of RefCoutPtr's member functions after all
instances of its use as a member. Absent the export keyword (cf.
http://www.parashift.com/c++-faq-lit...tml#faq-35.14), this
is ugly but not exceedingly dangerous since you'll get compile-time
errors if you mess it up.

Could you show me what you mean?

3. Use non-intrusive reference counting such as that found in
std::tr1::share d_ptr (aka boost::shared_p tr), Loki::SmartPtr, or this
FAQ:
<http://www.parashift.c om/c++-faq-lite/freestore-mgmt.html#faq-16.22>.

When I decided to write my own smart pointer class, I read a little
about the different approaches one can take. I remember having picked
the intrusive one because it looked easier to implement and because it
incurred little penalty on performance.

Thank you,

--
Ney André de Mello Zunino

[mlimber]

Ney André de Mello Zunino wrote:

mlimber wrote:

Ney André de Mello Zunino wrote:

RefCountPtr(con st RefCountPtr& original)
: object(original .object)

Bug: You need to decrement the reference count before reassigning.

{
if (object)
object->incrementRefer enceCount();
}

I am sorry, but I could not understand your remark. Why should I
decrement the reference count? For example, suppose I have an instance
/foo/ of type /Foo/ being managed by an instance of /RefCountPtr<Foo >/
named /pFoo1/. So far, the reference counter on the /foo/ object has
value 1. If a new /RefCountPtr<Foo >/, say /pFoo2/, is created by copy
construction from /pFoo1/, I expect both smart pointers to refer to the
same object and, therefore, its reference count should go up by 1,
becoming 2. That is why I increment the managed object's reference count
in the copy constructor. Am I wrong?

Mea culpa. I was thinking of the assignment operator.

Several solutions come to mind:

1. *Declare* Foo fully before your use of it as a member of Test. Of
course, this doesn't aid in reducing dependencies.

Okay. That surely works and it's what I have been doing. But, as you
mentioned, the dependencie issue is still there and the smart pointer is
still not behaving like a regular pointer.

2. Put the *definitions* of RefCoutPtr's member functions after all
instances of its use as a member. Absent the export keyword (cf.
http://www.parashift.com/c++-faq-lit...tml#faq-35.14), this
is ugly but not exceedingly dangerous since you'll get compile-time
errors if you mess it up.

Could you show me what you mean?

Declare RefCountPtr in a header RefCountPtr.hpp (or whatever), but put
the implementation of its functions in RefCountPtr.cpp (or whatever).
Include the latter file explicitly in every .cpp file that uses
RefCountPtr but make sure it is *after* the full declarations of the
forward-declared objects. E.g.,

In Bar.hpp
#include "RefCountPtr.hp p"
class Foo;
class Bar
{
// ...
RefCountPtr<Foo foo_;
};

In Bar.cpp:
#include "Bar.hpp"
#include "Foo.hpp"
#include "RefCountPtr.cp p"
// ...

3. Use non-intrusive reference counting such as that found in
std::tr1::share d_ptr (aka boost::shared_p tr), Loki::SmartPtr, or this
FAQ:
<http://www.parashift.c om/c++-faq-lite/freestore-mgmt.html#faq-16.22>.

When I decided to write my own smart pointer class, I read a little
about the different approaches one can take. I remember having picked
the intrusive one because it looked easier to implement and because it
incurred little penalty on performance.

There are certainly trade-offs to be had -- one of which is the ability
to forward-declare a class. The smart pointer in the FAQ is pretty
simple and straight-forward, though it doesn't have all the options of
shared_ptr and the like. I'm all for exercising your skills by writing
your own smart pointer, but for production code, I'd suggest going with
a tried-and-true smart pointer from the standard library, Boost, or
similar if possible. They're notoriously tricky to get right.

Cheers! --M

[Earl Purple]

Ney André de Mello Zunino wrote:

>
RefCountPtr& operator=(const RefCountPtr& original)
{
return operator=(origi nal.object);
}

RefCountPtr& operator=(T* pointer)
{
// Check for self-assignment and assignment from
// equivalent smart pointer
if (this->object != pointer)
{

stop right there!

operator= should be implemented in terms of copy-construct and swap!

operator=( T* ) is not recommended either. Better to use a method such
as reset( T* )

swap is nice and simple and will never throw.

[Frederick Gotham]

Earl Purple:

operator= should be implemented in terms of copy-construct and swap!

operator=( T* ) is not recommended either. Better to use a method such
as reset( T* )

swap is nice and simple and will never throw.

Nicely inefficient, yes.

--

Frederick Gotham

[Gianni Mariani]

Ney André de Mello Zunino wrote:

Gianni Mariani wrote:

>It's important to have some example code that shows the error. BTW,
the Austria C++ smart pointer (at::Ptr<>)does all this and more so if
you want an example, go check it out.

I will have a look at it. Thank you. And let me just clarify that the
reason I decided to create my own smart pointer class was simply as an
opportunity for improving my experience and not because existing
alternatives did not suffice.

Excellent.

>

>Also, your ReferenceCounta ble class does dot handle copy construct and
assignment correctly and neither does your RefCountPtr.

You are right. I am infringing the "rule of three". I suppose that, in
the case of /ReferenceCounta ble/, I should make sure both the copy
constructor and assignment operator reset the reference count for the
new object, right? Is there anything else I should take into account?

No. Yes.

Think about what the reference count is for. The reference count is the
number of existing smart pointers that are pointing to the object being
reference counted ! This does not change when the object is assigned.
Since the default assignment operator and copy constructor copy the
reference count, this is not the right behaviour. So you need to ignore
the reference count of the RHS on assignment and set the reference count
to whatever you initial reference count is on copy construct.

>
As for /RefCountPtr<T>/, could you help me see what I am doing wrong in
the copy constructor? As for the assignment operator, I did implement
it, though I did not include the code in the original post. Here it is:

RefCountPtr& operator=(const RefCountPtr& original)
{
return operator=(origi nal.object);

return * this;

}

Pointer assignment should be a template. You want to allow assignment
from types derived from T.

RefCountPtr& operator=(T* pointer)
{
// Check for self-assignment and assignment from
// equivalent smart pointer
if (this->object != pointer)
{
if (object)
{

Is it better that an object "delete" itself of that the smart pointer
calls delete ? You need to also consider using this in a threaded
environment. The first thing you want to do is to place the pointer
being assigned with the incremeneted count in place and the very last
thing is call decrement reference and in your case delete. The FAQ does
have it in the right order, so take a look at the FAQ.

object->decrementRefer enceCount();
if (object->referenceCount () == 0)
delete object;
}
object = pointer;
if (pointer)
pointer->incrementRefer enceCount();
}
return *this;
}

Is the implementation of the assignment operator for /RefCountPtr<T>/
also incorrect or incomplete?

incorrect ...

Also, consider letting the object do whatever it does on reference count
reaching zero and the smart pointer call whatever interface to manage it.

Also, what you're designing here is an "intrusive" smart pointer. There
is also an "extrusive" smart pointer idea which is what seems to be
targeted for approval for the next version of the standard. You can
find it in the boost shared_ptr implementation.