can we make class cant be derived at all?

G Haranadh

can we make class cant be derived at all? if yes how to make it. please let meknow?

Nice talking to you. :-O
If you judge people, you have no time to love them. -- Mother Teresa

theCPkid

class foo sealed
{
//...
};

use the 'sealed' keyword.

Rajesh R Subramanian

class CSealed
{
CSealed(){}
CSealed(const CSealed& ref){}
};

class some:public CSealed
{
//whatever
};

int _tmain(int argc, _TCHAR* argv[])
{
some s;
return 0;
}

This won't compile: C2248! Of course I assume that you know the other 'quirks' associated with keeping a class constructor as private. Let me know if you need more information.

“Follow your bliss.” – Joseph Campbell

Rajesh R Subramanian

theCPkid wrote:

use the 'sealed' keyword.

The ISO standard C++ has no such keyword.

“Follow your bliss.” – Joseph Campbell

Kushagra Tiwari

Hi , Here is what Stroutstroup had suggested on the same thing you want to achieve: Can I stop people deriving from my class? Bjarne Stroustrup :Yes, but why do you want to? There are two common answers: * for efficiency: to avoid my function calls being virtual * for safety: to ensure that my class is not used as a base class (for example, to be sure that I can copy objects without fear of slicing) In my experience, the efficiency reason is usually misplaced fear. In C++, virtual function calls are so fast that their real-world use for a class designed with virtual functions does not to produce measurable run-time overheads compared to alternative solutions using ordinary function calls. Note that the virtual function call mechanism is typically used only when calling through a pointer or a reference. When calling a function directly for a named object, the virtual function class overhead is easily optimized away. If there is a genuine need for "capping" a class hierarchy to avoid virtual function calls, one might ask why those functions are virtual in the first place. I have seen examples where performance-critical functions had been made virtual for no good reason, just because "that's the way we usually do it". The other variant of this problem, how to prevent derivation for logical reasons, has a solution. Unfortunately, that solution is not pretty. It relies on the fact that the most derived class in a hierarchy must construct a virtual base. For example: class Usable; class Usable_lock { friend class Usable; private: Usable_lock() {} Usable_lock(const Usable_lock&) {} }; class Usable : public virtual Usable_lock { // ... public: Usable(); Usable(char*); // ... }; Usable a; class DD : public Usable { }; DD dd; // error: DD::DD() cannot access // Usable_lock::Usable_lock(): private member I thinks This solves your problem , If yes rate the answer as Good and close the thread. Regards, Kushagra I hate to code but I luv to Develop :)

theCPkid

okay.. Thanks for the information. Visual studio compiler supports this keyword [^] and above all,if a person happens to use VS, "it works" without "any additional implications". Making the c'tor private will certainly stop the class from being inherited but it will also force the person to provide 'other' way of creating the class object. I think OP wanted to stop inheriting not instantiation. And my suggestion only helped him do what he wanted - nothing more, nothing less. :)

Rajesh R Subramanian

theCPkid wrote:

Visual studio compiler supports this keyword [^] and above all,if a person happens to use VS, "it works" without "any additional implications".

That's plainly wrong. If you scroll down to the bottom of the page you linked to, you will see this: Requirements (Read as "Additional implications"): Compiler option: /clr Which means that it is not a C++ program! It is a C++/CLI program, that targets the .NET framework.

theCPkid wrote:

Making the c'tor private will certainly stop the class from being inherited but it will also force the person to provide 'other' way of creating the class object.

Of course yes. But so what? That's the only way as far as C++ (the real C++) is concerned.

theCPkid wrote:

I think OP wanted to stop inheriting not instantiation. And my suggestion only helped him do what he wanted - nothing more, nothing less.

Your suggestion was just wrong here. It is a correct answer if the query was posted on a managed c++ forum.

“Follow your bliss.” – Joseph Campbell

theCPkid

Rajesh R Subramanian wrote:

Which means that it is not a C++ program! It is a C++/CLI program, that targets the .NET framework.

Now certainly, it's david vs big-fat-goliath(that's you) given my insufficient knowledge about managed or unmanaged code but man, if you do not scroll to the end of page, you will see this line "sealed is also valid when compiling for native targets (without /clr)" I have nothing more to say on this and whatever you say after that is correct but can you confirm this by using 'sealed' keyword in native unmanaged application on your system. I feel it's working on my PC. :)

