which design is better to wrap another class instance

This is a discussion on which design is better to wrap another class instance within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, Some people doubt that the design below is inferior compared to design which makes f, either Foo* or ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    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

  2. #2
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,261
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    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".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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?

    Quote Originally Posted by laserlight View Post
    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

  5. #5
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #6
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight,


    Quote Originally Posted by laserlight View Post
    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

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by George2 View Post
    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.

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks brewbuck,


    Quote Originally Posted by brewbuck View Post
    That is essentially all that ownership means.

    regards,
    George

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. what design patter let me reuse this class?
    By patiobarbecue in forum C++ Programming
    Replies: 4
    Last Post: 04-29-2009, 01:44 PM
  2. Create instance on class programatically
    By deviousdexter in forum C# Programming
    Replies: 6
    Last Post: 12-10-2008, 05:02 PM
  3. question about class design and overloading
    By l2u in forum C++ Programming
    Replies: 7
    Last Post: 12-13-2007, 01:02 PM
  4. Difficulty superclassing EDIT window class
    By cDir in forum Windows Programming
    Replies: 7
    Last Post: 02-21-2002, 04:06 PM
  5. class design and operation overload
    By Unregistered in forum C++ Programming
    Replies: 1
    Last Post: 12-03-2001, 09:49 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21