final class

[Rahul]

Hi Everyone,

I was searching for final class in c++, and i came across few links
which suggests to have the constructor of the, to be final class, as
private so that any derived class's constructors can't access the
same.

class C
{
private:
C()
{
printf("in private constructor of C\n");
}
};

class E : public C
{
public: E()
{
}
};

E obj; // causes compile time error saying C() can't be
accessed.

However this just makes class E abstract and doesn't really stop
inheritance from class C. In fact, there isn't any error if i remove
the declaration of obj. Is there any way to avoid extending from C in
the first place?

Thanks in advance!!!

[Abhishek Padmanabh]

On Dec 9, 10:07 am, Rahul <[e-mail]:

Hi Everyone,

I was searching for final class in c++, and i came across few links
which suggests to have the constructor of the, to be final class, as
private so that any derived class's constructors can't access the
same.

class C
{
private:
C()
{
printf("in private constructor of C\n");
}

};

class E : public C
{
public: E()
{
}

};

E obj; // causes compile time error saying C() can't be
accessed.

However this just makes class E abstract and doesn't really stop
inheritance from class C. In fact, there isn't any error if i remove
the declaration of obj. Is there any way to avoid extending from C in
the first place?

And what is the use of that inheritance? Keep on inheriting/multiple-
inheriting class C, will anything useful come out of it? Ever?

[Rahul]

On Dec 9, 10:56 am, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 9, 10:07 am, Rahul <[e-mail]:

Hi Everyone,

I was searching for final class in c++, and i came across few links
which suggests to have the constructor of the, to be final class, as
private so that any derived class's constructors can't access the
same.

class C
{
private:
C()
{
printf("in private constructor of C\n");
}

};

class E : public C
{
public: E()
{
}

};

E obj; // causes compile time error saying C() can't be
accessed.

However this just makes class E abstract and doesn't really stop
inheritance from class C. In fact, there isn't any error if i remove
the declaration of obj. Is there any way to avoid extending from C in
the first place?

And what is the use of that inheritance? Keep on inheriting/multiple-
inheriting class C, will anything useful come out of it? Ever?

Yes, to an extent an object can't be created. But i was expecting the
compiler to
give an error just like how final works with java...

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-12-09 07:33, Rahul wrote:

On Dec 9, 10:56 am, Abhishek Padmanabh <[e-mail]>
wrote:

>On Dec 9, 10:07 am, Rahul <[e-mail]:

Hi Everyone,

I was searching for final class in c++, and i came across few links
which suggests to have the constructor of the, to be final class, as
private so that any derived class's constructors can't access the
same.

class C
{
private:
C()
{
printf("in private constructor of C\n");
}

};

class E : public C
{
public: E()
{
}

};

E obj; // causes compile time error saying C() can't be
accessed.

However this just makes class E abstract and doesn't really stop
inheritance from class C. In fact, there isn't any error if i remove
the declaration of obj. Is there any way to avoid extending from C in
the first place?

And what is the use of that inheritance? Keep on inheriting/multiple-
inheriting class C, will anything useful come out of it? Ever?

Yes, to an extent an object can't be created. But i was expecting the
compiler to
give an error just like how final works with java...

No, you will only get the error when you try to instantiate.A better
question though, what is the use of a final mechanism? To me it seems a
bit short-sighted to assume that there will never be a situation where
one would need to inherit from the class.

--
Erik Wikström

[terminator]

On Dec 9, 9:33 am, Rahul <[e-mail]:

On Dec 9, 10:56 am, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 9, 10:07 am, Rahul <[e-mail]:

Hi Everyone,

I was searching for final class in c++, and i came across few links
which suggests to have the constructor of the, to be final class, as
private so that any derived class's constructors can't access the
same.

class C
{
private:
C()
{
printf("in private constructor of C\n");
}

};

class E : public C
{
public: E()
{
}

};

E obj; // causes compile time error saying C() can't be
accessed.

However this just makes class E abstract and doesn't really stop
inheritance from class C. In fact, there isn't any error if i remove
the declaration of obj. Is there any way to avoid extending from C in
the first place?

And what is the use of that inheritance? Keep on inheriting/multiple-
inheriting class C, will anything useful come out of it? Ever?

