C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Proposal: interfaces Goto page 1, 2, 3, 4  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message christopher diggins Guest Posted: Fri Apr 09, 2004 2:45 pm    Post subject: Proposal: interfaces Motivation ========== C++ designs that inherit from multiple pure abstract base classes introduce multiple vtables that cause rapid bloating of objects that is uneccessary. The current solution is an unacceptable "just don't do that". Proposed Solution ================= - interface reference type (fat pointer which points to object and to interface function table) - implements interface declarations class FuBar { implement IFuBar; ... }; - instantiable interface declaration semantics i.e. interface SomeInterface { FuBar1(); ... }; - a downloadable example and demonstration is available at : http://www.heron-language.com/heronfront.html Advantages of Proposal ====================== - no code bloat when compared to comparable ABC design - faster than comparable designs using ABC's - introduction of proposal requires virtually no changes to other parts of language standard -- Christopher Diggins http://www.cdiggins.com http://www.heron-language.com --- [ 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 Larry Evans Guest Posted: Fri Apr 09, 2004 3:49 pm    Post subject: Re: Proposal: interfaces christopher diggins wrote: Quote: Motivation ========== C++ designs that inherit from multiple pure abstract base classes introduce multiple vtables that cause rapid bloating of objects that is uneccessary. The current solution is an unacceptable "just don't do that". Proposed Solution ================= - interface reference type (fat pointer which points to object and to interface function table) - implements interface declarations Hi christopher, I'm just guessing, but also hoping that what you're proposing might help in something akin to dynamic inheritance. I've wanted to create something like a "base" class heirarchy and then "decorate" it with different "views". An example of what I'm trying to do is at: http://groups.yahoo.com/group/boost/files/regexp_first.zip it implements inheritance of T via superclass smart_ptr<T>; however, this obviously requires the inheriting class to forward all calls to the superclass. But the inheriting class would need to have a virtual function table whose only purpose would be to provide forwarding functions. Can you tell me how this interface feature would help in the regexp_first code? I'd be happy to email you the code directly if that would help. Regards, Larry --- [ 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 Larry Evans Guest Posted: Fri Apr 09, 2004 10:38 pm    Post subject: Re: Proposal: interfaces Larry Evans wrote: Quote: christopher diggins wrote: [snip] with different "views". An example of what I'm trying to do is at: http://groups.yahoo.com/group/boost/files/regexp_first.zip Another example of where interfaces MAY be useful is with the code at: http://groups.yahoo.com/group/boost/files/managed_ptr/overhead_referent_vals.zip The Overhead will contain a virtual DTOR in order to be able to call the Referent DTOR, but this causes the "bloat" of another VFT. Could this interface feature avoid that? --- [ 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 Alberto Barbati Guest Posted: Sat Apr 10, 2004 6:50 am    Post subject: Re: Proposal: interfaces christopher diggins wrote: Quote: Motivation ========== C++ designs that inherit from multiple pure abstract base classes introduce multiple vtables that cause rapid bloating of objects that is uneccessary. The current solution is an unacceptable "just don't do that". This motivation is valid in several problem domains, yet it's not valid in general. I still can imagine examples where abstract base classes are necessary and where the overhead of current implementation is acceptable. Whether your motivation is sufficient to justify a language extension, I cannot tell. Keep in mind that linkers are getting smarter and smarter and link-time code generation may (if not now, in the future) greatly reduce the code bloat that you are worried about. Quote: Proposed Solution ================= - interface reference type (fat pointer which points to object and to interface function table) - implements interface declarations class FuBar { implement IFuBar; ... }; - instantiable interface declaration semantics i.e. interface SomeInterface { FuBar1(); ... }; You suggest to introduce two new keywords but for sure you know how the committee is reluctant to add those. The "implement" keyword is unnecessary, IMHO. I don't see any problem in using the common syntax: class FuBar : public IFuBar ... }; As for the "interface" keyword, a replacement could be: class SomeInterface = 0 { FuBar1(); ... }; as "= 0" is already used for abstract virtual functions, the meaning should be clear. Alternatively, one could overload the keyword "virtual": virtual class SomeInterface { FuBar1(); ... }; Quote: - a downloadable example and demonstration is available at : http://www.heron-language.com/heronfront.html The fact that you can provide one implementation that gives good results doesn't demonstrate anything. See below... Quote: Advantages of Proposal ====================== - no code bloat when compared to comparable ABC design - faster than comparable designs using ABC's - introduction of proposal requires virtually no changes to other parts of language standard Your "solution" looks just like a syntax to me. It's not self-evident how the advantages that you are claiming are obtained and, even more important, why similar advantages cannot be obtained in another way. Exactly I would like to understand: 1) precisely what code won't be generated w.r.t. the ABC syntax 2) how your proposed syntax helps to eliminate such code 3) why your proposed syntax is essential to eliminate such code (i.e.: does it provide an essential information about the code that couldn't be obtained in other way programmatically, possibly at link-time?) -- Alberto Barbati --- [ 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 Dave Harris Guest Posted: Sat Apr 10, 2004 4:10 pm    Post subject: Re: Proposal: interfaces [email]cdiggins (AT) videotron (DOT) ca[/email] ("christopher diggins") wrote (abridged): Quote: - instantiable interface declaration semantics i.e. How does an interface differ from an abstract base class? Can an interface have non-pure virtual functions? Non-virtual functions? Static member variables? Or are they just like in Java? Your motive seems to be performance. I suspect the Java model is more restrictive than is necessary for performance, for ideological reasons. I think that the killer problem with implementing ABCs is dealing with non-static instance variables. But I could be wrong. I would like to see a much more detailed analysis than that you show on your web site. I'd like to see exactly where the overhead of ABCs comes from. Have you considered other implementation techniques for ABCs, eg thunks, or cached searches? Can you prove that the only way to get performance is by using the restricted form of interfaces? -- 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 ] Back to top John Nagle Guest Posted: Sat Apr 10, 2004 7:11 pm    Post subject: Re: Proposal: interfaces Could you arrange to host your files on an openly accessable website? Thanks. John Nagle Animats Larry Evans wrote: Quote: Larry Evans wrote: christopher diggins wrote: [snip] with different "views". An example of what I'm trying to do is at: http://groups.yahoo.com/group/boost/files/regexp_first.zip Another example of where interfaces MAY be useful is with the code at: http://groups.yahoo.com/group/boost/files/managed_ptr/overhead_referent_vals.zip --- [ 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 christopher diggins Guest Posted: Sun Apr 11, 2004 5:16 am    Post subject: Re: Proposal: interfaces "Dave Harris" <brangdon (AT) cix (DOT) co.uk> wrote Quote: cdiggins (AT) videotron (DOT) ca ("christopher diggins") wrote (abridged): - instantiable interface declaration semantics i.e. How does an interface differ from an abstract base class? Can an interface have non-pure virtual functions? Non-virtual functions? Static member variables? Or are they just like in Java? Your motive seems to be performance. My motive is performance in so much that I want to have the freedom to write a class that implements multiple interfaces without having to worry about being hit with ever-increasing size and speed penalties that are uneccessary. Quote: I suspect the Java model is more restrictive than is necessary for performance, for ideological reasons. I think that the killer problem with implementing ABCs is dealing with non-static instance variables. I think the killer problem is the overwhelmingly common misconception that an interface is the same as an ABC and that the functions should be virtual. Quote: But I could be wrong. I would like to see a much more detailed analysis than that you show on your web site. I'd like to see exactly where the overhead of ABCs comes from. I would have thought that was relatively common knowledge. Quote: Have you considered other implementation techniques for ABCs, eg thunks, or cached searches? No, I am not concerned with ABC's specifically but how they are a poor substitute for an interface. Quote: Can you prove that the only way to get performance is by using the restricted form of interfaces? I can't prove that because it isn't true. There are lots of ways improving performance. Quote: -- Dave Harris, Nottingham, UK -- Christopher Diggins http://www.cdiggins.com http://www.heron-language.com --- [ 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 David Abrahams Guest Posted: Sun Apr 11, 2004 11:03 pm    Post subject: Re: Proposal: interfaces [email]cdiggins (AT) videotron (DOT) ca[/email] ("christopher diggins") writes: Quote: "Dave Harris" <brangdon (AT) cix (DOT) co.uk> wrote in message news:memo.20040410131032.2400A (AT) brangdon (DOT) m... [email]cdiggins (AT) videotron (DOT) ca[/email] ("christopher diggins") wrote (abridged): - instantiable interface declaration semantics i.e. How does an interface differ from an abstract base class? Can an interface have non-pure virtual functions? Non-virtual functions? Static member variables? Or are they just like in Java? Your motive seems to be performance. My motive is performance in so much that I want to have the freedom to write a class that implements multiple interfaces without having to worry about being hit with ever-increasing size and speed penalties that are uneccessary. I suspect the Java model is more restrictive than is necessary for performance, for ideological reasons. I think that the killer problem with implementing ABCs is dealing with non-static instance variables. I think the killer problem is the overwhelmingly common misconception that an interface is the same as an ABC and that the functions should be virtual. Has anyone suggested the "good-old CRTP" yet? // base class template for all interfaces template <class Derived> struct interface { protected: Derived& self() { return *static_cast<Derived*>(this); } Derived const& self() const { return *static_cast<Derived const*>(this); } }; // a specific interface - requires that Derived supports foo and bar template <class Derived> struct foobar : interface<Derived> { void baz() { this->self().foo(); this->self().bar(); } }; // A specific implementation of the foobar interface struct my_foobar : foobar<my_foobar> { void foo(); void bar(); }; Look, ma, no virtual functions! Cheers, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ 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 vze2hb3b@verizon.net Guest Posted: Mon Apr 12, 2004 6:44 pm    Post subject: Re: Proposal: interfaces Quote: Has anyone suggested the "good-old CRTP" yet? // base class template for all interfaces template <class Derived struct interface { protected: Derived& self() { return *static_cast Derived const& self() const { return *static_cast<Derived const*>(this); } }; // a specific interface - requires that Derived supports foo and bar template <class Derived struct foobar : interface { void baz() { this->self().foo(); this->self().bar(); } }; // A specific implementation of the foobar interface struct my_foobar : foobar<my_foobar { void foo(); void bar(); }; Look, ma, no virtual functions! Cheers, Dave Is't there a problem when using different classes implementing foobar? I would have to declare my_foobar and your_foobar like this: foobar< my_foobar > & foobar_1 = *new my_foobar; foobar< your_foobar > & foobar_2 = *new your_foobar; Then references foobar_1 and foobar_2 would have different types which is not what happens for interfaces in Java, for example, which is a limitation since I won't be able, for instance, to define a function i that has a parameter of type "interface foobar" unless I want to templatize everything that deals with that interface. Regards, -- Aleksandr Morgulis [email]aleksandr.morgulis (AT) verizon (DOT) net[/email] --- [ 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 christopher diggins Guest Posted: Tue Apr 13, 2004 3:29 am    Post subject: Re: Proposal: interfaces "David Abrahams" <dave (AT) boost-consulting (DOT) com> wrote Quote: cdiggins (AT) videotron (DOT) ca ("christopher diggins") writes: <snip> Quote: Has anyone suggested the "good-old CRTP" yet? <snip> Quote: Look, ma, no virtual functions! The CRTP(?) approach does indeed have no virtual functions but is lacking of polymorphism on the interface because every "implementation" would have a different base type. -- Christopher Diggins http://www.cdiggins.com http://www.heron-language.com --- [ 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 christopher diggins Guest Posted: Tue Apr 13, 2004 3:33 am    Post subject: Re: Proposal: interfaces "Alberto Barbati" <AlbertoBarbati (AT) libero (DOT) it> wrote Quote: christopher diggins wrote: Motivation ========== C++ designs that inherit from multiple pure abstract base classes introduce multiple vtables that cause rapid bloating of objects that is uneccessary. The current solution is an unacceptable "just don't do that". This motivation is valid in several problem domains, yet it's not valid in general. I still can imagine examples where abstract base classes are necessary and where the overhead of current implementation is acceptable. Whether your motivation is sufficient to justify a language extension, I cannot tell. Keep in mind that linkers are getting smarter and smarter and link-time code generation may (if not now, in the future) greatly reduce the code bloat that you are worried about. This was a big error on my part in the presentation of the proposal. I don't propose to replace ABC's but rather introduce interfaces as being an appropriate alternative for certain design scenarios which call for them (i.e. behaves-like and looks-like object relationships). I agree that ABC's are a perfectly acceptable and balanced solution in many cases and shouldn't be replaced. Linkers do nothing to deal with the larger problem of object bloat when implementing large numbers of ABC's. Quote: Proposed Solution ================= - interface reference type (fat pointer which points to object and to interface function table) - implements interface declarations class FuBar { implement IFuBar; ... }; - instantiable interface declaration semantics i.e. interface SomeInterface { FuBar1(); ... }; You suggest to introduce two new keywords but for sure you know how the committee is reluctant to add those. The "implement" keyword is unnecessary, IMHO. I don't see any problem in using the common syntax: The committee prejudices don't concern me at this point with regards to the syntax. But in general, I have confidence that they measure each proposal carefully and separately without preconcieved notions. Quote: class FuBar : public IFuBar ... }; As for the "interface" keyword, a replacement could be: class SomeInterface = 0 { FuBar1(); ... }; as "= 0" is already used for abstract virtual functions, the meaning should be clear. Alternatively, one could overload the keyword "virtual": virtual class SomeInterface { FuBar1(); ... }; Your syntax proposal is interesting and clever, I credit you with it in the rewrite of my proposal. Quote: - a downloadable example and demonstration is available at : http://www.heron-language.com/heronfront.html The fact that you can provide one implementation that gives good results doesn't demonstrate anything. See below... I am demonstrating the technique as opposed to proving things. Some people need to see tangible work before they take theoretical notions into consideration. Quote: Advantages of Proposal ====================== - no code bloat when compared to comparable ABC design - faster than comparable designs using ABC's - introduction of proposal requires virtually no changes to other parts of language standard Your "solution" looks just like a syntax to me. It's not self-evident how the advantages that you are claiming are obtained and, even more important, why similar advantages cannot be obtained in another way. It is more than syntax I am trying to propose. It is the fact that an interface is not an ABC. See http://www.heron-language.com/abc-iop.html. Quote: Exactly I would like to understand: 1) precisely what code won't be generated w.r.t. the ABC syntax Virtual functions and dynamic dispatch of functions within the object implementing an interface would not be generated. Quote: 2) how your proposed syntax helps to eliminate such code Becaue an interface is clearly not an ABC there is no point to using virtual functions as it conflicts with the intent. Quote: 3) why your proposed syntax is essential to eliminate such code (i.e.: does it provide an essential information about the code that couldn't be obtained in other way programmatically, possibly at link-time?) The proposed syntax differentiates the notion of implementing an interface from inheriting an ABC. The main difference is that implementing an interface does no imply virtualization of the functions. This fact can by easily leveraged by an implementation to create a more efficient usage of interfaces compared with the naive comparable implementation using ABC's. The intent of using ABC as an interface is not easily knowable to a compiler/linker and having the compiler have different representations of an ABC depending on context would probably not be a practically possible option. Thanks for your comments Alberto -- Christopher Diggins http://www.cdiggins.com http://www.heron-language.com --- [ 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 David Abrahams Guest Posted: Tue Apr 13, 2004 3:35 am    Post subject: Re: Proposal: interfaces [email]vze2hb3b (AT) verizon (DOT) net[/email] writes: Quote: Is't there a problem when using different classes implementing foobar? It depends on your requirements. Please re-read the part of my post that you snipped: ----- [email]cdiggins (AT) videotron (DOT) ca[/email] ("christopher diggins") wrote: Quote: My motive is performance in so much that I want to have the freedom to write a class that implements multiple interfaces without having to worry about being hit with ever-increasing size and speed penalties that are uneccessary. I suspect the Java model is more restrictive than is necessary for performance, for ideological reasons. I think that the killer problem with implementing ABCs is dealing with non-static instance variables. I think the killer problem is the overwhelmingly common misconception that an interface is the same as an ABC and that the functions should be virtual. ------- Quote: I would have to declare my_foobar and your_foobar like this: foobar< my_foobar > & foobar_1 = *new my_foobar; foobar< your_foobar > & foobar_2 = *new your_foobar; Then references foobar_1 and foobar_2 would have different types which is not what happens for interfaces in Java, for example, which is a limitation since I won't be able, for instance, to define a function i that has a parameter of type "interface foobar" unless I want to templatize everything that deals with that interface. Of course. You can't have it both ways: either you get type erasure, dynamic polymorphism, and you pay the runtime cost of virtual functions, or you preserve type distinctions, use static polymorphism, and avoid the runtime cost of virtual functions. In C++, it's up to you to choose. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com --- [ 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 Pete Vidler Guest Posted: Tue Apr 13, 2004 2:58 pm    Post subject: Re: Proposal: interfaces christopher diggins wrote: [snip] Quote: The CRTP(?) approach does indeed have no virtual functions but is lacking of polymorphism on the interface because every "implementation" would have a different base type. CRTP = Curiously Recurring Template Pattern. The compile-time polymorphism is gained through the use of templates whenever you need to take different "interfaces". -- Pete --- [ 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 David Abrahams Guest Posted: Tue Apr 13, 2004 2:59 pm    Post subject: Re: Proposal: interfaces [email]dave (AT) boost-consulting (DOT) com[/email] (David Abrahams) writes: Quote: Of course. You can't have it both ways: either you get type erasure, dynamic polymorphism, and you pay the runtime cost of virtual functions, or you preserve type distinctions, use static polymorphism, and avoid the runtime cost of virtual functions. In C++, it's up to you to choose. Sorry, I obviously didn't read the proposal carefully. The proposal wants to trade object size for increased (interface) pointer size. That's not available in C++, at least, not with a nice syntax. I think the proposal misses that you also need fat references, in order to allow (*interface_pointer).foo() Cheers, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com --- [ 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 Dave Harris Guest Posted: Tue Apr 13, 2004 7:32 pm    Post subject: Re: Proposal: interfaces [email]cdiggins (AT) videotron (DOT) ca[/email] ("christopher diggins") wrote (abridged): Quote: How does an interface differ from an abstract base class? Can an interface have non-pure virtual functions? Non-virtual functions? Static member variables? Or are they just like in Java? I would still like to see this answered. In my view you have not yet made a case for your new feature. Quote: Have you considered other implementation techniques for ABCs, eg thunks, or cached searches? No, I am not concerned with ABC's specifically but how they are a poor substitute for an interface. Why are they are poor substitute? It seems to me Java interfaces have restrictions which make them less useful than C++ classes. Quote: Can you prove that the only way to get performance is by using the restricted form of interfaces? I can't prove that because it isn't true. There are lots of ways improving performance. You just said your motivation was performance. If you can get the performance of interfaces with ABCs, why do you want the new feature? Maybe in, say, 5 or 10 years time, when all the compiler vendors have "export" working properly and they have turned their attention to optimisation, they will find better ways of implementing ABCs. Then interfaces will not be necessary. Do you have any good reason for thinking this cannot happen? -- 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 ] 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 Goto page 1, 2, 3, 4  Next Page 1 of 4   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.