Inheritance

[rohitbhageria]

How to make a class non-inheritable but still create objects of that
class ?

[jayostu]

hi !!!
i don't know whether is there any good mechanism in c++ to achieve this (as final in java) but you can get the same thing done by this way
first make the constructor as private now this won't allow any other class to inherit that class and if u want other classes to create the objects provide one static method for that



here is the example of the same

#include <iostream.h>

class Base
{
private:
Base()
{

}

public :
static Base ConstructorBase()
{
Base a1;
return a1;
}
void fun()
{
cout<<"in base fun";
}
};


class Der ublic Base
{
public :
// error
/*
Der()
{

}
*/

};

void main()
{
Base *aObj=& Base::ConstructorBase();
aObj->fun();

delete aObj;

}

jayostu

[cup]

How about

class
{
public:
    ...
} object1, object2, object3;

You cannot inherit from it if you don't give it a name. The only problem with this is it only has a default constructor. The following does not work: you can still inherit from a typedef. Something I only just found out.

typedef class
{
public:
    ...
} Sterile;

[Zeeshan]

Here is a simple technique which i have already post on codeguru in VC programming forum.

class temp
{
private:
    temp() { };
    friend class MyClass;
};

class MyClass : virtual public temp
{
    // do whatever you want
};

Now MyClass become a final class, i.e. you can make object of this but cant inherit class from it.

Hope it helps.

[jayostu]

hi all !!!
i think all of us want to tell one thing that is make the constructor private. later things are as per ur choice whether should make a static function or again a new class
bye
jayostu

[Graham]

Why bother? You should only inherit publicly from a class that has been designed for public inheritance - that is, it has a virtual destructor and (probably) one or more virtual functions. Yes, you can prevent it by making the constructor private, but that ties you to heap-based allocation of your objects. Look at the STL - none of the container classes are designed to be publicly inherited from, so you just don't do it. Too much is made of public inheritance in OO programming - it's just one aspect, and not a major one at that. Personally, I wouldn't take any special steps to prevent public inheritance from a class. Special steps are taken to allow public inheritance. If someone does decide to inherit from a class that's not designed for it, then they will suffer the problems of doing something that they shouldn't. Why should I limit my (and others) options just to molly-coddle the occasional idiot who should know better?

Rant over.

[jfaust]

just to molly-coddle the occasional idiot

Wow, I can actually feel my vocabulary expanding! I can't wait to use this one!

Although I mostly agree with you, Graham, but it is not obvious to most programmers (read "occasional idiot") that a non-virtual destructor means that the class should not be inherited from. It makes sense after some thought, but it is easy to miss, and you really do need to actively look for it. I didn't make this connection until I started using STL, when the very first thing I did was inherit from a container. Not to worry: my use of STL has since improved.

Also, the class in question may look like a class that would be nice to inherit from. It may be tempting. It's better to have rules enforced by the compiler. It makes the "occasional idiot" walk down the hall and ask what's going on.

That aside, I agree that it's probably not worth limiting the use of the class in order to prevent inheritance unless that inheritance would cause a specific problem.

I would like to see compilers warn against inheriting from a class with a non-virtual destructor. This sounds like something easy enough to implement.

Jeff

[Graham]

Jeff - if you want to expand your vocabulary a bit more, then "pillock" is my favourite alternative for "idiot". American friends of mine became quite enamoured of that word after I first used it (I think I was referring to D. Quayle at the time).

I quite like the idea of a warning when publicly inheriting from a class with a non-virtual destructor (no problem if privately inheriting). After all, VC++ gives us that pointless "use of 'this' in an initializer list" warning, so why not something useful?

I still think, though, that it comes down to changing people's attitudes to what OO actually means. Inheritance is not the first tool of OO that you should reach for. And, if you do think "oh, that's nice class, I wonder if I can inherit from it?", I would say: resist and consider long and hard whether that makes sense from a design point of view. Presumably, if the class exists, then it's a concrete class - read Scott Meyers on the subject of inheriting from concrete classes. It's more likely that the correct design decision is to extract the common code (the reason you wanted to inherit in the first place) into an abstract class that both classes then inherit from. I don't have time to repeat Meyers's arguments for making all non-leaf classes abstract, but they are pretty compelling.