HandBooks Professional Java-C-Scrip-SQL part 42 ppsx

public:
some_class() {
std::cout << "some_class::some_class()\n";
}
some_class(const some_class& other) {
std::cout << "some_class(const some_class& other)\n";
}
~some_class() {
std::cout << "some_class::~some_class()\n";
}
};
int main() {
std::cout << "Before start of scope\n";
{
boost::intrusive_ptr<some_class> p1(new some_class());
boost::intrusive_ptr<some_class> p2(p1);
}
std::cout << "After end of scope \n";
}
To demonstrate that the intrusive_ptrs together with the functions
intrusive_ptr_add_ref and intrusive_ptr_release do their jobs
right, here is the output from running the program:
Before start of scope
some_class::some_class()
some_class::~some_class()
After end of scope
The intrusive_ptr is taking care of business for us. When the first
intrusive_ptr p1 is created, it is passed a new instance of some_class.
The intrusive_ptr constructor actually takes two arguments. The second is a
bool that states whether intrusive_ptr_add_ref should be called or not.
Because the default value of this argument is TRue, when constructing p1, the

reference counter for the instance of some_class becomes 1. Then, a second
intrusive_ptr, p2, is constructed. It is copy constructed from p1, and when
p2 sees that p1 is referencing a non-null pointer, it calls
intrusive_ptr_add_ref. The reference count is now 2. Then, the two
intrusive_ptrs leave scope. First, p2 is destroyed, and the destructor calls
intrusive_ptr_release. This decrements the reference counter to 1. Then,
p1 is destroyed, and the destructor calls intrusive_ptr_release again,
which causes the reference count to drop to 0; this in turn triggers our
implementation of intrusive_ptr_release to delete the pointer. You'll
note that the implementation of reference_counter is not thread-safe, and
therefore cannot be used in multithreaded applications without adding
synchronization.
Rather than relying on a generic implementation of intrusive_ptr_add_ref
and intrusive_ptr_release, we could have these functions operate directly
on the base class (here, reference_counter). The advantage of this approach
is that even if the classes derived from reference_counter are defined in
other namespaces, intrusive_ptr_add_ref and
intrusive_ptr_release will still be found using ADL (argument dependent
lookup). Changing the implementation of reference_counter is
straightforward.
class reference_counter {
int ref_count_;
public:
reference_counter() : ref_count_(0) {}

virtual ~reference_counter() {}
friend void intrusive_ptr_add_ref(reference_counter* p) {
++p->ref_count_;
}
friend void intrusive_ptr_release(reference_counter* p) {

if ( p->ref_count_==0)
delete p;
}
protected:
reference_counter& operator=(const reference_counter&) {
// No-op
return *this;
}
private:
// Copy construction disallowed
reference_counter(const reference_counter&);
};
Treating this As a Smart Pointer
It's not altogether easy to come up with scenarios where intrusive, reference-
counted smart pointers are really required. Most, if not all, problems can be solved
with non-intrusive smart pointers. However, there is one case in which it's easier to
use an intrusive reference count: when one needs to return this from a member
function, to be stored in another smart pointer. When returning this from a type
that's being owned by non-intrusive smart pointers, the result is that two different
smart pointers believe that they own the same object, which implies that they will
both try to delete it when the time has come to do so. This leads to double deletion,
with the probable result that your application will crash. It must somehow be
possible to tell the other smart pointer that this resource is already referenced by
another smart pointer, and that's exactly what an internal reference counter
(implicitly) does. Because the logic of intrusive_ptr indirectly operates on the
internal reference count of the objects they refer to, there is no violation of
ownership or inconsistencies in the reference counting. The reference count is
simply incremented.
Let's take a look at the potential problem first, with an implementation relying on
boost::shared_ptr for sharing resource ownership. It's basically the

example from earlier in this chapter, when discussing
enable_shared_from_this.
#include "boost/shared_ptr.hpp"
class A;
void do_stuff(boost::shared_ptr<A> p) {
//
}
class A {
public:
call_do_stuff() {
shared_ptr<A> p(???);
do_stuff(p);
}
};
int main() {
boost::shared_ptr<A> p(new A());
p->call_do_stuff();
}
The class A wants to call the function do_stuff, but the problem is that
do_stuff expects a shared_ptr<A>, not a plain pointer to A. So, in
A::call_do_stuff, how should the shared_ptr be created? Now, let's
rewrite A to make it compatible with intrusive_ptr, by deriving from
reference_counter, and let's also add an overloaded version of do_stuff,
accepting an argument of type intrusive_ptr<A>.
#include "boost/intrusive_ptr.hpp"
class A;
void do_stuff(boost::intrusive_ptr<A> p) {
//
}
void do_stuff(boost::shared_ptr<A> p) {

//
}
class A : public reference_counter {
public:
void call_do_stuff() {
do_stuff(this);
}
};
int main() {
boost::intrusive_ptr<A> p(new A());
p->call_do_stuff();
}
As you can see, in this version of A::call_do_stuff, we are able to send this
directly to the function expecting an intrusive_ptr<A>, due to the converting
constructor of intrusive_ptr.
Here's a special treat to end this section: Now that A is supporting
intrusive_ptr, we can actually write code that creates a shared_ptr that
wraps the intrusive_ptr, allowing us to call the original version of
do_stuff, which takes a shared_ptr<A> as argument. Assuming that you
cannot control the source code for do_stuff, this might be a very real problem
that you need to solve. Again, the solution awaits in the form of a custom deleter,
one that understands that it needs to call intrusive_ptr_release. Here's the
new version of A::call_do_stuff.
void call_do_stuff() {
intrusive_ptr_add_ref(this);
boost::shared_ptr<A> p(this,&intrusive_ptr_release<A>);
do_stuff(p);
}
An elegant solution indeed. When there are no more shared_ptrs left, the
custom deleter is invoked, which calls intrusive_ptr_release, which in

turn decreases the internal reference counter of A. Note that if
intrusive_ptr_add_ref and intrusive_ptr_release are
implemented to operate on reference_counter, you'd create the
shared_ptr like so:
boost::shared_ptr<A> p(this,&intrusive_ptr_release);
Supporting Different Reference Counters
We talked earlier about the possibility of supporting different reference counts for
different types. This may be necessary when integrating existing classes with
different reference-counting mechanisms (third-party classes employing their own
version of a reference-counter, for example). Or there may be different
requirements for deallocating, such as calling another function rather than
delete. As mentioned already, the calls to intrusive_ptr_add_ref and
intrusive_ptr_release are unqualified. This means that the scope of the
argument (the pointer type) is considered during name lookup, and thus these
functions should be defined in the same scope as the type on which they should
operate. If you implement generic versions of intrusive_ptr_add_ref and
intrusive_ptr_release in the global namespace, you make it impossible to
create generic versions in other namespaces. For example, if a namespace needs a
special version for all of its types, specializations or overloads must be provided
for each and every type. Otherwise, the functions in the global namespace
introduce an ambiguity. It is therefore not a good idea to provide generic versions
in the global namespace, though they are fine in other namespaces.
Because of the way that we have implemented the reference counter, using the
base class reference_counter, it is a good idea to have an ordinary function
in the global namespace that accepts an argument of type
reference_counter*. This still allows us to provide generic overloads inside
other namespaces without introducing ambiguities. As an example, consider the
classes another_class and derived_class in a namespace called
my_namespace.
namespace my_namespace {

class another_class : public reference_counter {
public:
void call_before_destruction() const {
std::cout <<
"Yes, I'm ready before destruction\n";
}
};