Classes Help!!!

Code:

---

class ParentClass
{
        public:
                ParentClass(string str_inputfile)
                {
                        // do stuff
                }
};

---

Code:

---

class ChildClass : public ParentClass
{
        public:
                ChildClass(string inputstr)
                {
                        // do stuff
                }
};

---

This gives me the errors:

Code:

---

main.cpp:417: error: no matching function for call to ‘ParentClass::ParentClass()’
main.cpp:345: note: candidates are: ParentClass::ParentClass(std::string)
main.cpp:343: note:                ParentClass::ParentClass(const ParentClass&)

---

What does it mean by "no matching function call" ?

So I have to redefine *every* function in a parent class to get inheritance working?? That's annoying

No. Rather, ParentClass does not have a default constructor. Therefore, all subclass constructors must invoke one of ParentClass' constructors in their initialisation lists, e.g.,

Code:

---

ChildClass(string inputstr) : ParentClass(inputstr)
{
    // do stuff
}

---

By the way, you may wish to pass std::string objects by const reference in this case.

Will this actually call the parent's constructor? The parent constructor is doing some stuff that I really don't want the child to be doing again hehe

Yes, it does. The initializer list directly calls a constructor of the mentioned object.

What kind of things does the base class do that you don't want the derived class doing? Maybe the base class constructor shouldn't do it either, or maybe it needs a default constructor?

Quote:

---

Originally Posted by Elysia

Yes, it does. The initializer list directly calls a constructor of the mentioned object.

---

Hmm, I see.

I guess I should modify it then. Thanks all =]

I changed some stuff around, and now I have this:

Code:

---

class GraphObj
{
        public:
                GraphObj(const string inputstr)
                {
                        line = inputstr;
                }

                //virtual ~GraphObj() = 0;

                virtual void draw(Image& img) = 0;
        private:
                string line;
};

---

And

Code:

---

class Line : public GraphObj
{
        public:
                Line(const string inputstr) : GraphObj(inputstr)
                {
                        line = inputstr;
                }

                //~Line() : ~GraphObj()
                //{
                //}

                void draw(Image& img)
                {
                        // do stuff
                }
        private:
                string line;
};

---

Two questions:

If I want to use inheritance, do I have to have the stuff in bold, or is it done automatically for me? (So I can delete it and the "line" variable will still be created / initialized)

Also, it gives me some warnings:

Code:

---

main.cpp:24: warning: ‘class GraphObj’ has virtual functions but non-virtual destructor
main.cpp:37: warning: ‘class Line’ has virtual functions but non-virtual destructor

---

I tried to add the destructor stuff in but I'm not sure if I'm doing it right (the stuff commented out), because it gives a bunch of nasty errors about linking...

I don't want to write a destructor for every one of my subclasses, but do I *have* to do it if I want to get rid of the warning?

Absolutely delete it.

The problem is that you need an implementation of a destructor, even if it's pure. Easier to not make it pure, since you have a pure function already. (The only reason to make a destructor pure is
to make a class abstract when it has no natural pure functions.)

Code:

---

virtual ~GraphObj() {}

---

You don't need to explicitly create a destructor in any of the derived classes.

Quote:

---

If I want to use inheritance, do I have to have the stuff in bold, or is it done automatically for me? (So I can delete it and the "line" variable will still be created / initialized)

---

Yes, though line will not be accessible to the derived class since it is private.

Quote:

---

I tried to add it in but I'm not sure if I'm doing it right.

---

You are correct to write:

Code:

---

virtual ~GraphObj() = 0;

---

But you still need to implement the base class destructor since it will be invoked by the derived class destructor:

Code:

---

GraphObj::~GraphObj() {}

---

The derived class destructor can be left out (since the compiler generated one will do). If you implement it, the syntax would be:

Code:

---

Line::~Line()
{
    // ...
}

---

Quote:

---

Originally Posted by CornedBee

Absolutely delete it.

The problem is that you need an implementation of a destructor, even if it's pure. Easier to not make it pure, since you have a pure function already. (The only reason to make a destructor pure is
to make a class abstract when it has no natural pure functions.)

