Problem with pointers to dynamic objects

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

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?

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
{
    // ...
};

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.

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.

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.

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]

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?

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.

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"?

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.

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.

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.

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.

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.

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.