""cody"" <deutronium@web.de> wrote in message
news:GtNYa.6$0q2.5739@news.ecrc.de...
> you can't create a virtual function and say what somebody has to do with
is.
> this is the decision of the programmer.
>
> there are 3 things which you can do with a vitual function when overriding
> it:
>
> replace it:
> virtual void Func()
> {
> // your code goes here
> }
>
> extend it:
> virtual void Func()
> {
> Base::Func(); // call the base
> // your code goes here after the base call
> }
>
> intercept it:
> virtual void Func()
> {
> // your code before the basefunc is called
> Base::Func(); // call the base
> }
>
> when you design a class you can never know what a programmer will do with
> your virtual functions in its derrived classes. if you would know you
> wouldn't need them.
>
> --
> cody

This is true, which was the point of my original post.  I was trying to
propose a way that would indicate the intent of the virtual function.

I was saying that if the virtual function was designed to be replaced and
only replaced, there was no clear way to indicate this thus my proposed
no_base_call language addition.

Jeff

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <GtNYa.6$0q2.5739@news.ecrc.de>,
 on Fri, 8 Aug 2003 23:29:52 +0000 (UTC),
 deutronium@web.de ("cody") wrote:

> you can't create a virtual function and say what somebody has to do with is.
> this is the decision of the programmer.
>
> there are 3 things which you can do with a vitual function when overriding
> it:
>
> replace it:
> virtual void Func()
> {
> // your code goes here
> }
>
> extend it:
> virtual void Func()
> {
> Base::Func(); // call the base
> // your code goes here after the base call
> }
>
> intercept it:
> virtual void Func()
> {
> // your code before the basefunc is called
> Base::Func(); // call the base
> }

#pragma picky(on)
There's a fourth option - you can (if I may borrow your terminology)
both "intercept" AND "extend":
virtual void Func()
{
 // do stuff
 Base::Func();
 // do stuff
}
#pragma picky(off)

(In fact, you can also call the base function repeatedly if you really
want to, although I suspect that's rather uncommon)

> when you design a class you can never know what a programmer will do with
> your virtual functions in its derrived classes.

Unless you make them private, in which case you'll know that a
programmer can't call them directly, so he must either replace it or
leave it alone.

Regards,
 Andy S

--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> This is true, which was the point of my original post.  I was trying to
> propose a way that would indicate the intent of the virtual function.
>
> I was saying that if the virtual function was designed to be replaced and
> only replaced, there was no clear way to indicate this thus my proposed
> no_base_call language addition.


you can never know what a programmer will do with your virtual function. he
can extend,intercept,replace it or whatever this is his desicion and not
yours.
that is the principle of virtual functions. they are intended that derrived
classes may alter their implementation or extend the old. how could you know
what somebody will do with your class? maybe he just want to extend the
function to increment a counter when the function gets called, maybe he want
to replace the method or whatever. how could you know? there may be hundreds
of derrived classes from yours why should you restrict the versatility of
polyformism in your class?
but the solution to your problem is: a good dokumentation provides the
programmer information to know how the method *should* correctly be
overridden. this isn't just "calling the base-class or not", this is: "in
which case shall the base been called or not, which return value is correct,
what do i have to do with the arguments, in which manner should the method
affect the state of the object/program" and so on.

i recommend you to read the dokumentation to specific virtual methods and
you'll see how many cases there are.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <vj0oskcg324hce@corp.supernews.com>,
 on Wed, 6 Aug 2003 03:11:54 +0000 (UTC),
 sebmol@yahoo.com ("Sebastian Moleski") wrote:

> "Andy Sawyer" <andys@despammed.com> wrote in message
> news:he4wx996.fsf@evo6.com...
>> In article <a4OXa.321878$nr.13166846@twister.southeast.rr.com>,
>>  on Tue, 5 Aug 2003 14:39:02 +0000 (UTC),
>>  no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams") wrote:
>>
>> > If the base class version was private, then the derived classes would
>> > not be able to over-ride the function anyways.
>>
>> Why on earth not?
>>
>> If you REALLY want to ensure that no derived class can call your base
>> class implementation, you could write something like:
>
> Um, if the virtual function is private in the base class, the derived
> class can't call the base class implementation either. No need to
> resort to run-time kludges.

Sure, but the OP seemd to object to the private virtual function
approach. And, presumably, the private virtual function would be
accessible indirectly via a call to some public or protected function?
(A virtual function which cannot be called *at all* seems a little
pointless to me)

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:u18uwee9.fsf@evo6.com...
> > Um, if the virtual function is private in the base class, the derived
> > class can't call the base class implementation either. No need to
> > resort to run-time kludges.
>
> Sure, but the OP seemd to object to the private virtual function
> approach. And, presumably, the private virtual function would be
> accessible indirectly via a call to some public or protected function?
> (A virtual function which cannot be called *at all* seems a little
> pointless to me)

You basically get the template method pattern through private virtual functions.
So, yes, of course those private virtual functions can be called through the
public or protected class interface but not directly.

sm


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Richard Smith" <richard@ex-parrot.com> wrote in message
news:Pine.LNX.4.55.0308051622460.31618@sphinx.mythic-beasts.com...
> Jeff Williams wrote:
>
> > If the base class version was private, then the derived classes would
not be
> > able to over-ride the function anyways.
>
> Wrong.  A derived class can override virtual functions in a
> base irrespective of their access specifier (i.e. whether
> they are private, protected or public).
>
> --
> Richard Smith

I didn't know that, thanks for the correction (You learn something new every
day)

