Bungled Inheritence: Layered Constructors

I'm *positive* someone has asked this before...but I couldn't find it in the search, sorry, so I'm asking again.

I have a base class called Object, with the following constructor:

Object.cpp:

Code:

---

Object::Object()
{
        burnable = false;
        edible = false;
        equipable = false;
        wearable = false;
                       
        keyID = -1;  // not a key
        lockID = -1; // not a lock
       
        name = "New Object.";
        floorDescription = "A dusty new object lies on the floor.";
}

---

All those variables that are modified there are PRIVATE Object variables.

Now, I have a class Container, which is an extention of Object. I do the following:

Container.h:

Code:

---

class Container : public Object

---

Container.cpp:

Code:

---

Container::Container()
{
        Container::Object();
       
        floorDescription = "You spy a new container lies here.";
        name = "New Container";
        isOpen = false;       
}

---

This is to avoid resetting all the params to default values again in the Container constrcturo. This works fine, except when I try to modify floorDescription and name (private fields in Object class), I get the following errors:

std::string Object::floorDescription' is private Object.h

std::string Object::name' is private Object.h

Any ideas?

I may be wrong but I don't think derived classes will inherit private members of base, I think you can use the protected key word for this.

Quote:

---

Originally posted by HybridM
I may be wrong but I don't think derived classes will inherit private members of base, I think you can use the protected key word for this.

---

Correct. Derived classes only inherit public members and methods.

Quzah.

Ahhhhhhh, I knew it was something absurdly simple! Thanks!

Three ideas:

1) You don't need the line Container::Object(); The base class constructor is called automatically. In this case that is all you need since there are no arguments for your constructor.

2) All member variables that are private cannot be accessed by derived classes. If you want to allow them to be accessed by derived classes but not be other classes then you would make them protected. Some people would say that making member variables protected is indicative of a design flaw, but for the purposes of your problem that would fix it.

Quote:

---

Originally posted by quzah
Derived classes only inherit public members and methods

---

You meant protected, not public, right?

3) Just a side note, a better way to initialize those variables could be like this (assuming all are declared protected):

Code:

---

Object::Object() : burnable(false),
        edible(false),
        equipable(false),
        wearable(false),
        keyID(-1),  // not a key
        lockID(-1) // not a lock
        name("New Object."),
        floorDescription("A dusty new object lies on the floor.")
{
}

---

Hmm, I never knew you could do that...thanks, I'll try it.

Ahhh, awesome, it works, minus the following constructer, which gives me a "Parse error before { token":

Code:

---

Room::Room(string newDesc, int newNorth, int newEast, int newSouth, int newWest, int newTop, int newBottom) :

        description(newDesc),       
        northRoom(newNorth),
        eastRoom(newEast),
        southRoom(newSouth),
        westRoom(newWest),
        topRoom(newTop),
        bottomRoom(newBottom),
{
}

---

This notation is new to me...I like it, but I don't quite understand it...

Remove the comma at the end of bottomRoom(newBottom), to get rid of the parse error.

Its called an intialization list. You can search for more information or somebody who has more time/knowledge can give you detailed information. I would guess there is already good info about them in this forum.

Quote:

---

Originally posted by jlou
You meant protected, not public, right?

---

No. I ment public:

Code:

---

class Foo {
    public:
        void Fooie( void )
        {
            cout << "Fooie " << endl;
        }
};

class Bar : public Foo {
    public:
        void ReBar( void )
        {
            Fooie( );
            cout << " Bar!" << endl;
        }
};

Bar b;
b.ReBar( );

---

See?

Quzah.

Ach, so embarrased..can't believe I missed that comma.

Derived classes inherit protected fields too, I think, is what the guy was trying to say...

Yeah. It would have been best said, "They do not inherit private members and methods.", I suppose.

Quzah.

Quote:

---

Originally posted by quzah
Correct. Derived classes only inherit public members and methods.

---