Yes, to an extent an object can't be created. But i was expecting the
compiler to
give an error just like how final works with java...

In C++ nothing is final.why should a class be not extensible?
I even cannot see why currently intrinsic types cannot be derived.

regards,
FM.

[Abhishek Padmanabh]

On Dec 9, 4:32 pm, terminator <[e-mail]:

On Dec 9, 9:33 am, Rahul <[e-mail]:

On Dec 9, 10:56 am, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 9, 10:07 am, Rahul <[e-mail]:

Hi Everyone,

I was searching for final class in c++, and i came across few links
which suggests to have the constructor of the, to be final class, as
private so that any derived class's constructors can't access the
same.

class C
{
private:
C()
{
printf("in private constructor of C\n");
}

};

class E : public C
{
public: E()
{
}

};

E obj; // causes compile time error saying C() can't be
accessed.

However this just makes class E abstract and doesn't really stop
inheritance from class C. In fact, there isn't any error if i remove
the declaration of obj. Is there any way to avoid extending from C in
the first place?

And what is the use of that inheritance? Keep on inheriting/multiple-
inheriting class C, will anything useful come out of it? Ever?

Yes, to an extent an object can't be created. But i was expecting the
compiler to
give an error just like how final works with java...

In C++ nothing is final.why should a class be not extensible?
I even cannot see why currently intrinsic types cannot be derived.

In C++, nothing is final as such (unless the constructors are made
private - and getting an object of the class is via some friend
factory class or exposes a public getter for new instances). But it
does not mean that everything is extensible.

Extensible are classes whose current design is capable of or "hints"
at possible future extensions. If none of the member functions are
virtual (in which case the destructor won't be made virtual as well),
it tells that there is no functionality to be "overridden". If the
destructor isn't virtual (irrespective of if it has virtual functions
or not), it tells that there is nothing to be "extended". One could
argue about safely using classes derived from classes not having
virtual destructors, but that is different. That is not extension.
That is just a way to save some typing. Inheritance does help in
saving some typing but that is not the real goal: runtime
polymorphism.

I wonder why you would want to derive from intrinsic types? The usual
way to build upon them would be via composition.

[James Kanze]

On Dec 9, 11:57 am, Erik Wikström <[e-mail]:

On 2007-12-09 07:33, Rahul wrote:

On Dec 9, 10:56 am, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 9, 10:07 am, Rahul <[e-mail]:

A better question though, what is the use of a final
mechanism? To me it seems a bit short-sighted to assume that
there will never be a situation where one would need to
inherit from the class.

In particular, there are meta-programming techniques which
depend on being able to derive from a class (without ever
created instances of the derived class).

What might be useful is some means of declaring that a specific
function is the final override; this is important for
programming by contract. In practice, however, I've not found
any real cases of abuse, so it's more a theoretical benefit than
a real one.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

Rahul wrote:

I was searching for final class in c++

I have never understood the meaningfulness of "final" classes from an
object-oriented design point of view.

For what purpose, from OOD PoV, should one forbid inheritance from a
certain class?

[Pete Becker]

On 2007-12-10 05:54:30 -0500, Juha Nieminen <no****@thanks.invalidsaid:

Rahul wrote:

>I was searching for final class in c++

I have never understood the meaningfulness of "final" classes from an
object-oriented design point of view.

For what purpose, from OOD PoV, should one forbid inheritance from a
certain class?

Java has them. What more do you need?

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Vladislav.Lazarenko]

I apologize, guys. C++ has final class. I won't spend time describing
how it works, I hope your knowledge is enough to understand source
code. Check it out -
http://www.boost-consulting.com/vaul...20Programming&

[Juha Nieminen]

Pete Becker wrote:

On 2007-12-10 05:54:30 -0500, Juha Nieminen <no****@thanks.invalidsaid:

>Rahul wrote:

>>I was searching for final class in c++

I have never understood the meaningfulness of "final" classes from an
object-oriented design point of view.

For what purpose, from OOD PoV, should one forbid inheritance from a
certain class?

Java has them. What more do you need?

That didn't answer my question.

[Vladislav.Lazarenko]