Jeff

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:u18uwee9.fsf@evo6.com...
> In article <vj0oskcg324hce@corp.supernews.com>,
>  on Wed, 6 Aug 2003 03:11:54 +0000 (UTC),
>  sebmol@yahoo.com ("Sebastian Moleski") wrote:
>
> > "Andy Sawyer" <andys@despammed.com> wrote in message
> > news:he4wx996.fsf@evo6.com...
> >> In article <a4OXa.321878$nr.13166846@twister.southeast.rr.com>,
> >>  on Tue, 5 Aug 2003 14:39:02 +0000 (UTC),
> >>  no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams")
wrote:
> >>
> >> > If the base class version was private, then the derived classes would
> >> > not be able to over-ride the function anyways.
> >>
> >> Why on earth not?
> >>
> >> If you REALLY want to ensure that no derived class can call your base
> >> class implementation, you could write something like:
> >
> > Um, if the virtual function is private in the base class, the derived
> > class can't call the base class implementation either. No need to
> > resort to run-time kludges.
>
> Sure, but the OP seemd to object to the private virtual function
> approach. And, presumably, the private virtual function would be
> accessible indirectly via a call to some public or protected function?
> (A virtual function which cannot be called *at all* seems a little
> pointless to me)
>
> Regards,
>  Andy S


Well my scenario was not a virtual function that should never be called.  It
was a virtual function that should never be called by functions that
over-ride it.  And I wanted an easy method to convey this fact to users of
the class, the private virtual function idiom as suggested by Richard Smith
seems to accomplish that however it is not blatantly obvious to other users
of the class imho.  I suppose for most purposes you could accomplish the
goal I stated by simply using a combination of the private virtual function
idiom and a comment in the code as a benefit to those who are not familiar
with the idiom.

Jeff

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <vj3m8nq803t7ac@corp.supernews.com>,
 on Thu, 7 Aug 2003 04:52:46 +0000 (UTC),
 sebmol@yahoo.com ("Sebastian Moleski") wrote:

> "Andy Sawyer" <andys@despammed.com> wrote in message
> news:u18uwee9.fsf@evo6.com...
>> > Um, if the virtual function is private in the base class, the derived
>> > class can't call the base class implementation either. No need to
>> > resort to run-time kludges.
>>
>> Sure, but the OP seemd to object to the private virtual function
>> approach. And, presumably, the private virtual function would be
>> accessible indirectly via a call to some public or protected function?
>> (A virtual function which cannot be called *at all* seems a little
>> pointless to me)
>
> You basically get the template method pattern through private virtual
> functions.

Which was kind of my point. (It's rare for me to declare a virtual
function as public).

> So, yes, of course those private virtual functions can be called
> through the public or protected class interface but not directly.

And it was my understanding that the OP wanted to prevent the base-class
function being called by a derived class function - and if the derived
class function calls one of those public or protected members...


Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

you can't create a virtual function and say what somebody has to do with is.
this is the decision of the programmer.

there are 3 things which you can do with a vitual function when overriding
it:

replace it:
virtual void Func()
{
// your code goes here
}

extend it:
virtual void Func()
{
Base::Func(); // call the base
// your code goes here after the base call
}

intercept it:
virtual void Func()
{
// your code before the basefunc is called
Base::Func(); // call the base
}

when you design a class you can never know what a programmer will do with
your virtual functions in its derrived classes. if you would know you
wouldn't need them.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no fucking ads]


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Often when over-riding functions from a base class, I find it difficult to
easily determine if I should be calling the base class version (in the case
of a hook) or not calling the base class version (in the case of changing
behavior).
It occurred to me that it might be useful to provide an additional function
type specifier that I shall refer to as no_base_call.

Example:

struct foo
{
   virtual void RespondToInput(int i) no_base_call
   {
       // .. do something here
   }
};


struct bar : foo
{
   void RespondToInput(int i)
   {
       // do some code here
       return foo::RespondToInput(i);   // ERROR!  call to base class
function flagged as no base call
   }
};


Now on the one hand I assume I cannot possibly be the first to think of this
and yet it doesn't exist.  Which tells me it is either A) Error prone or not
possible or B) deemed un-useful
Which is it?  Any comments on such a mechanism?

