In article <2xbuioukf2.fsf_-_@obelix.mpi-sb.mpg.de> you wrote:
> I would very mouch appreciate some handy example for the _need_ to
> remove the virtuality `gene' inside a derivation tree! I understand
> the posibillity to do it, but i didn't need it yet.

I have a *real* example in some code I'm working on right now.  The basic
idea is a base class that services incoming events through a common
interface.  These are overridden by successively more specific handlers,
mapping the events at each protocol level to calls.  The point is, once
a level of protocol has been dealt with, it should not be meddled with
by someone overriding the lower level virtual function.

This does not answer the case of revoking the virtuality, merely stopping
any further overriding (but I haven't seen a use for a non-virtual
override of a virtual function anyway).

Here is an example:

    class EndPoint {  // handles results from a "poll" system call
        static void handle_poll_processing();
    protected:
        virtual void handle_poll_result( int file_descriptor, int events_bitmask ) = 0;
    };

    class Receiver : EndPoint {
        virtual void handle_data( string data ) = 0;
        virtual void handle_eof() = 0;

        /*final*/ void handle_poll_result( iostream file, int events_bitmask )
    };


    void Receiver::handle_poll_result( iostream file, int events_bitmask )
    {
        if ( events_bitmask & POLL_IN )
        {
            string S;
            file >> S;
            handle_data(S);
        }
        else if ( events_bitmask & POLL_HUP )
        {
            handle_eof();
        }
    }

    class Recorder : Receiver {
        /*final*/ void handle_data( string data );
        /*final*/ void handle_eof();
    };

and so on.  The point is, a "Recorder" won't work as advertised if someone
inherits from it then overrides the handle_poll_result - which it "doesn't
even know exists".

I would suggest that it should be a requirement that a virtual method
must be visible in any class which wishes to override it, and that it
be illegal to override an "invisible" virtual member (maybe unless it is
explicitly declared virtual).

-Martin.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I would very mouch appreciate some handy example for the _need_ to
remove the virtuality `gene' inside a derivation tree! I understand
the posibillity to do it, but i didn't need it yet.

if i understood the idea right it can be illustrated thus:


define an inheritance tree, where some virtual Method() becomes
non-virtual in the middle:

 struct Granny {
 virtual Method();
 };

 struct Ma : public Granny {
 virtual Method();
 };

 struct Me : public Ma {
 // from now on, Method isn't virtual any longer.
 // this is expressed by ommitting the virtual keyword
 // (!!! which breaks existing code, so some other syntactic sugar
 // is needed !!!)
 Method();
 };

 struct LittleJonas : public Me {
 Method(); // !!! hides Me::Method
 };


generate some pointers to different levels in the inheritance tree,
such that virtual function calling will be used:

 Granny* ptrMa = new Ma();
 Granny* ptrMe = new Me();
 Granny* ptrJonas = new LittleJonas();


call the functions, which uses the virtual/nonvirtual functions:

 ptrMa->Method(); // Ma::Method()
 ptrMe->Method(); // Ma::Method() or Me::Method(), depending on
    // the exact point where to remove the
    // virtuality property...
 ptrJonas->Method(); // same as ptrMe->Method()

constructing this example, it becomes less and less clear to me, what
this could be usefull for, and how exactly it should work...

so long

fred
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]