Yes, my wording was wrong also. I meant to say that in addition to public members and methods, derived classes also inherit protected members and methods.

Code:

---

class Foo {
    protected:
        void Fooie( void )
        {
            cout << "Fooie " << endl;
        }
};

---

would work.

why are classes using protected supposedly badly designed?

What I meant was not that using protected is bad design, but rather that making base class member variables protected might be considered bad design.

I actually do that all the time, but there are some who say that in perfectly designed object oriented code, data should be encapsulated. This includes hiding base class data from derived classes and only exposing access methods for the data that should be allowed to be modified or seen by the derived classes.

I'm sorry I can't provide a reference to a book or article that makes that declaration. Like I said, I break that "rule" all the time because in my coding situations I'd rather be able to code quickly than take the time to follow perfect OOP techniques. To me this case is a VERY trivial issue. There are so many other ways that I and other programmers can improve design. I just mentioned it because I didn't want to blindly recommend something that might be considered bad design.

Protected isn't bad. Protected is just bad *for variables*. Herb Sutter has asserted that variables should never be anything other than private (with the exception of the public variables forming struct-like classes which do nothing more than bundle data togather, and have no methods). Protected should be used for methods and methods alone, just like public.

The reason is thus: methods are your interface, variables are your implementation, and NOTHING outside of the class, not even child classes, should have direct access to the implementation. Everything outside of the class itself* should access the class only through its interface, be it a public or protected interface.

If you want the child to be able to modify properties that others can't, use protected member functions. Not protected variables.

* Note: functions designed to operate on a class, and bundled with that class, count as part of the class itself. An example is a friend ostream & operator << (ostream &o, const MyClass & c). Even though it's not in the body of the class, for all intents and purposes, it is a part of the class's public interface. It is part of the implementation of the class.

I don't understand why not make all functions public then...I mean protected makes it inherited and public does :confused: whats the difference?

JaWiB, protected members are inherited as private and public as public in the derived.

I'm still a little confused though, if Derived classes shouldn't inherit base variables, then what are derived classes used for if you have to redeclare all the variables?

Not sure if this answers your question...

Code:

---

class foo
{
  public:
    foo();
    virtual ~foo();
  protected:
    void doSomethingelse();
};

class bar : public foo
{
  public:
    bar();
    ~bar();
};

int main()
{
  foo f;
  bar b;

  f.doSomethingelse();  // doesnt work
  b.doSomethingelse();  // works fine
}

---

Code:

---

class BaseClass
{
public:
    BaseClass() : m_data(0) { }
    ~BaseClass() { }
    int GetData() { return m_data; }  // Allow anybody to get the data
protected:
    void SetData(int data)  // Only allow derived classes to set data
private:
    void DoSomethingWhenDataIsSet();
    int m_data;
};

void BaseClass::SetData(int newData)
{
    m_data = newData;
    DoSomethingWhenDataIsSet();
}

---

Here, any derived class can set the data, but because the variable is private and the SetData method is protected, the implementation of setting m_Data is kept hidden from derived classes. If m_Data itself was protected, derived classes might fail to call DoSomethingWhenDataIsSet() when they set m_Data.

Also, like laasunde's example shows, since SetData is protected and not public, users of the class or any of its derived classes can never set the data. They can only get it.

Quote:

---

Originally posted by HybridM
JaWiB, protected members are inherited as private and public as public in the derived.

I'm still a little confused though, if Derived classes shouldn't inherit base variables, then what are derived classes used for if you have to redeclare all the variables?

---

You're not supposed to redeclare any variables. The information you store in the base class should be accessed and altered by its methods only. The variables still exist and ARE inherited, they're just not *accessible* directly in the derived class. They ARE accessible indirectly, through any accessible methods inherited from the base. Because all variables (implementation) should only be indirectly accessible through methods (interface), making them private is perfect.

jlou shows one good example of this.

ahh I see, thanks Cat.

