how write a final method in c++ like java ..

[mangesh]

class B
{
virtual void m( )
{

}
};

class D : public B
{

}

what should be done so that void m() can not be overriden in D

 

[Alf P. Steinbach]

* mangesh:

class B
{
virtual void m( )
{
}
};

class D : public B
{
}

what should be done so that void m() can not be overriden in D

Remove the word 'virtual'.

 

[shailesh]

C++ doesn't support final methods (like in Java).

A virtual function can be redefined by a derived class whenever
required. There is no way to restrict this functionality.

 

[homsan toft]

class B
{
virtual void m( )
{

}
};

class D : public B
{

}

what should be done so that void m() can not be overriden in D

http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.12

 

[Geo]

class B
{
virtual void m( )
{

}
};

class D : public B
{

}

what should be done so that void m() can not be overriden in D

To be honest, I've never known why you would want to do this, what
problem does it solve ?

 

[Alf P. Steinbach]

* shailesh:

C++ doesn't support final methods (like in Java).

A virtual function can be redefined by a derived class whenever
required. There is no way to restrict this functionality.

Simply don't declare it virtual in the first place.

 

[Markus Schoder]

To be honest, I've never known why you would want to do this, what
problem does it solve ?

Since in Java every (non-static) function is virtual you probably want
to give some indication which functions are supposed to be overriden
and which are not. Similar as with non-virtual functions in C++ (yes I
know there is a difference).

 

[Geo]

Since in Java every (non-static) function is virtual you probably want
to give some indication which functions are supposed to be overriden
and which are not. Similar as with non-virtual functions in C++ (yes I
know there is a difference).

But this is a question about C++, what Java does is irrelevant.

 

[Noah Roberts]

Markus Schoder wrote:
Similar as with non-virtual functions in C++ (yes I

know there is a difference).

A pretty big difference, no? non-virtuals in C++ can still be
overridden but that doesn't function polymorphically.

In my opinion there shouldn't be any such thing as final or non-virtual
functions. I see the reasoning behind it in C++ where you can do
whatever you want and language features are 'removable' (like not using
polymorphism) but from a design standpoint I think it smells bad.

 

[Ulrich Hobelmann]

In my opinion there shouldn't be any such thing as final or non-virtual
functions. I see the reasoning behind it in C++ where you can do
whatever you want and language features are 'removable' (like not using
polymorphism) but from a design standpoint I think it smells bad.

Tell that to the C# guys, who chose to do it like C++, not like Java.

Of course you have to know what you're doing, but maybe people who don't
shouldn't go into programming...