Code:

---

virtual ~GraphObj() {}

---

You don't need to explicitly create a destructor in any of the derived classes.

---

Aha!

I commented it out and it gave an error since line was private, so I made it protected.

And then the destructor stuff, so I have:

Code:

---

class GraphObj
{
        public:
                GraphObj(const string inputstr)
                {
                        line = inputstr;
                }
                virtual ~GraphObj() {};
                virtual void draw(Image& img) = 0;
        protected:
                string line;
};

---

Code:

---

class Line : public GraphObj
{
        public:
                Line(const string inputstr) : GraphObj(inputstr)
                {
                }
                void draw(Image& img)
                {
                        // stuff
                }
};

---

No compile errors or warnings!!

Now, my constructor in Line is completely blank... Do I even need it? Looks odd...

Quote:

---

Originally Posted by laserlight

Yes, though line will not be accessible to the derived class since it is private.


You are correct to write:

Code:

---

virtual ~GraphObj() = 0;

---

But you still need to implement the base class destructor since it will be invoked by the derived class destructor:

Code:

---

GraphObj::~GraphObj() {}

---

The derived class destructor can be left out (since the compiler generated one will do). If you implement it, the syntax would be:

Code:

---

Line::~Line()
{
    // ...
}

---

---

What's the difference between doing:

virtual ~GraphObj() {};

or

GraphObj::~GraphObj() {};

in my base class?



Edit: hmm, nevermind, it gives the warning again about non-virtual functions with the 2nd method

Quote:

---

Originally Posted by Paul22000

What's the difference between doing:

Code:

---

                virtual ~GraphObj() {}

---

or

Code:

---

                GraphObj::~GraphObj() {}

---

in my base class?

---

