owernship of ying and yang objects

[ma740988]

Experimenting with smart pointers here but need a refresher here.

Consider the snippet:

# include <iostream>
# include <string>

using namespace std;

class ying {
public:
ying () {}
~ying() { cout << " deleted ying " << endl; }
void run_it()
{ cout << typeid(*this).name() << endl; }

ying& operator=(const ying& o )
{ cout << " op= ying " << endl;
return *this; }
ying(const ying& o )
{cout << " cc ying " << endl; }

};

class yang
{
public:
yang () {}
~yang() { cout << " deleted yang " << endl; }
yang& operator=(const yang& o )
{ cout << " op= yang " << endl;
return *this; }
yang(const yang& o )
{cout << " cc yang " << endl; }

void run_it()
{ cout << typeid(*this).name() << endl; }
};

class bar {
yang *ptr_ya;
ying *ptr_yi;
public:
bar ( yang* ptr1, ying* ptr2 )
: ptr_ya(ptr1)
, ptr_yi(ptr2)
{}

void test_yang() { ptr_ya->run_it(); }
void test_ying() { ptr_yi->run_it(); }

~bar() { delete ptr_ya; delete ptr_yi; }

};

int main()
{
yang *ptr_ya = new yang();
ying *ptr_yi = new ying();

bar b(ptr_ya, ptr_yi);
b.test_yang();
b.test_ying();

// no longer necessary. this is why we're better off with
// auto_ptrs (the smart 'pointer' stuff)
//delete ptr_ya;
//delete ptr_yi;

}

I've haven't retrofitted the source yet to use smart pointers,
nonetheless, simple question. The ying and yang objects are passed
(pass by pointer) to bar constructors. That said, it's bars
responsibility to delete ying and yang. Correct?

Now I'm off to retrofit this to use smart pointer and examine the
behavior.

Thanks

[AnonMail2005]

The beauty of some smart pointers is that you don't have to delete
anything.

Take a look at, for instance, boost's shared_ptr. It keeps a reference
count of how many "share" the pointer. When it goes to zero it deletes
the object pointed to. You can pass the thing around, make copies, etc
and you never have to worry about deleting the thing that it points to.

Until you use them, you won't realize how a big concern of C++
programming - namely avoiding memory leaks - goes away.

ma740988 wrote:

Experimenting with smart pointers here but need a refresher here.

Consider the snippet:

# include <iostream>
# include <string>

using namespace std;

class ying {
public:
ying () {}
~ying() { cout << " deleted ying " << endl; }
void run_it()
{ cout << typeid(*this).name() << endl; }

ying& operator=(const ying& o )
{ cout << " op= ying " << endl;
return *this; }
ying(const ying& o )
{cout << " cc ying " << endl; }

};

class yang
{
public:
yang () {}
~yang() { cout << " deleted yang " << endl; }
yang& operator=(const yang& o )
{ cout << " op= yang " << endl;
return *this; }
yang(const yang& o )
{cout << " cc yang " << endl; }

void run_it()
{ cout << typeid(*this).name() << endl; }
};

class bar {
yang *ptr_ya;
ying *ptr_yi;
public:
bar ( yang* ptr1, ying* ptr2 )
: ptr_ya(ptr1)
, ptr_yi(ptr2)
{}

void test_yang() { ptr_ya->run_it(); }
void test_ying() { ptr_yi->run_it(); }

~bar() { delete ptr_ya; delete ptr_yi; }

};

int main()
{
yang *ptr_ya = new yang();
ying *ptr_yi = new ying();

bar b(ptr_ya, ptr_yi);
b.test_yang();
b.test_ying();

// no longer necessary. this is why we're better off with
// auto_ptrs (the smart 'pointer' stuff)
//delete ptr_ya;
//delete ptr_yi;

}

I've haven't retrofitted the source yet to use smart pointers,
nonetheless, simple question. The ying and yang objects are passed
(pass by pointer) to bar constructors. That said, it's bars
responsibility to delete ying and yang. Correct?

Now I'm off to retrofit this to use smart pointer and examine the
behavior.

Thanks

[Greg]

ma740988 wrote:

Experimenting with smart pointers here but need a refresher here.

Consider the snippet:

# include <iostream>
# include <string>

using namespace std;

class ying {
public:

};

class yang
{
public:
};

