Re: final method - is this valid solution
On 21 Cze, 19:08, Chris Uzdavinis <cuz...@gmail.com> wrote:
On Wednesday, June 20, 2012 7:50:28 PM UTC-5, PiotrN wrote:
It seems that this is the pattern how base class can control which
derived classes are allowed to override virtual methods.
Maybe this is useful in very controlled micro environments,
Of course I agree with you. As with anything in human life - 90% of
things are used in 10% cases and 10% of things are in 90% cases... And
this does not mean that those 90% of things are not usable...
But anyway:
I thought about things like funny one - the library providers adding
possibility of overriding their methods only when you paid for it (I
hope they do not read this :D).
I can also imagine some quite useful like:
magine case where can and should exists only one class Main in
application using library "someLib" which overrides method
MainInterface::run.
someLib.cpp:
class Main; // define in application
class MainInterface {
protected:
class run_final { class tag; friend class Main; friend class
MainInterface; };
virtual int run(int a, run_final::tag*) = 0;
public:
int mainEntry(int a) { run(a, 0); }
};
extern "C" Main* createMainObject(); // shall be defined by
application - extern "C" to have portable linkage
int main() {
MainInterface* mi =
dynamic_cast<MainInterface*>(createMainObject());
return mi->mainEntry();
}
app1.cpp - define class Main and createMainObject() ....
HTH,
Piotr Nycz
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]