Problem with pointers to dynamic objects

This is a discussion on Problem with pointers to dynamic objects within the C++ Programming forums, part of the General Programming Boards category; Hi, I'm writing a program for an assignment at the moment requiring inheritance and dynamic objects. Originally Posted by Part ...

  1. #1
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218

    Problem with pointers to dynamic objects

    Hi, I'm writing a program for an assignment at the moment requiring inheritance and dynamic objects.

    Quote Originally Posted by Part of the program spec
    Add a member attribute which is a pointer to a potential dynamic object of class Guest
    I'm having problems working out how to declare a pointer in the class rooms. Neither my notes, or my teacher seem to be able to tell me how to do this.

    Heres my classes:
    Code:
    class rooms
    {
        private:
            int number;
            float cost;
            guests *p;  //This wont work
        public:
            rooms();
            ~rooms();
            int GetNumber();
            float GetCost();
            void SetNumber(int);
            void SetCost(float);
            void AddGuest();
    };      
    
    class guests : rooms //guests are derived from rooms
    {
        private:
            char surname[10];
            int bill;  
        public:
            guests();
            ~guests();
            void EndGuest();
            char* GetName();
            void AddCharge(int);
            float GetBill();         
    };
    When i compile I get an error message saying that I cant declare 'guests' without a type. How then would I declare a pointer in an object, or is this all just plain wrong?

  2. #2
    Registered User
    Join Date
    Apr 2007
    Location
    Sweden
    Posts
    41
    If your teacher doesn't know how to do a forward declaration, he/she shouldn't teach C++.

    Code:
    class guests;
    
    class rooms
    {
        // ...
    };
    
    class guests : rooms
    {
        // ...
    };

  3. #3
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    Why is a guest derived from a room? A guest isn't a room, a room contains one or more guests. You should be using containment instead of inheritance:
    Code:
    class Guest {
    };
    
    
    class Room {
      Guest *_guest;
    };
    Yeah, I know you're using private inheritance and all of that, but it's still not intuitive.

  4. #4
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    Thanks for the help guys.

    A guest isn't a room, a room contains one or more guests.
    You would think so. But the assignment only requires one guest that the room is booked in the name of. Its a bit of a pointless specification since you may as well just have extra fields in the room that hold the guest data, but its all for the sake of learning I suppose.

  5. #5
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    But the assignment only requires one guest that the room is booked in the name of.
    That's not a good reason. Inheritance is a bad solution for this, whether the requirements only assume one guest or not. Especially when the requirements change to allow more than one guest. But my point is that you're not using inheritance in a sensible way. Inheritance is used to give the child class the same interface as the parent class. A guest doesn't have the same interface as a room for any reasonable definition of guest and room that I can think of. This is something I would expect to see:
    Code:
    class Guest { }; // concrete
    
    class Room { }; // abstract
    class DoubleRoom: public Room { }; // concrete
    class QueenRoom: public Room { }; // concrete
    class KingRoom: public Room { }; // concrete
    Each concrete room contains a list of guests, and you use inheritance to create the slightly different rooms that the hotel has, like a room with two double beds, a room with a queen bed, and a room with a king bed.

  6. #6
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    What you are saying makes sense, but its out of the spec and going on past experience doing something like that will probably get me marked down on it. Even if it is better.

    Basically at the start of the prog I run the rooms constructor function to create 10 of them. The only detail a room has, its cost, is hard coded. Then when a guest checks in I create a guest object linked to the room, when the guest checks out the guest gets destroyed.

    Yep the prog stinks, but its what I have got to do.

    [edit]I don't really get the need for inheritance, but it says that I have to use it here.[/edit]
    Last edited by mike_g; 04-25-2007 at 09:20 AM.

  7. #7
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Does it specifically say that you have to derive a Guest from a Room?

    So, you initially create a Room. To put the Guest in it, you create a Guest (which at the same time means creating a Room). And when the Guest leaves, you destroy it, together with a Room but not the Room it was visiting? Does this sound absurd?

  8. #8
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    Yes, very. It seems that whoever came up with the assignment was unable to think of a practical situation for us to demonstrate the use of inheritance.

  9. #9
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    What you are saying makes sense, but its out of the spec
    Well why didn't you say so instead of coming up with a weak argument like "the assignment only requires one guest that the room is booked in the name of"?

  10. #10
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    Inheritance is used to give the child class the same interface as the parent class.
    Public inheritance is used to give a child class the same interface as the parent class. Consequently, the above class hierarchy does not express: a guest is-a room. It expresses: a guest is-implemented-in-terms-of a room. That said, it is still true that composition is better here. Oh well.
    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

  11. #11
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    Public inheritance implements the child in terms of the public interface. Private inheritance does the same thing but with a different interface, it implements the child in terms of the private interface.
    Consequently, the above class hierarchy does not express: a guest is-a room. It expresses: a guest is-implemented-in-terms-of a room.
    And what's the difference? A room still defines how a guest works. You can use whatever terms you want, but the effect is the same.

  12. #12
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    Public inheritance implements the child in terms of the public interface. Private inheritance does the same thing but with a different interface, it implements the child in terms of the private interface.
    I would argue that with respect to the class user, the private interface is not an interface at all, but merely implementation detail.

    And what's the difference? A room still defines how a guest works. You can use whatever terms you want, but the effect is the same.
    Not quite, since polymorphism no longer works.
    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

  13. #13
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    I would argue that with respect to the class user, the private interface is not an interface at all, but merely implementation detail.
    It's the interface for the child's implementation. That's not a hard thing to imagine, right?
    Not quite, since polymorphism no longer works.
    Fair enough, but that still doesn't change the fact that the parent class, inherited publicly or privately, defines the child class. You can call it "is-implemented-in-terms-of" instead of "is-a", but that's really no different from taking a pile of dung and calling it a flower bed. You just change the label, not what the thing really is.

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    It's the interface for the child's implementation. That's not a hard thing to imagine, right?
    I know what you mean (i.e., you are looking at it from the perspective of the child class implementer), but then you should have said what you mean. After all, looking at the child class interface means looking at its public interface, without caring about its implementation. Should I say encapsulation? We seem to have brought up all the main OOP marketing terms except abstraction, but I just did that

    Fair enough, but that still doesn't change the fact that the parent class, inherited publicly or privately, defines the child class. You can call it "is-implemented-in-terms-of" instead of "is-a", but that's really no different from taking a pile of dung and calling it a flower bed. You just change the label, not what the thing really is.
    I think that there really is a conceptual difference. Consider other object oriented programming languages such as Java, for example, which does not have private inheritance (or protected inheritance, for that matter). In such a language, inheritance really does always express an is-a relationship, and I believe that is the general model of inheritance in OOP, since inheritance and polymorphism are so closely related. So, to properly talk about inheritance in the same sense, C++ programmers should talk about public inheritance, not private inheritance.
    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

  15. #15
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Public and private inheritance share pretty much nothing, conceptually. Public inheritance is a subtype relationship requiring substitutability. To put it in terms of Coplien, it's a form of positive variance. Public bases are part of the interface of a class.
    Private inheritance is strictly an implementation detail. It is absolutely no business of any other code that a class privately inherits something. Private inheritance is merely a convenience over containment and implementation in terms of a single subobject.
    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

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem with malloc and pointers to pointers
    By mike_g in forum C Programming
    Replies: 7
    Last Post: 03-29-2008, 06:03 PM
  2. Problem with Vectors And Pointers
    By Shamino in forum Game Programming
    Replies: 3
    Last Post: 01-21-2006, 06:23 PM
  3. very weird problem (pointers I think)
    By hannibar in forum C Programming
    Replies: 2
    Last Post: 10-11-2005, 06:45 AM
  4. two-dimensional dynamic array of pointers to classes
    By Timo002 in forum C++ Programming
    Replies: 4
    Last Post: 04-21-2005, 06:18 AM
  5. problem , need pointers. thanks
    By mobius in forum C Programming
    Replies: 4
    Last Post: 09-03-2001, 05:12 AM

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