Managing a reference object

This is a discussion on Managing a reference object within the C++ Programming forums, part of the General Programming Boards category; Following on a recent thread about exposing the aggregatee interface, I'm faced with a situation I'm not comfortable with and ...

  1. #1
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510

    Managing a reference object

    Following on a recent thread about exposing the aggregatee interface, I'm faced with a situation I'm not comfortable with and need your opinion.

    To bring you back on focus... I have a class CInventory that is a part of CBeing. It was decided then that CInventory would expose its interface through IInventory.

    Code:
    class IInventory { /*... */ }
    class CInventory: public IInventory { /* ... */ }
    CBeing has a CInventory. It exposes CInventory interface through IInventory. This allowed me to hide a small subset of the CInventory interface I didn't want visible to users of CBeing while still have CInventory fully available to the internals of CBeing.

    Code:
    class CBeing {
        public:
            /* ... */
            IInterface& Inventory() { return inv_; }
            const IInterface& Inventory() const { return inv_; }
       private:
            /* ... */
            CBeing& inv_;
    };
    And this is where the problems start. You see, I don't want to worry much about the management of the inv_ object. So, it's quiet easy for me to change the above to pointers to CBeing, allocating on the constructor and deallocating on the destructor.

    However the syntax I will be forcing on the user of CBeing is probably unnecessary. being.Inventory()->equip("sword"); is not pretty when I can have being.Inventory().equip("sword");.

    The problem is that the above reference forces me to define CBeing::inv_ on the constructor initializer list. I just think my code smells trouble here...

    Code:
    CBeing::CBeing(): inv_() {
        inv_.load_dat("00001");
    }
    The problem is that I really don't have an object to feed inv_ with. That object will be created with CBeing and destroyed with it.

    With pointers and allocation/deallocation I can solve this. But what can I do if I stick to references?
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #2
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    Doh!

    I don't need inv_ to be a reference! Am I silly or what?... (Don't answer)

    Took me a post to find that. When I couldn't after watering my eyes from so much looking at the code.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I'm having a deja vu here ...
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    It's actually very educational this type of problems. It keeps reminding me how little I know of C++. I think the hardest step is training my mind to it, not really learning the syntax.

    When I look at a reference, for instance, and don't need to manually activate a few brain cells,... then I'll be a happy camper
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #5
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    Quote Originally Posted by Mario F.
    Doh!

    I don't need inv_ to be a reference!
    Yeah, inv_ can internally be a CInventory object, that is probably the best way (assuming you don't want the Inventory to be created before the Being and then passed in as a constructor parameter).

    Of course you can return a reference even if you internally store the object as a pointer. return *inv_; would work.

    Probably easiest of all to just have CInventory inv_; though.

    You can return a reference regardless if you store the object as a reference, pointer, or object.
    Last edited by Cat; 11-23-2006 at 06:44 PM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How to maintain and return local object reference?
    By benshi in forum C++ Programming
    Replies: 14
    Last Post: 12-16-2007, 01:17 PM
  2. non-const reference and const reference
    By George2 in forum C++ Programming
    Replies: 3
    Last Post: 12-15-2007, 04:03 AM
  3. Question about OpenGL/Linux
    By Ideswa in forum Linux Programming
    Replies: 12
    Last Post: 09-10-2006, 05:56 AM
  4. Strange/false errors
    By Ganoosh in forum Windows Programming
    Replies: 8
    Last Post: 10-20-2005, 04:54 PM
  5. Beginners guide to OOP from a Java background?!
    By eggsy84 in forum C++ Programming
    Replies: 6
    Last Post: 06-08-2005, 06:13 AM

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