On Dec 10, 5:54 am, Juha Nieminen <[e-mail]:

Rahul wrote:

I was searching for final class in c++

I have never understood the meaningfulness of "final" classes from an
object-oriented design point of view.

For what purpose, from OOD PoV, should one forbid inheritance from a
certain class?

It is just a simple way to allow control over a class and avoid
possibly anomalous behavior. Java specific thing is also performance.
I agree that from OOD PoV it is not needed, however, when you write
libraries (frameworks), you probably want to protect stupid users from
incorrect usage of your library. In such a way I would rather prevent
inheritance from standard STL containers, for example. That's it.

[Kai-Uwe Bux]

Vl*****************@gmail.com wrote:

On Dec 10, 5:54 am, Juha Nieminen <[e-mail]:

>Rahul wrote:

I was searching for final class in c++

I have never understood the meaningfulness of "final" classes from an
object-oriented design point of view.

For what purpose, from OOD PoV, should one forbid inheritance from a
certain class?

It is just a simple way to allow control over a class and avoid
possibly anomalous behavior. Java specific thing is also performance.
I agree that from OOD PoV it is not needed, however, when you write
libraries (frameworks), you probably want to protect stupid users from
incorrect usage of your library. In such a way I would rather prevent
inheritance from standard STL containers, for example. That's it.

Inheriting from standard containers can lead to some surprises. However,
there are times when it is perfectly sound to do so. This is not to say
that making a class final is never a good idea; but it is very very hard to
predict all possible legitimate uses of a class. Limiting usage by
artificially tying down the hands of client code programmers is rarely ever
a good idea. In particular, making standard containers final classes would
not be good.
Best

Kai-Uwe Bux

[Vladislav.Lazarenko]

On Dec 10, 8:35 pm, Kai-Uwe Bux <[e-mail]:

[e-mail] wrote:

On Dec 10, 5:54 am, Juha Nieminen <[e-mail]:

Rahul wrote:
I was searching for final class in c++

I have never understood the meaningfulness of "final" classes from an
object-oriented design point of view.

For what purpose, from OOD PoV, should one forbid inheritance from a
certain class?

It is just a simple way to allow control over a class and avoid
possibly anomalous behavior. Java specific thing is also performance.
I agree that from OOD PoV it is not needed, however, when you write
libraries (frameworks), you probably want to protect stupid users from
incorrect usage of your library. In such a way I would rather prevent
inheritance from standard STL containers, for example. That's it.

Inheriting from standard containers can lead to some surprises. However,
there are times when it is perfectly sound to do so. This is not to say
that making a class final is never a good idea; but it is very very hard to
predict all possible legitimate uses of a class. Limiting usage by
artificially tying down the hands of client code programmers is rarely ever
a good idea. In particular, making standard containers final classes would
not be good.

Best

Kai-Uwe Bux

I agree. It was just an example. Want you to do final class or not,
having ability to do it is good. I love C++ because it is possible to
do everything. Why not final class?

[Kai-Uwe Bux]

Vl*****************@gmail.com wrote:

On 10 ???, 22:23, "Alf P. Steinbach" <[e-mail]:

>* [e-mail]:

I love C++ because it is possible to
do everything. Why not final class?

It's often a good idea to check the FAQ before posting.

<url:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.11>

>>

[snip]

>
Alf, looks like we misunderstood each other. I know it is possible.
Moreover, solution described in FAQ is not general. You should always
write base class from scratch, right? The code I have posted to Boost
Vault is general solution. The only you should do is inherit from
"nonderivable" class, that's it. The only thing user should remember -
not all compilers, probably, supports template friends.

If by "template friends" you should mean something like

template < typename T >
class dummy {
friend class T;
...
};

then no standard compliant compiler will support template friends.

(Now, of course, I am guessing here from context; but I presume that you
want to use templated inheritance for implementing a final<template that
does not require the user to manually use virtual inheritance. I think
that, at least as of the current standard, [7.1.5.3/2] blocks any attempt
in that direction.)

You can read about C++ "final" in Boost mailing list:
http://lists.boost.org/Archives/boos.../05/122446.php

Best

Kai-Uwe Bux