Is this bad object design?

[phalaris_trip]

Let's say I'm sure that one of my base classes will never be instantiated, so I decide to make it abstract. But at the same time all of its functions have definitions because they're common to all derived classes (e.g. Physics() will be the same regardless).

So I know that it should be abstact (infact it would probably crash the program if it was created) and yet there are no functions which I can declare as abstract..

So the only thing I can do is something stupid like:
void lol() = 0;

But then I have to derive that in all my other classes. This seems like a bad idea..
So should I redesign the class? Or should I remove the abstractness?

[Ancient Dragon]

Only make the class abstract (meaning with pure virtual functions) if there is a reason to do that. Don't create a pure virtual function just for the sake of making it an abscract class. There are thousands of base classes that do not contain pure virtual functions.

[Ezzaral]

If the program would crash if you used the base class on it's own, then it sounds like some required function of the class remains unspecified. If child classes provide that necessary functionality then the methods to do so should be abstract. Without knowing what additional functions the child classes are providing it's difficult to give a definitive answer.

If the base class can be used on it's own then it does not need to be abstract at all, as AD pointed out.

[Narue]

>This seems like a bad idea..
Yea, that's a really bad idea.

>So should I redesign the class?
No, this is a common problem and there's a common solution. Make the destructor pure virtual, but you still have to give it a body unless you want all of the child classes to not be able to be instantiated as well. ;)

[phalaris_trip]

If the program would crash if you used the base class on it's own, then it sounds like some required function of the class remains unspecified. If child classes provide that necessary functionality then the methods to do so should be abstract. Without knowing what additional functions the child classes are providing it's difficult to give a definitive answer.

If the base class can be used on it's own then it does not need to be abstract at all, as AD pointed out.

I think I see what you mean, but I don't know what additional functionality the child classes might have.. it's always going to be something that Animal does not have though. I might not even know now what child classes there are. I just want to lay down a framework of common factors to build upon.

So if I'm making
class Elk : public Animal,
I don't want to declare
virtual RubAntlersAgainstPineTrees() = 0;
in Animal.

>This seems like a bad idea..
Yea, that's a really bad idea.

>So should I redesign the class?
No, this is a common problem and there's a common solution. Make the destructor pure virtual, but you still have to give it a body unless you want all of the child classes to not be able to be instantiated as well. ;)

Doh, I'm lost now.. how can I give it a body if it's pure virtual?

I tried declaring virtual ~CBase() = 0; but now I'm getting unresolved external errors mentioning the destructor.. so I'm doing something totally wrong?

EDIT: If it makes a difference, I don't have any prototypes. All my classes are inline inside their .h file..

[Narue]

>how can I give it a body if it's pure virtual?
The same way you give it a body if it's not:

class base {
public:
    virtual ~base() = 0;
};

base::~base()
{
}

Or if you like to be concise:

class base {
public:
    virtual ~base() = 0 {}
};

This is assuming that the destructor doesn't do anything, of course.

[phalaris_trip]

Or if you like to be concise:

class base {
public:
    virtual ~base() = 0 {}
};

This is assuming that the destructor doesn't do anything, of course.

Yep, that did the trick. I didn't know you could do that...

Thanks a bunch everyone..