which design is better to wrap another class instance

Hello everyone,


Some people doubt that the design below is inferior compared to design which makes f, either Foo* or Foo&. The reason is below design will waste memory space and degrade performance by creating a new instance.

I think it depends. If we really needs to wrap a new instance, I think the following design is fine. If we needs to refers to an existing instance, this design is inferior because it will waste memory space and degrade performance by creating a new instance and destroy the original one.

Code:

class Foo;

class Goo
{
    Foo f; // change to Foo* pf or Foo& rf is always better?
}

thanks in advance,
George

I think your question is too general.
There are numerous cases either way where it only makes sense to choose one option or the other, and also many cases where it really doesn't matter.
I don't think you'll get a useful answer without being more specific.

If we really needs to wrap a new instance, I think the following design is fine.

Yes. Basically, it says that each Goo object owns a Foo object. If you want each Goo object to own a Foo object that may actually be of a type derived from Foo, then you should store a std::tr1::shared_ptr, a std::auto_ptr or a raw pointer to Foo instead so that polymorphism will work. If you use a std::auto_ptr, then your Goo object will not have normal copying semantics. If you use a raw pointer, then you should implement the copy constructor, copy assignment operator and destructor appropriately.

If we needs to refers to an existing instance, this design is inferior because it will waste memory space and degrade performance by creating a new instance and destroy the original one.

If you need to refer to an existing instance, this "design" will not even work. You should store a reference, std::tr1::weak_ptr, or a raw pointer to the existing Foo object instead. If you use a raw pointer, then you run the risk of trying to access a non-existent object.

As you noted, "it depends".

Thanks laserlight,


1.

I am interested to see how to use auto_ptr to achieve the effect of polynorphism. I have written the below code, do you think it is correct to demo this feature?

If yes, I think when we call pb->f(), the conversion operator of auto_ptr converts auto_ptr<Base> type to Base* type? My confusion is I have not seen auto_ptr has such a conversion operator to do such work. :-)

Code:

#include <iostream>
#include <memory>

using namespace std;

class Base
{
public:
	virtual void f()
	{
		cout << "Base" << endl;
	}
};

class Derived : public Base
{
public:
	virtual void f()
	{
		cout << "Derived" << endl;
	}
};

int main()
{
	auto_ptr<Base> pb (new Derived);
	pb->f(); // display derived

	return 0;
}

2.

How do you define own another component? Manage the life cycle (responsible for creating and destroying)? Or have some other points?

Originally Posted by laserlight

Yes. Basically, it says that each Goo object owns a Foo object. If you want each Goo object to own a Foo object that may actually be of a type derived from Foo, then you should store a std::tr1::shared_ptr, a std::auto_ptr or a raw pointer to Foo instead so that polymorphism will work. If you use a std::auto_ptr, then your Goo object will not have normal copying semantics. If you use a raw pointer, then you should implement the copy constructor, copy assignment operator and destructor appropriately.


If you need to refer to an existing instance, this "design" will not even work. You should store a reference, std::tr1::weak_ptr, or a raw pointer to the existing Foo object instead. If you use a raw pointer, then you run the risk of trying to access a non-existent object.

As you noted, "it depends".

regards,
George

I have written the below code, do you think it is correct to demo this feature?

Almost, since you forgot to make the Base destructor virtual.

If yes, I think when we call pb->f(), the conversion operator of auto_ptr converts auto_ptr<Base> type to Base* type? My confusion is I have not seen auto_ptr has such a conversion operator to do such work.

Take a look at the overloaded operator-> of auto_ptr.

How do you define own another component? Manage the life cycle (responsible for creating and destroying)?

Yes, though the actual responsibility of managing the life cycle may be delegated to say, a smart pointer. Basically, I have composition in mind.

Thanks laserlight,

Originally Posted by laserlight

Yes, though the actual responsibility of managing the life cycle may be delegated to say, a smart pointer. Basically, I have composition in mind.

Beyond managing the lifecycle of an object, do you have any other perspective of what means "owns" another object? :-)


regards,
George

Originally Posted by George2

Beyond managing the lifecycle of an object, do you have any other perspective of what means "owns" another object? :-)

That is essentially all that ownership means.

Thanks brewbuck,

Originally Posted by brewbuck

That is essentially all that ownership means.

regards,
George