C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Re: no_base_call          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Richard Smith Guest Posted: Tue Aug 05, 2003 2:38 pm    Post subject: Re: no_base_call Jeff Williams wrote: Quote: 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. Quote: 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 ] Back to top Jeff Williams Guest Posted: Tue Aug 05, 2003 2:39 pm    Post subject: Re: no_base_call 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 (AT) cix (DOT) co.uk> wrote Quote: no_spam_remove_up_to_here_jwilliams (AT) mfchelp (DOT) 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 ] Back to top Ben Hutchings Guest Posted: Tue Aug 05, 2003 11:38 pm    Post subject: Re: no_base_call [Please don't top-post.] In article <a4OXa.321878$nr.13166846 (AT) twister (DOT) southeast.rr.com>, "Jeff Williams" wrote: Quote: "Dave Harris" <brangdon (AT) cix (DOT) co.uk> wrote in message news:memo.20030804224451.61301B (AT) brangdon (DOT) madasafish.com... [email]no_spam_remove_up_to_here_jwilliams (AT) mfchelp (DOT) com[/email] ("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 ] Back to top Sebastian Moleski Guest Posted: Wed Aug 06, 2003 3:11 am    Post subject: Re: no_base_call "Andy Sawyer" <andys (AT) despammed (DOT) com> wrote Quote: In article <a4OXa.321878$nr.13166846 (AT) twister (DOT) southeast.rr.com>, on Tue, 5 Aug 2003 14:39:02 +0000 (UTC), [email]no_spam_remove_up_to_here_jwilliams (AT) mfchelp (DOT) com[/email] ("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 ] Back to top Andy Sawyer Guest Posted: Thu Aug 07, 2003 2:43 am    Post subject: Re: no_base_call In article <vj0oskcg324hce (AT) corp (DOT) supernews.com>, on Wed, 6 Aug 2003 03:11:54 +0000 (UTC), [email]sebmol (AT) yahoo (DOT) com[/email] ("Sebastian Moleski") wrote: Quote: "Andy Sawyer" <andys (AT) despammed (DOT) com> wrote in message news:he4wx996.fsf (AT) evo6 (DOT) com... In article <a4OXa.321878$nr.13166846 (AT) twister (DOT) southeast.rr.com>, on Tue, 5 Aug 2003 14:39:02 +0000 (UTC), [email]no_spam_remove_up_to_here_jwilliams (AT) mfchelp (DOT) com[/email] ("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 ] Back to top Sebastian Moleski Guest Posted: Thu Aug 07, 2003 4:52 am    Post subject: Re: no_base_call "Andy Sawyer" <andys (AT) despammed (DOT) com> wrote Quote: 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 ] Back to top Jeff Williams Guest Posted: Fri Aug 08, 2003 3:22 am    Post subject: Re: no_base_call "Richard Smith" <richard (AT) ex-parrot (DOT) com> wrote Quote: 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 ] Back to top Jeff Williams Guest Posted: Fri Aug 08, 2003 5:01 am    Post subject: Re: no_base_call "Andy Sawyer" <andys (AT) despammed (DOT) com> wrote Quote: In article <vj0oskcg324hce (AT) corp (DOT) supernews.com>, on Wed, 6 Aug 2003 03:11:54 +0000 (UTC), [email]sebmol (AT) yahoo (DOT) com[/email] ("Sebastian Moleski") wrote: "Andy Sawyer" <andys (AT) despammed (DOT) com> wrote in message news:he4wx996.fsf (AT) evo6 (DOT) com... In article <a4OXa.321878$nr.13166846 (AT) twister (DOT) southeast.rr.com>, on Tue, 5 Aug 2003 14:39:02 +0000 (UTC), [email]no_spam_remove_up_to_here_jwilliams (AT) mfchelp (DOT) com[/email] ("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 ] Back to top Andy Sawyer Guest Posted: Fri Aug 08, 2003 11:29 pm    Post subject: Re: no_base_call In article <vj3m8nq803t7ac (AT) corp (DOT) supernews.com>, on Thu, 7 Aug 2003 04:52:46 +0000 (UTC), [email]sebmol (AT) yahoo (DOT) com[/email] ("Sebastian Moleski") wrote: Quote: "Andy Sawyer" <andys (AT) despammed (DOT) com> wrote in message news:u18uwee9.fsf (AT) evo6 (DOT) 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). Quote: 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 ] Back to top Jeff Williams Guest Posted: Tue Aug 12, 2003 5:17 pm    Post subject: Re: no_base_call ""cody"" <deutronium (AT) web (DOT) de> wrote Quote: 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 ] Back to top Andy Sawyer Guest Posted: Tue Aug 12, 2003 6:40 pm    Post subject: Re: no_base_call In article <GtNYa.6$0q2.5739 (AT) news (DOT) ecrc.de>, on Fri, 8 Aug 2003 23:29:52 +0000 (UTC), [email]deutronium (AT) web (DOT) de[/email] ("cody") wrote: Quote: 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) Quote: 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 ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.