The first can be put inline the actual class definition and the second is placed outside the definition, so called implementation. Other that that, there's nothing different about them.
And btw, drop the ";" after definitions (even if they're inline in the class definition).

Quote:

---

Edit: hmm, nevermind, it gives the warning again about non-virtual functions with the 2nd method

---

What warning is that again?

Quote:

---

Originally Posted by Elysia

The first can be put inline the actual class definition and the second is placed outside the definition, so called implementation. Other that that, there's nothing different about them.
And btw, drop the ";" after definitions (even if they're inline in the class definition).


What warning is that again?

---

The virtual functions thing

main.cpp:24: warning: ‘class GraphObj’ has virtual functions but non-virtual destructor
main.cpp:37: warning: ‘class Line’ has virtual functions but non-virtual destructor

Hmm, guess I'll just use the virtual destructor way heh. I never have to call it myself so whatever is easier hehe

-----

Which semicolon? After class definitions?

class Blah
{

};

If I remove it, it gives errors

Code:

---

main.cpp:271: error: multiple types in one declaration

---

Are you aware of the purpose of virtual functions, especially virtual destructors?
If you aren't doing anything special in the destructor, you can omit the virtual destructors and ignore the warnings, but as they say, if a class has virtual functions, then it is also recommended that they have a virtual destructor.

Quote:

---

What's the difference between doing:

virtual ~GraphObj() {};

or

GraphObj::~GraphObj() {};

in my base class?

---

Well the difference is really minor.

Code:

---

class Graph {
  public:
  virtual ~Graph() {
      // defined inside the class
  }
};

class Graph {
  public:
  virtual ~Graph();
};

Graph::~Graph() {
  // defined outside the class
}

---

I've heard that defining functions inside the class suggests inlining them to the compiler, but that shouldn't work much better than the inline keyword. I've typically treated class declarations as outlines of the implementation and rarely put the implementations in the class. This helps me separate implementation from the class design.

Quote:

---

Originally Posted by Elysia

Are you aware of the purpose of virtual functions, especially virtual destructors?

---

Not ~really~. All I know is that we have to have them.

After all this, I still don't know what virtual functions are for, but I do know *how* to use them now =]

And I can't get rid of the virtual destructor because we get marked down for warnings

Quote:

---

Originally Posted by citizen

I've typically treated class declarations as outlines of the implementation and rarely put the implementations in the class. This helps me separate implementation from the class design.

---

Yes, it also helps when you want to modify the definition and if you just want to scan the definition, as well. Separating the two almost always results in advantages.

Quote:

---

Originally Posted by Paul22000

Not ~really~. All I know is that we have to have them.

---

Virtual functions allow the compiler at run-time to what type of object it is that you're calling a function on. By doing this, it is possible to derive several classes from a common base class, and then call a virtual function inside the base class, and the compiler will actually call the same virtual function in the correct derived class:

Code:

---

class CBase { public: virtual void foo() { cout << "Base\n"; } };
class CDerived1: public CBase { public: virtual void foo() { cout << "Derived1\n"; } };
class CDerived2: public CBase { public: virtual void foo() { cout << "Derived2\n"; } };

void foo(CBase& r)
{
    r.foo();
}

int main()
{
    CBase b;
    CDerived1 d1;
    CDerived2 d2;
    foo(b); // Prints "Base"
    foo(d1); // Prints "Derived1"
    foo(d2); // Prints "Derived2"
}

---

Consequently, the destructor is no different. The destructor is called when invoking delete on a pointer, so the correct destructor will be called (imagine renaming class member function foo to the destructor and changing the function foo to take a pointer (allocated with new) and calling delete inside).

Quote:

---

And I can't get rid of the virtual destructor because we get marked down for warnings

---

Fair enough. It's recommended you have a virtual destructor for classes that contains virtual functions.

Quote:

---

Originally Posted by Elysia

Virtual functions allow the compiler at run-time to what type of object it is that you're calling a function on. By doing this, it is possible to derive several classes from a common base class, and then call a virtual function inside the base class, and the compiler will actually call the same virtual function in the correct derived class:

---

Ahhh, that makes sense!

Quote:

---

Originally Posted by Elysia

It's recommended you have a virtual destructor for classes that contains virtual functions.

---

What's the downside to leaving it like it is?

I have in the parent class:

Code:

---

virtual ~GraphObj() {};

---

And that's it. Nothing in the base classes.

You can just as well remove it because it serves no purpose.
But if you don't want the warning, you can just leave it empty.

Quote:

---

What's the downside to leaving it like it is?

---

Read this FAQ on When should my destructor be virtual?

Quote:

---

Nothing in the base classes.

---

Careful. "base class" and "parent class" are synonyms. The opposite is "derived" or "child class".

Quote:

---

Originally Posted by Elysia

You can just as well remove it because it serves no purpose.

---

I think this is rather dangerous advice to give to someone who admits to "not ~really~" understanding virtual functions.

Code:

---

Base *p = new Derived();
delete p;

---

If Base doesn't have a virtual destructor, then ~Base gets called but ~Derived doesn't. Even if your ~Base doesn't do anything useful, someone else deriving from your Base might have a ~Derived which does, expecting it to be called.

Compilers generate this warning because if your class has virtual functions, it is apparently intended to be derived from.

--
Computer Programming: An Introduction for the Scientifically Inclined

Quote:

---

If Base doesn't have a virtual destructor, then ~Base gets called but ~Derived doesn't.

---

In practice, yes, though by the rules of the C++ Standard it just results in undefined behaviour.

And with multiple inheritance, it might well crash if you don't give it a virtual destructor:

Code:

---

struct B1
{
  int d1, d2, d3;
  ~B1() {}
};

struct B2
{
  int e1, e2, e3;
  ~B2() {}
};

struct D : B1, B2
{
  int f1, f2, f3;
};

int main()
{
  B2 *b2 = new D;
  delete b2;
}

---

Crashes on GCC:
*** glibc detected *** ./multip: free(): invalid pointer: 0x000000000060201c ***

The reason is that in GCC's internal model, the destructor returns a pointer to the actual start of the object, and that is passed to operator delete. If the destructor is not virtual, then you get the pointer to the B2 subobject, which is not the start of the object, and thus an address free() can't handle.