Jeff


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams") wrote
(abridged):
> Often when over-riding functions from a base class, I find it
> difficult to easily determine if I should be calling the base
> class version (in the case of a hook) or not calling the base
> class version (in the case of changing behavior).
> It occurred to me that it might be useful to provide an
> additional function type specifier that I shall refer to as
> no_base_call.

Why not declare the base class version private if it isn't supposed to
be called? Have a public forwarding function if necessary.

-- Dave Harris, Nottingham, UK

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jeff Williams wrote:

> Often when over-riding functions from a base class, I find it difficult to
> easily determine if I should be calling the base class version (in the case
> of a hook) or not calling the base class version (in the case of changing
> behavior).

Use the private virtual function idiom, then.  Basically,
this says that a virtual function should be private unless
you want to be able to call it non-virtually from an
overriding implementation, in which case it should be
protected.  If the virtual function should be callable from
outside the base class, then a public (or maybe just
protected) forwarding function should be provided.

This idiom provides a number of advantages.  There's minimal
danger of accidentally making a non-virtual function call
when a virtual one was intended.  It provides a single place
to place code to assert preconditions and insert other code
that is common to all overrides.  It provides better
segregation between the "implementation interface" (i.e.
the virtual functions that subclasses override) and the
"external interface" (i.e. the public functions that users
of the class call).  Finally, it can assist in the use of
patterns that reduce dependencies, such as the Bridge
pattern.

> It occurred to me that it might be useful to provide an additional function
> type specifier that I shall refer to as no_base_call.

No need for it.  If you following the advice above, you
shouldn't get into problems.

--
Richard Smith

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

If the base class version was private, then the derived classes would not be
able to over-ride the function anyways.


The more I think the on it though, the idea is inherently flawed.  Because
even if the original base class was flagged as no_base_call, and some other
class over-rides that func what happens when that derived class is further
derived from....  would it still be no base call?  If so, then you couldn't
call the first over-ride of the function and the person writing that class
most likely assumed the code would be executed even though the ultimate base
class was designed such that when the func in question was overridden that
its version would not be called.


"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20030804224451.61301B@brangdon.madasafish.com...
> no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams") wrote
> (abridged):
> > Often when over-riding functions from a base class, I find it
> > difficult to easily determine if I should be calling the base
> > class version (in the case of a hook) or not calling the base
> > class version (in the case of changing behavior).
> > It occurred to me that it might be useful to provide an
> > additional function type specifier that I shall refer to as
> > no_base_call.
>
> Why not declare the base class version private if it isn't supposed to
> be called? Have a public forwarding function if necessary.
>
> -- Dave Harris, Nottingham, UK
>
> ---
> [ 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    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jeff Williams wrote:

> If the base class version was private, then the derived classes would not be
> able to over-ride the function anyways.

Wrong.  A derived class can override virtual functions in a
base irrespective of their access specifier (i.e. whether
they are private, protected or public).

--
Richard Smith

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

[Please don't top-post.]

In article <a4OXa.321878$nr.13166846@twister.southeast.rr.com>,
"Jeff Williams" wrote:
> "Dave Harris" <brangdon@cix.co.uk> wrote in message
> news:memo.20030804224451.61301B@brangdon.madasafish.com...
>> no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams") wrote
>> (abridged):
>> > Often when over-riding functions from a base class, I find it
>> > difficult to easily determine if I should be calling the base
>> > class version (in the case of a hook) or not calling the base
>> > class version (in the case of changing behavior).
>> > It occurred to me that it might be useful to provide an
>> > additional function type specifier that I shall refer to as
>> > no_base_call.
>>
>> Why not declare the base class version private if it isn't supposed to
>> be called? Have a public forwarding function if necessary.
>
> If the base class version was private, then the derived classes would
> not be able to over-ride the function anyways.

Yes, they can.  Overriding a virtual function does not require that the
overridden function be accessible.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <a4OXa.321878$nr.13166846@twister.southeast.rr.com>,
 on Tue, 5 Aug 2003 14:39:02 +0000 (UTC),
 no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams") wrote:

> If the base class version was private, then the derived classes would
> not be able to over-ride the function anyways.

Why on earth not?

If you REALLY want to ensure that no derived class can call your base
class implementation, you could write something like:

class base
{
public:
   virtual void foo()
   {
     assert( typeid( *this ) == typeid( base ) );
   }
};

Although obviously, it's a run-time check rather than a compile-time
check.

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:he4wx996.fsf@evo6.com...
> In article <a4OXa.321878$nr.13166846@twister.southeast.rr.com>,
>  on Tue, 5 Aug 2003 14:39:02 +0000 (UTC),
>  no_spam_remove_up_to_here_jwilliams@mfchelp.com ("Jeff Williams") wrote:
>
> > If the base class version was private, then the derived classes would
> > not be able to over-ride the function anyways.
>
> Why on earth not?
>
> If you REALLY want to ensure that no derived class can call your base
> class implementation, you could write something like:

Um, if the virtual function is private in the base class, the derived class
can't call the base class implementation either. No need to resort to run-time
kludges.

sm


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]