I quite like the separation between polymorphism (where and when you
need it, plus it's explicit and visible) and simple, static, efficient,
encapsulated functions (like with C structs). Puts you in control, and
most of the time you shouldn't inherit all over the place anyway.

 

[Noah Roberts]

Tell that to the C# guys, who chose to do it like C++, not like Java.

Why should I tell it to the C# guys? I don't care what they do or
don't do.

Of course you have to know what you're doing, but maybe people who don't
shouldn't go into programming...

Heh, ok...right to the personal attacks...don't pass go, don't collect
$200. You're way, way too invested in this language feature.

I quite like the separation between polymorphism (where and when you
need it, plus it's explicit and visible) and simple, static, efficient,
encapsulated functions (like with C structs). Puts you in control, and
most of the time you shouldn't inherit all over the place anyway.

Puts you in control? Debatable. You don't have a lot of control if
you need to inherit from a 3rd party library that can't be altered to
have a virtual function that you need to override. The only person
that has control is the person building the class. Clients have none.
Any function that accepts that class as input is stuck with that
class's implementation and depends on it. Any function you wish to
build that accepts that class as input also has a dependency on that
class's implementation...not just its interface. Breaking that
dependency requires an extra wrapper class and I don't find that simple
or efficient.

Simple and efficient? Well, simple is debatable since lacking of this
feature would remove the necessity to declare functions to be virtual.
It would also remove the necessity of workarounds when you can't
override a function you need to override (see above). On the
efficiency angle I would make mention of premature optimization and
question exactly how expensive you think virtual functions are.

The reasons behind not inheriting all over the place are numerous but
one of the most convincing arguments to me is the fact that it creates
strong dependencies. Non-virtual functions also create or indicate
strong dependencies on a specific functionality rather than an
interface. That has an odor.

 

[Ulrich Hobelmann]

Heh, ok...right to the personal attacks...don't pass go, don't collect
$200. You're way, way too invested in this language feature.

It wasn't meant as a personal attack. I merely acknowledge that C++
(and having virtual and non-virtual functions) is complex, and that a
programmer has to live with that complexity, if they choose the job.

Simple and efficient? Well, simple is debatable since lacking of this
feature would remove the necessity to declare functions to be virtual.
It would also remove the necessity of workarounds when you can't
override a function you need to override (see above). On the
efficiency angle I would make mention of premature optimization and
question exactly how expensive you think virtual functions are.

You have a point, but C++ is designed to allow all optimizations that
the programmer might want. If you want libs with virtual functions,
talk to whoever provides the library.

The reasons behind not inheriting all over the place are numerous but
one of the most convincing arguments to me is the fact that it creates
strong dependencies. Non-virtual functions also create or indicate
strong dependencies on a specific functionality rather than an
interface. That has an odor.

Yes. It always depends how much reusability an interface needs or even has.

 

[Noah Roberts]

Noah Roberts wrote:

You have a point, but C++ is designed to allow all optimizations that
the programmer might want.

Other languages also offer this feature but don't make you declare when
you want polymorphism. For instance the OP compares to Java where the
default behavior is to have a virtual function call and the developer
explicitly states when this isn't wanted. Objective-C, a more dynamic
OO language that requires runtime lookups for all name resolutions,
even provides support for static calls to a specific function in the
form of "IMP" pointers. The default behavior is to use dynamic
function calls (in whatever form the language supports) but to allow
for the optimization when truely needed. IMHO this results in better
code as developers are encouraged to use the less dependant mechanism
as a norm.

So I don't really question the necessity of having the feature
available, but I do question the default behavior of class functions
and I also think that using that feature can indicate questionable
coding practices...which is what having a smell means. Obviously there
are situations in which you actually need that kind of speed and the
dependency it creates is a reasonable sacrifice. As a norm however, I
debate that.

 

[SuperKoko]

Markus Schoder wrote:
Similar as with non-virtual functions in C++ (yes I

A pretty big difference, no? non-virtuals in C++ can still be
overridden but that doesn't function polymorphically.

I know that it's something weird with C++. It is here mainly for
historical reasons, and should not be used.
So, IMHO, it is not a big difference... It's just a language trap.
Advanced programmers don't fall in, period.
You may say that it is a "huge flaw which totally spoils the language".
If you think so, then turn towards a more clean language. C++ is not a
"clean language designed from scratch". We have to live with it, and in
practice it is not a real problem when you know deeply the language.
It is a problem for teaching it to students, though.

In my opinion there shouldn't be any such thing as final or non-virtual
functions. I see the reasoning behind it in C++ where you can do
whatever you want and language features are 'removable' (like not using
polymorphism) but from a design standpoint I think it smells bad.

OOP is not the only programming paradigm... A huge number of problems
are better solved with another programming paradigm.
In particular, C++ accepts the object-based paradigm, which can be
easily and efficiently used, and doesn't require virtual functions.
And, in C++ you don't pay for what you don't use.
C++ gives the freedom of using any available programming paradigm you
want.
The overhead of a vtable pointer can itself be unacceptable when there
are a lot of small objects allocated.
For instance, a 1 or 2 bytes object may use 8 bytes (because of
vptr+alignment)!
Furthermore, objects such as std::vector would suffer from a huge
overhead (500% sometimes) for very simple inline operations such as
operator[].
Perhaps super-smart optimizers might more or less inline
false-virtual-calls at runtime, but such optimization were not
effectively possible in 1998 (and are still not perfect today).
Furthermore, it doesn't solve the space overhead problem.
C++ is a language efficient & implementable right now... It was created
for that purpose from the start : Be a language useful right now (in
the tradition of the C language).

 

[phlip]

what should be done so that void m() can not be overriden in D

You should not want to try.

Ask yourself if you _really_ know for an absolute _fact_ that nobody will
_ever_ want to override your virtual. Only a control freak would think
they know that. Overriding is already useful for your method, because you
yourself already overrode it. Do not presume to know better than your
clients what they should want to do with your class.

As a major example of this hubris, folks whose job is teaching teams to
retrofit unit tests onto test-free systems must often write Mock Objects.
And they discover their 3rd party, closed-source libraries are full of
objects that cannot be cleanly mocked, because their authors, with
god-complexes, decided that nobody could override their most useful
methods. These authors did not deign to consider an entire category of
usage - as base classes for Mock Objects.

http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal

http://tinyurl.com/rups8