class bar {
yang *ptr_ya;
ying *ptr_yi;
public:
bar ( yang* ptr1, ying* ptr2 )
: ptr_ya(ptr1)
, ptr_yi(ptr2)
{}

void test_yang() { ptr_ya->run_it(); }
void test_ying() { ptr_yi->run_it(); }

~bar() { delete ptr_ya; delete ptr_yi; }

};

int main()
{
yang *ptr_ya = new yang();
ying *ptr_yi = new ying();

bar b(ptr_ya, ptr_yi);
b.test_yang();
b.test_ying();

// no longer necessary. this is why we're better off with
// auto_ptrs (the smart 'pointer' stuff)
//delete ptr_ya;
//delete ptr_yi;

}

I've haven't retrofitted the source yet to use smart pointers,
nonetheless, simple question. The ying and yang objects are passed
(pass by pointer) to bar constructors. That said, it's bars
responsibility to delete ying and yang. Correct?

Without some policy in place that we could apply to this situation that
wold tell us that bar now "owns" the pointers passed in its
constructor, then I would say the answer is "no": bar should not free
the pointers since it did not allocate them. Whichever class or
function allocated the memory has the responsibility for ensuring that
the memory is freed after it's no longer needed. The allocating code
"owns" the allocated memory, and that would be the function main in
this case.

Now, ownership of allocated memory can be transferred - but there has
to be a well-documented, consistently-followed convention to perform
such a transfer. It's not enough just to decide that bar owns the
pointers because we wrote the code that way. Memory management becomes
unmaintainable unless the API alone can tell us when a class or
function assumes ownership of passed in, allocated memory.

A smart pointer lets a block of allocated memory have multiple,
concurrent owners - and a smart pointer frees the allocated memory only
after it has no more owners left. Since ownership of a smart pointer
does not need to be transferred, any code can decide to "own" a smart
pointer, without having to coordinate the transfer from anywhere else.
So by simplifying the rules of memory ownership, smart pointers are not
only easier to use, they also reduce the likelihood of
memory-management related errors.

Greg

[ma740988]

An**********@gmail.com wrote:

The beauty of some smart pointers is that you don't have to delete
anything.

Take a look at, for instance, boost's shared_ptr. It keeps a reference
count of how many "share" the pointer. When it goes to zero it deletes
the object pointed to. You can pass the thing around, make copies, etc
and you never have to worry about deleting the thing that it points to.

Until you use them, you won't realize how a big concern of C++
programming - namely avoiding memory leaks - goes away.

That's where I'm headed. smart pointer. Actually, I was trying to
figure out reference counted smart versus just 'smart'. I think a
reference counted pointer would be better for what I've shown. This
way, I dont care which order I delete the objects. In essence - from
what I've seen with reference counted smart pointer - that object will
exist until the last one remain standing (i.e 'count' is now 1). Only
then will the object get destroyed

[mlimber]

Greg wrote:

Without some policy in place that we could apply to this situation that
wold tell us that bar now "owns" the pointers passed in its
constructor, then I would say the answer is "no": bar should not free
the pointers since it did not allocate them. Whichever class or
function allocated the memory has the responsibility for ensuring that
the memory is freed after it's no longer needed. The allocating code
"owns" the allocated memory, and that would be the function main in
this case.

Now, ownership of allocated memory can be transferred - but there has
to be a well-documented, consistently-followed convention to perform
such a transfer. It's not enough just to decide that bar owns the
pointers because we wrote the code that way. Memory management becomes
unmaintainable unless the API alone can tell us when a class or
function assumes ownership of passed in, allocated memory.
Agreed, and the standard convention for communicating that ownership is
transferred is to pass (or return) a std::auto_ptr.
A smart pointer lets a block of allocated memory have multiple,
concurrent owners - and a smart pointer frees the allocated memory only
after it has no more owners left. Since ownership of a smart pointer
does not need to be transferred, any code can decide to "own" a smart
pointer, without having to coordinate the transfer from anywhere else.
So by simplifying the rules of memory ownership, smart pointers are not
only easier to use, they also reduce the likelihood of
memory-management related errors.

Correction: a smart pointer with the semantics of boost::shared_ptr
does this (well, depending on what you mean by "concurrent"). A smart
pointer with different semantics (e.g., boost::scoped_ptr or
std::auto_ptr) does not do what you describe here.

Cheers! --M