final equivalent

[kiran]

Hi all,

How can we stop a base class to be derived in C++? In java we do that
using final keyword. Is there a c++ equivalent?

Thanks in advance,
Kiran

 

[Alf P. Steinbach]

* kiran:

How can we stop a base class to be derived in C++? In java we do that
using final keyword. Is there a c++ equivalent?

This is a FAQ.

Finding the FAQ's discussion of this is a fine exercise that will help
you help yourself later.

Cheers, & hth.,

- Alf

 

[Salt_Peter]

Hi all,

How can we stop a base class to be derived in C++? In java we do that
using final keyword. Is there a c++ equivalent?

Thanks in advance,
Kiran

Have you considered reading the FAQ?

[23.11] How can I set up my class so it won't be inherited from?
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.11

 

[Rahul]

Hi all,

How can we stop a base class to be derived in C++? In java we do that
using final keyword. Is there a c++ equivalent?

Thanks in advance,
Kiran

you have got to use friend class and virtual base class concepts to do
the same...

 

[Juha Nieminen]

How can we stop a base class to be derived in C++? In java we do that
using final keyword. Is there a c++ equivalent?

I still can't understand why anyone would want to. What is the reason,
from object-oriented design point of view, to make a class final?

(IMO any technical reason which has nothing to do with OOD usually
means that the OOD in the program is crappy.)

 

[jkherciueh]

I still can't understand why anyone would want to. What is the reason,
from object-oriented design point of view, to make a class final?

(IMO any technical reason which has nothing to do with OOD usually
means that the OOD in the program is crappy.)

And why would the OOD point of view matter? Not every program using classes
is OO.

E.g., would there by any reason, _not_ to finalize

std::vector<T,A>::iterator

or

std::map<T,C,A>::iterator

(the later has to be implemented as a class or by compiler magic)?

Note that T* would be a compliant implementation for std::vector::iterator
anyhow, so any program deriving from vector::iterator is in a state of sin
already (in fact, there is no guarantee in the standard that you can derive
from any of the container iterators -- they are all implementation-defined
and could be final).


Best

Kai-Uwe Bux

 

[Alf P. Steinbach]

* Juha Nieminen:

I still can't understand why anyone would want to. What is the reason,
from object-oriented design point of view, to make a class final?

I have one example of where you initially want sort of the opposite,
that any derived class is abstract, non-instantiable, until you finally
derive a concrete class at bottom like

struct UserClass: SomeAbstractThingo {}; // Can't be made concrete.
typedef Concrete<UserClass> ConcreteUserClass; // Is concrete.

where Concrete<> applies post-construction final initialization (which
can be virtual), e.g. via a call to a virtual PostConstruct() function
from the Concrete<> constructor, and perhaps also ditto pre-destruction
preparatory cleanup.

The/one way to implement "can't be made concrete" and "is concrete" is
the same as for final class, using a virtual base with limited access.

Now if you could derive from Concrete<> you could override PostConstruct
and not have that override called. So making Concrete<> a final class
helps guarantee correct usage by technically disabling one incorrect
usage. It's an old ideal, that to the degree possible all that's
technically allowed should be meaningful and correct, i.e. capturing the
design constraints via the type system etc. However, that ideal must be
balanced against the ideal of C++ that the programmer should always be
able to do whatever he/she wants, even if perhaps in some contorted way.
So whether to make Concrete a final class is an engineering decision.


Cheers, & hth.,

- Alf

 

[James Kanze]

I still can't understand why anyone would want to. What is the reason,
from object-oriented design point of view, to make a class final?

I don't see too much value in making the class final, but being
able to make functions final is certainly useful in ensuring
invariants and contracts.