ref counted pointers going out of scope
 

Hello

If I have a function which creates a pointer like this:

int number = 44; //global

void MyFunction() {
int* pNum = &number;
}

Then as soon as MyFunction returns then pNum goes out of scope and
becomes no more.

But I am looking at some code that does this:

CRQueue::ptr_type pqueue = thisThread->GetQueue();

The next step is that a timer is setup to periodically exercise some
function using some items that have been added to the queue.

As the pqueue is reference counted, I am assuming it doesn't go out of
scope and so the queue will still be valid (presumably until all items
in the queue have benn processed by the timer function?).


I am really just looking for confirmation that this is possible to
do. If so, I then need to read up on reference counted pointers. Any
hints on good sources of info would be appreciated.

Re: ref counted pointers going out of scope
 

On Nov 19, 11:54*am, Angus <anguscom...@gmail.com> wrote:

[]

> But I am looking at some code that does this:
>
> CRQueue::ptr_type pqueue = thisThread->GetQueue();
>
> The next step is that a timer is setup to periodically exercise some
> function using some items that have been added to the queue.
>
> As the pqueue is reference counted, I am assuming it doesn't go out of
> scope and so the queue will still be valid (presumably until all items
> in the queue have benn processed by the timer function?).

It does go out of scope.

> I am really just looking for confirmation that this is possible to
> do. *If so, I then need to read up on reference counted pointers. *Any
> hints on good sources of info would be appreciated.

The idea behind reference counting is that there is a reference
counter associated with an object (often it is simple a member of an
object). When you create a smart-pointer to that object, the
constructor of the pointer increments the counter. When the pointer
gets destroyed, its destructor of the pointer decrements the reference
counter. When the reference counter reaches 0 it means that there are
no more pointers referencing that objects, so that the object can be
destroyed.

In your particular case, there is a (probably work) queue associated
with a thread. The queue must be owned by the thread object, so no
matter what kind of pointer you use to refer to that queue, the queue
exists as long as the thread owning it exists.

--
Max