I sense some confusion here regarding inheritance. ;)

Quote:

---

Originally posted by HybridM
JaWiB, protected members are inherited as private and public as public in the derived.

---

False.
Actually, when you declare an inherited (or child) class, you can specify the inheritance as well:
class ChildClass : [visibility_specificator] BaseClass
{
// declare member functions and variables
}

There are three cases:
1.) class ChildClass : public BaseClass
All public and protected members of the BaseClass will become public and protected in the ChildClass;

2.) class ChildClass : protected BaseClass
All public and protected members of the BaseClass will become protected in the ChildClass;

3.) class ChildClass : private BaseClass
All public and protected members of the BaseClass will become private in the ChildClass.

If you don't specify a visibility_specificator, this is considered by default:
- private for classes
- public for structs

When you create an object of the class, only public members will be accessible.

Quote:

---

Originally posted by JaWiB
I don't understand why not make all functions public then...I mean protected makes it inherited and public does whats the difference?

---

Protected members are not accessible when you create an object of the given class. Visibility or inheritance specificator protected is useful for inheritance only. So, you can still use base class members in the child class, but they are hidden when you create an object of the given class.

Also, as a note, protected and private base classes are different than public; in general they form a has-a relationship, not an is-a. For example, class Mercedes can publically derive from Car, because a Mercedes is-a car. Car *might* privately derive from Engine (a car has-a(n) engine), but it's often better to simply use a private member variable.

I also don't like the term "visibility specifier"; I'd prefer "access specifier". Private and protected methods are still VISIBLE, they still participate in name resolution, they are just not ACCESSIBLE.

An example:

Code:

---

class C{
public:
  void f(double d);
private:
  void f(int i);
};

int main(){
  C myC;
  int i;
  myC.f(i); // this is an error.
}

---

In the above code, main() can still *see* the existence of "void f(int i);", and it chooses that as the best match. main() does NOT have access to it, though, so it errors on compilation.

If the levels actually controlled visibility, myC.f(i) should call void myC.f(double) because it would be the only one the compiler could "see".

Yeah, I was a bit confused, I'm going to read up on it.

I'm going to have to go with carlos' examples...you guys almost confused me there...nice try

Quote:

---

Originally posted by Cat
Also, as a note, protected and private base classes are different than public;

---

This statement might cause confusion.
What do you mean? A base class cannot be public, protected, or private, it can have such members.
A base class is a base class - you can create child classes, specifying an access (or visibility) specificator - (see my previous reply for details.

Quote:

---

Originally posted by Cat
I also don't like the term "visibility specifier"; I'd prefer "access specifier". Private and protected methods are still VISIBLE, they still participate in name resolution, they are just not ACCESSIBLE.

---

I admit this one, I used the term visibility specificator as a consequence of "casting" from hungarian to english :D.

An advice to all of you who just started to learn C++ / Object Oriented approach: buy some good books, search the MSDN whenever a question arises, never let problems unclear.

Start projects by your own, as coding is an art, and a well designed, nice structured source code is a piece of art!

Quote:

---

Originally posted by Carlos
This statement might cause confusion.
What do you mean? A base class cannot be public, protected, or private, it can have such members.
A base class is a base class - you can create child classes, specifying an access (or visibility) specificator - (see my previous reply for details.

---

I think Cat was refering to public, protected & private inheritance....in that case there is a difference.

It's mainly a difference in how you inherit a base class's functionality......public inheritance is used for an "is a" situation - like a dog is an animal etc......, but private iheritance can be used if the derived class is not strictly a type of a base class - kind of like layering, but private inheritance allows you to take advantage of virtual functions where layering doesnt

Yes, I quess he intended to speak about inheritance, but following statement is somehow missleading (especially for a newbie), isn't it:
"Also, as a note, protected and private base classes are different than public".

Besides, this comment was a bit redundant, as I presented (at least tried to:)) in my reply all kinds of inheritances...