Rajesh R Subramanian

theCPkid wrote:

Now certainly, it's david vs big-fat-goliath(that's you) given my insufficient knowledge about managed or unmanaged code

Certainly no! I'm not trying to talk you down or something like that. I'm merely stating the facts that I can pull off my head. My idea of visiting the forums and discussing with people is to teach them some, and learn some from them back.

theCPkid wrote:

"sealed is also valid when compiling for native targets (without /clr)"

Probably MS has done something with *their* compiler to support this feature (read as added feature specific to their compiler, or an extension, because of which you won't be able to have the same code successfully compiled with another c++ compiler). It doesn't work just right on my machine (you're probably using some latest version of VS and that compiler support for understanding this keyword). I only have 2003 installed here on this PC and it doesn't just work right. I will be able to derive classes from a class that has been declared 'sealed'. :)

theCPkid wrote:

I feel it's working on my PC.

Now, what does that mean? Something like:

class c1 sealed{}; class c2:public c1{};

gives a compiler error? If yes, then I'm almost certain that it becomes Microsoft C++ compiler (insert version) specific. Because it doesn't even work right with the previous versions! Not to mention sealed is NOT a C++ keyword.

“Follow your bliss.” – Joseph Campbell

theCPkid

class A sealed
{

};
class B: public A
{

};

error C3246: 'B' : cannot inherit from 'A' as it has been declared as 'sealed' I use VS 2008.

Rajesh R Subramanian wrote:

I only have 2003 installed here on this PC and it doesn't just work right. I will be able to derive classes from a class that has been declared 'sealed'.

Do you mean your compiler recognizes sealed keyword, allows compilation etc and still do not stop you from inheriting? hmmm.. may be you should tweak around a bit to find out how 'sealed' is being interpreted by your VS compiler. In the msdn link I mentioned before, it is written sealed is valid even if /clr is not mentioned. So, my suggestion is not entirely wrong. It works in at least one case. :laugh:

Nuri Ismail

G Haranadh wrote:

can we make class cant be derived at all? if yes how to make it. please let meknow?

Actually there is an article on CodeProject which can help you. -> Sealing Classes in C++[^] Personally I like this[^] handy macro, which is generalized version of Stroustrop's solution [^]. :)

Regards, Nuri Ismail

modified on Saturday, October 24, 2009 12:12 PM

Rajesh R Subramanian

I do a rebuild all and it barfed all over. It doesn't even seem to know what does 'sealed' mean. Won't even compile. Which would be the case with every other c++ compiler. (the previous build had ignored the changes I made to the code - happens every now and then).

theCPkid wrote:

So, my suggestion is not entirely wrong. It works in at least one case. Laugh

Right. :)

“Follow your bliss.” – Joseph Campbell

Lost User

Rajesh R Subramanian wrote:

It doesn't even seem to know what does 'sealed' mean.

I just tried this with VC++ Express and it compiled just as theCPkid states, even though the MSDN document states that you need the /clr option - which I certainly did not use. Is this a bug or a new feature I wonder :confused:

Rajesh R Subramanian

No it isn't a bug. It is some sort of an extension to their compiler. Even though there is nothing called "sealed" in the c++ language, Microsoft seem to have added the ability to their native c++ compiler to understand and support this keyword (the idea must have come from .NET). It looks like only VS 2005 or above will support this keyword. This cannot even be said to be "Microsoft Specific" (note that the documentation avoids using this term too), because it is restrictive to some versions of their compilers. Unfortunately if you would like to write portable code, using it is a very bad idea, because any other standard c++ compiler won't even know what sealed means. You will have to rewrite your code such that your class is not inheritable (and that will require you to change the whole class code, and the code that is using the class). And if you want to write a class that is not inheritable, and if you use this feature, then the code is NOT c++. Because it won't even compile in any standards conformant c++ compiler.

“Follow your bliss.” – Joseph Campbell