C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  satisfying pure virtual function through inheritance Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Ulrich Eckhardt Guest Posted: Thu Sep 29, 2005 8:37 pm    Post subject: satisfying pure virtual function through inheritance Greetings! I just tried this here: Quote: struct interface { virtual void foo() = 0; }; struct implementation { void foo() {} }; struct combined: interface, implementation { }; combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder ist a) what is the reason not to allow this? What dangers would it bring if implementation::foo satisfied the virtual function, what would break? b) what are ways around it? My problem is that the virtual function declarations (and stubs returning an error code) are generated from an interface description and I need to manually implement them. Further, there are two use-cases where in one, the virtual functions are called by the framework (i.e. they should be private virtual functions that can be overridden) or they can be part of a publicly available API (and then there is no need to override them so they should be public nonvirtual). What I'm mostly pondering over is how I can combine these two use-cases and still create code that is clear but doesn't do things twice. For that case I would like to have the mentioned 'class implementation' which is manually written and, depending on the context, used directly or called indirectly via the framework. Another thing in that context is how would I best make sure, in case the autogenerated code changes a parameter in a virtual function, that I catch this so the implementations don't suddenly turn from overrides into overloads? I tried all compilers I have, neither of them warned me - or maybe I'm just not giving them the right switch, I haven't completed that part of my homework yet. Uli [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Sat Oct 01, 2005 1:54 am    Post subject: Re: satisfying pure virtual function through inheritance On 29 Sep 2005 16:37:18 -0400, Ulrich Eckhardt <eckhardt (AT) satorlaser (DOT) com> wrote in comp.lang.c++.moderated: Quote: Greetings! I just tried this here: | struct interface | { | virtual void foo() = 0; | }; | | struct implementation | { | void foo() {} | }; | | struct combined: interface, implementation | { | }; | | combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder ist a) what is the reason not to allow this? What dangers would it bring if implementation::foo satisfied the virtual function, what would break? What happens if you have a third type: struct another { void foo() {} }; ....and combined inherits from all three? Which foo() implements the pure virtual? Which one gets called? -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Virtanen Antti Guest Posted: Sat Oct 01, 2005 1:40 pm    Post subject: Re: satisfying pure virtual function through inheritance On 2005-09-29, Ulrich Eckhardt <eckhardt (AT) satorlaser (DOT) com> wrote: Quote: I just tried this here: | struct interface | { | virtual void foo() = 0; | }; | | struct implementation | { | void foo() {} | }; | | struct combined: interface, implementation | { | }; | | combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder ist a) what is the reason not to allow this? What would be the reason to allow this? After all, structs are not classes and IMHO should not be used as classes. Quote: What dangers would it bring if implementation::foo satisfied the virtual function, what would break? Designer's and maintainer programmer's heads at least, but there's likely to be better reasons for not allowing this sort of constructs. Quote: What I'm mostly pondering over is how I can combine these two use-cases and still create code that is clear but doesn't do things twice. For that case I would like to have the mentioned 'class implementation' which is manually written and, depending on the context, used directly or called indirectly via the framework. I didn't quite understand your problem, but your "combined" class (it is logically a class, even if you name it a struct) inherits the method "foo" twice with the same signature (return value and parameters). How is the compiler supposed to know which one of the two logical possibilities you want to use? In this particular case, there's of course the logical solution, but the compiler can't see it. After all, "implementation" doesn't have anything in common with your "interface", so how is the compiler supposed to know that "foo" in "implementation" is the one you want to use as an implementation for the "foo" in "interface"? If you further derive from "combined" additional problems arise from this ambiquity and the compiler can't see if you do. Quote: Another thing in that context is how would I best make sure, in case the autogenerated code changes a parameter in a virtual function, that I catch this so the implementations don't suddenly turn from overrides into overloads? Shortly, you can't. If a parameter changes, the code looks perfectly valid from the compiler's point of view since then you have two different functions and there's no ambiquity. You could perhaps do some evil magic with template metaprogramming to check for overloads, but that would be difficult and I'm not sure if it's even possible. -- // Antti Virtanen -//- http://www.students.tut.fi/~virtanea -//- 050-4004278 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Sat Oct 01, 2005 3:58 pm    Post subject: Re: satisfying pure virtual function through inheritance Ulrich Eckhardt wrote: Quote: Greetings! I just tried this here: | struct interface | { | virtual void foo() = 0; | }; | | struct implementation | { | void foo() {} | }; | | struct combined: interface, implementation | { | }; | | combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder is [snip] b) what are ways around it? struct combined: interface, implementation { inline void foo() { return implementation::foo(); } }; Because combined::foo() is inlined, calls such as cb.foo(); will be every bit as efficient as calls to cb.implementation::foo(); Because it's defined in struct combined, it will satisfy the need to override interface::foo(), so your virtual calls will work as well. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ulrich Eckhardt Guest Posted: Sat Oct 01, 2005 4:06 pm    Post subject: Re: satisfying pure virtual function through inheritance Jack Klein wrote: Quote: What happens if you have a third type: struct another { void foo() {} }; ...and combined inherits from all three? Which foo() implements the pure virtual? Which one gets called? Well, in that case the resolution is ambiguous. The same argument applies to this case though: void foo(float); void foo(short); foo(1); In this case, when either foo() is absent, the other is called, so why not in my case? Uli -- Questions ? see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first ! [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Antoun Kanawati Guest Posted: Sat Oct 01, 2005 9:23 pm    Post subject: Re: satisfying pure virtual function through inheritance Virtanen Antti wrote: Quote: What would be the reason to allow this? After all, structs are not classes and IMHO should not be used as classes. struct is identical to class, excpet that one of them starts with an implicit 'public' the other with 'private' for member visibility. --ak [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Greg Herlihy Guest Posted: Sun Oct 02, 2005 1:30 am    Post subject: Re: satisfying pure virtual function through inheritance Ulrich Eckhardt wrote: Quote: Greetings! I just tried this here: | struct interface | { | virtual void foo() = 0; | }; | | struct implementation | { | void foo() {} | }; | | struct combined: interface, implementation | { | }; | | combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder ist a) what is the reason not to allow this? In order to instantiate a "combined" object, the combined class must implement the pure virtual method interface::foo by overriding it. Inheriting a function called foo from another base class does not override the other foo. Purely from a practical viewpoint, it's very hard to see how vtables which are the mechanism typically used by C++ compilers to support polymorphism could accomodate a virtual override by an inherited, non-virtual function. Nor do I see much benefit from such a feature in the first place. It seems more likely to surprise programmers than it would be to solve common problems. Quote: What dangers would it bring if implementation::foo satisfied the virtual function, what would break? What programs would break if the inherited foo did override the pure virtual foo? I'm sure such a change would break some program somewhere. But the question is premature. As others have already pointed out, this hypothetical feature has not been clearly defined. It is rife with potential ambiguity. Even if those issues were worked out, there are the technical obstacles I just mentioned. Assuming those could be surmounted, then its impact on existing programs would have to be considered. Quote: b) what are ways around it? I don't quite understand why the obvious approach is inadequate: struct implementation : public interface { void foo(); ... Note the two possible meanings for the method foo() above. The first possibility is that interface declares a pure virtual method foo, so implementation is providing an override for foo. The other possibility is that there is no foo method in the base class, and implementation is thereby declaring its own (non-virtual) method foo. As far as I understand the problem, this kind of conditional declaration of foo - to be either virtual or non-virtual - is the goal. So perhaps an approach along these lines would work. Quote: My problem is that the virtual function declarations (and stubs returning an error code) are generated from an interface description and I need to manually implement them. Further, there are two use-cases where in one, the virtual functions are called by the framework (i.e. they should be private virtual functions that can be overridden) or they can be part of a publicly available API (and then there is no need to override them so they should be public nonvirtual). What I'm mostly pondering over is how I can combine these two use-cases and still create code that is clear but doesn't do things twice. For that case I would like to have the mentioned 'class implementation' which is manually written and, depending on the context, used directly or called indirectly via the framework. Another thing in that context is how would I best make sure, in case the autogenerated code changes a parameter in a virtual function, that I catch this so the implementations don't suddenly turn from overrides into overloads? I tried all compilers I have, neither of them warned me - or maybe I'm just not giving them the right switch, I haven't completed that part of my homework yet. I would declare the methods pure virtual in the base class. A subclass cannot be instantiated directly unless it overrides every pure virtual method it inherits. Therefore any change that would cause a method in the derived class to overload - instead to override - an inherited method will provoke an error when the derived class is instantiated. It is in fact that very error (instantiating an abstract class) that prevents the combination class from being instantiated in example above. Greg [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Sun Oct 02, 2005 1:35 am    Post subject: Re: satisfying pure virtual function through inheritance * Ulrich Eckhardt: Quote: Greetings! I just tried this here: | struct interface | { | virtual void foo() = 0; | }; | | struct implementation | { | void foo() {} | }; | | struct combined: interface, implementation | { | }; | | combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder ist a) what is the reason not to allow this? What dangers would it bring if implementation::foo satisfied the virtual function, what would break? 'implementation' is unrelated to 'interface', and one doesn't want functions that just by accident have the same signature to override each other. Quote: b) what are ways around it? Make them related: struct interface { virtual void foo() = 0; }; struct implementation: virtual interface { void foo() {} }; struct combined: virtual interface, implementation { }; combined cb; Although as you can see it's now redundant to let 'combined' inherit directly from 'interface'. Quote: My problem is that the virtual function declarations (and stubs returning an error code) are generated from an interface description and I need to manually implement them. Further, there are two use-cases where in one, the virtual functions are called by the framework (i.e. they should be private virtual functions that can be overridden) or they can be part of a publicly available API (and then there is no need to override them so they should be public nonvirtual). What I'm mostly pondering over is how I can combine these two use-cases and still create code that is clear but doesn't do things twice. For that case I would like to have the mentioned 'class implementation' which is manually written and, depending on the context, used directly or called indirectly via the framework. Another thing in that context is how would I best make sure, in case the autogenerated code changes a parameter in a virtual function, that I catch this so the implementations don't suddenly turn from overrides into overloads? As long as the interface member functions are pure virtual the compiler will tell you. If not, you can get some help -- but no guarantee -- from techniques like struct implementation: virtual interface { void foo() { static_cast<void(interface::*)()>( &interface::foo ); // Implementation code here. } }; Hth. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ulrich Eckhardt Guest Posted: Sun Oct 02, 2005 1:35 am    Post subject: Re: satisfying pure virtual function through inheritance Virtanen Antti wrote: Quote: After all, structs are not classes and IMHO should not be used as classes. Ahem, structs _are_ classes. This starts with the single difference being the default access to members and baseclasses (private vs public) and goes on with the possibility to declare a struct and then define a class instead of a struct. Uli -- Questions ? see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first ! [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Arno Guest Posted: Sun Oct 02, 2005 1:48 am    Post subject: Re: satisfying pure virtual function through inheritance A partial solution could be templating the implementation with the interface it implements: class Interface { virtual int func()=0; } template< class TInterface > class Implementation: public TInterface { int func() { ... } }; class User: public Implementation {}; [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Perks and Sarah Moun Guest Posted: Sun Oct 02, 2005 4:17 pm    Post subject: Re: satisfying pure virtual function through inheritance I thought this could be solved by by bringing the implementation function into the combined class's scope, but: struct A { virtual void f() = 0; }; struct B { void f(); }; struct C : A, B { using B::f; }; C c; D:gubbinsthingthing.cpp(20) : error C2259: 'C' : cannot instantiate abstract class due to following members: D:gubbinsthingthing.cpp(19) : see declaration of 'C' D:gubbinsthingthing.cpp(20) : warning C4259: 'void __thiscall A::f(void)' : pure virtual function was not defined D:gubbinsthingthing.cpp(17) : see declaration of 'f' Why wouldn't the using declaration (which acts as a disambiguator if the methods aren't abstract) mean that C::f is well-defined, and so resolve the problem? Thanks John [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Sun Oct 02, 2005 8:21 pm    Post subject: Re: satisfying pure virtual function through inheritance Virtanen Antti wrote: Quote: On 2005-09-29, Ulrich Eckhardt <eckhardt (AT) satorlaser (DOT) com> wrote: I just tried this here: | struct interface | { | virtual void foo() = 0; | }; | struct implementation | { | void foo() {} | }; | struct combined: interface, implementation | { | }; | combined cb; But GCC rejects it, saying that 'combined' doesn't implement the required virtual function. What I wonder ist a) what is the reason not to allow this? What would be the reason to allow this? After all, structs are not classes and IMHO should not be used as classes. There is no fundamental different between struct and class in C++. It is common practice, when discussing language issues involving public inheritance, to use struct rather than class simply to avoid all of the extra "public" keywords, which are irrelevant to the problem. Quote: What dangers would it bring if implementation::foo satisfied the virtual function, what would break? Designer's and maintainer programmer's heads at least, It's a rule. In Java, it works, and it doesn't seem to cause too many problems. I'm not convinced that the Java rule is better, but I do need more arguments, one way or the other, before making up my mind. Changing the rule would definitely make mixin's easier. On the other hand, mixin's aren't common enough to warrant changing it if there are other arguments in favor of the current rule. Quote: but there's likely to be better reasons for not allowing this sort of constructs. What I'm mostly pondering over is how I can combine these two use-cases and still create code that is clear but doesn't do things twice. For that case I would like to have the mentioned 'class implementation' which is manually written and, depending on the context, used directly or called indirectly via the framework. I didn't quite understand your problem, but your "combined" class (it is logically a class, even if you name it a struct) Of course it's a class -- in C++, the keyword struct defines a class. Quote: inherits the method "foo" twice with the same signature (return value and parameters). How is the compiler supposed to know which one of the two logical possibilities you want to use? Because only one is not pure virtual. Quote: In this particular case, there's of course the logical solution, but the compiler can't see it. The compiler knows very well which functions are pure virtual, and which aren't. Quote: After all, "implementation" doesn't have anything in common with your "interface", so how is the compiler supposed to know that "foo" in "implementation" is the one you want to use as an implementation for the "foo" in "interface"? The problem isn't for the compiler. The problem is that the author of implementation may not know about interface, and may not have respected the contract for interface::foo in his implementation. A more justifiable variant might be: struct interface { virtual void foo() = 0 ; } ; struct implementation : virtual interface { virtual void foo() {} } ; struct combined : virtual interface, implemenation { } ; And in fact, this works (and is a frequent pattern in Barton and Nackman). -- James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Virtanen Antti Guest Posted: Mon Oct 03, 2005 8:57 pm    Post subject: Re: satisfying pure virtual function through inheritance On 2005-10-02, James Kanze <kanze (AT) none (DOT) news.free.fr> wrote: Quote: What would be the reason to allow this? After all, structs are not classes and IMHO should not be used as classes. There is no fundamental different between struct and class in C++. Yes. I don't quite understand why, but so it is. Quote: I didn't quite understand your problem, but your "combined" class (it is logically a class, even if you name it a struct) Of course it's a class -- in C++, the keyword struct defines a class. Maybe so. Why is there a keyword "class" then, since we could well live without it and the committee has been reluctant to introduce new keywords the language (which is a wise policy IMHO) ? The fact that there are two different ways of saying the same thing doesn't mean we should use them interchangably and not worry about anything. Saving a few keystrokes by playing with the default visibility is one thing and avoiding logical inconsistencies is another. After all, C++ is afaik the only object oriented language in which structs are really classes and vice versa. It seems you can even declare a class and instantiate an object from the class using the old C-trick: class singleton { // put some members here } singleton_; Cool? I don't think this is reasonable, even if it's still perfectly valid, was usual practise in the golden C-hacking days, and may save us a few keystrokes. A few other issues that popped into my mind: 1) If a project mixes code written in C and C++, is it a good thing to declare methods and inheritance hierarchies with the struct keyword? 2) What about mixing C++ and C#? In C# many things work exactly like they do in C++, but are structs still interchangable with classes in C#? 3) struct inheritance is slightly different from class inheritance. If no agreement has been done about the keyword used to declare the base class (and no inheritance type is explicitly speecified), this may provide some surprises. Usually the surprise is a compile-time error and nothing fancy, of course. Bjarne Stroustroup writes in "C++ programming language 3rd edition": "Which style you use depends on circumstances and taste. I usually prefer to use struct for classes that have all data public. I think of such classes as 'not quite proper types, just data structures.'" I tend to agree with the guy. I may write a constructor for a struct, so I'm not a purist in this issue. Of course, this comes finally down to "circumstances and taste" which can be argued about endlessly, but I find it pretty alarming if I see "real" classes declared with the struct keyword. Quote: In this particular case, there's of course the logical solution, but the compiler can't see it. The compiler knows very well which functions are pure virtual, and which aren't. Okay agreed, but still, in the form originally presented, the compiler would have to figure out that it is indeed the "foo" in "interface" which should be implemented by the other inherited class, even though this other class makes no reference to the "interface". This is something I wish the compilers do not reason out automatically when they encounter two matching signatures from unrelated classes (unrelated from the compiler's point of view). Btw. the original form of the code won't compile in Java because the compiler refuses to figure that out. The Java compiler is most wise in this issue IMHO. Quote: A more justifiable variant might be: Yes and as you pointed out, your variant also compiles, which is reasonable. -- // Antti Virtanen -//- http://www.students.tut.fi/~virtanea -//- 050-4004278 "Aivan samoin jos kirjastosta jatkuvasti varastettaisiin kirjoja, niin varmaan jonkinlainen muutos tulisi kirjastolaitokseen. Tässä tapahtuu nyt todella niin, että varkaiden kautta rehellinen kuluttaja joutuu kiusalliseen tilanteeseen, kun tätä lakia on muutettu. Irina Krohn selittää eduskunnassa tekijänoikeuslakia 29.9.2005 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ulrich Eckhardt Guest Posted: Tue Oct 04, 2005 2:07 pm    Post subject: Re: satisfying pure virtual function through inheritance Alf P. Steinbach wrote: Quote: Make them related: struct interface { virtual void foo() = 0; }; struct implementation: virtual interface { void foo() {} }; struct combined: virtual interface, implementation { }; combined cb; Although as you can see it's now redundant to let 'combined' inherit directly from 'interface'. Yes, of course that is a solution. My problem is that 'implementation' is a stand-alone class which has nothing to do with 'interface' per se. Therefore, it should not derive from 'interface'. In fact, 'interface' is not a pure interface but features a network interface which dispatches traffic to the virtual functions. In part, those functions are covered by 'implementation'. The best solution I have come across would have been to use the kind of derivation which I described, but that is not covered by C++. Quote: Another thing in that context is how would I best make sure, in case the autogenerated code changes a parameter in a virtual function, that I catch this so the implementations don't suddenly turn from overrides into overloads? As long as the interface member functions are pure virtual the compiler will tell you. If not, you can get some help -- but no guarantee -- from techniques like struct implementation: virtual interface { void foo() { static_cast<void(interface::*)()>( &interface::foo ); // Implementation code here. } }; IOW, use static_cast to make sure that the interface defined in the baseclass is the same as that defined in the derived one. Good idea, thanks! Uli [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ulrich Eckhardt Guest Posted: Tue Oct 04, 2005 2:09 pm    Post subject: Re: satisfying pure virtual function through inheritance Allan W wrote: Quote: struct combined: interface, implementation { inline void foo() { return implementation::foo(); } }; Because combined::foo() is inlined, calls such as cb.foo(); will be every bit as efficient as calls to cb.implementation::foo(); Because it's defined in struct combined, it will satisfy the need to override interface::foo(), so your virtual calls will work as well. Leaving aside the diverging definitions of inline from standard and reality, you confused me with your statement: 1. At the point where 'foo()' is invoked on a reference to 'interface', the definition of it is unknown, so nothing can be inlined. The call must go via the virtual function table to an non-inline 'combined::foo()' which adjusts 'this' for the difference between the 'interface' and 'implementation' subobjects and then invokes 'implementation::foo()'. 2. When 'foo()' is invoked on an object who's full dynamic type is known at compile time, this indeed can be completely inlined. In my case, version 1 is when the function is invoked via an RPC-like dispatcher. Version 2 is when the functions are invoked directly, but in that case I'd rather use only objects of type 'implementation' and ignore the additional overhead. Uli [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] 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 (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   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.