C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  [RFC] Auto functions: an interesting feature?          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message stelios xanthakis Guest Posted: Sun Sep 07, 2003 1:56 am    Post subject: [RFC] Auto functions: an interesting feature? Hi fellows. This is not strictly related to C++, but I understand that future directions are of interest in this group. Auto functions is a new feature that has just been added to the lwc preprocessor and the goal is to achieve code expansion in a template-like schema. Here is what happens: If an auto function is not redefined by the programmer in a derrived class, the compiler will automatically redefine it by its most recent definition. As a result, a definition exists for every sub-object. With this consequence, important optimizations can be done: virtual calls are direct member calls and members of virtual base classes are accessed directly from the common shared object. An example: class A { protected: virtual int f () { return 1; } public: auto virtual int av (); }; int A::av () { int i, s; for (i=s=0;i<10000;i++) s += f (); return s; } class B : public A { int f () { return 2; } } Here, the compiler shall define two functions, A::av and B::av. In these it will probably be able to actually inline the different 'f' functions. Do you think this is a useful extension? Any flaws in it? A reason why this was not implemented in C++? More Ideas? Salut, stelios [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Torsten Robitzki Guest Posted: Sun Sep 07, 2003 3:23 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? stelios xanthakis wrote: Quote: Do you think this is a useful extension? Any flaws in it? A reason why this was not implemented in C++? More Ideas? I don't think that this would be a useful extension to the language. If one would want to let the compiler generated code like you want, the simplest solution would be to ask the compiler to do so: class A { public: virtual int av() { return loop<1>(); } protected: template <int I> static int loop() { int i, s; for (i=s=0;i<10000;i++) s += I; return s; } }; But ok, I understood that this was just an example I think optimizations hint like auto or inline should be left out of the code because most compiler should know much more about the underlying architecture then a programmer do. A good compiler/linker set might do that optimization on there own in a pre linking step. But I doubt that there is any jet who do so. Until such optimizations are available my suggested solution will do the job without any changes to the language that will be pointless in 10 years. Or is there anyone out still using auto qualified variables today? regards Torsten [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Mon Sep 08, 2003 6:25 am    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]mayall (AT) freemail (DOT) gr[/email] (stelios xanthakis) wrote (abridged): Quote: Auto functions is a new feature that has just been added to the lwc preprocessor and the goal is to achieve code expansion in a template-like schema. Here is what happens: If an auto function is not redefined by the programmer in a derrived class, the compiler will automatically redefine it by its most recent definition. As a result, a definition exists for every sub-object. With this consequence, important optimizations can be done: virtual calls are direct member calls and members of virtual base classes are accessed directly from the common shared object. An example: Would auto affect the semantics in any way, or is it just for efficiency? Is there any reason a compiler cannot replicate a function in derived classes on its own, without the hint? This sounds a well-known compiler optimisation (at least in some circles) called "specialisation". Optimisations are permitted provided they don't affect the visible behaviour of the program. In this case, the compiler would need to be sure that all the replications have the same address and use the same local statics. Were you planning any special treatment for statics in "auto" functions? Quote: class A { protected: virtual int f () { return 1; } public: auto virtual int av (); }; int A::av () { int i, s; for (i=s=0;i<10000;i++) s += f (); return s; } class B : public A { int f () { return 2; } } Note that is not actually necessary to redefine av() in every subclass. Only in subclasses that redefine f(). How is the compiler supposed to discover the source code for av() that it needs to replicate? Would it be easier to implement if A::av() were required to be inline? -- Dave Harris, Nottingham, UK [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Mike Capp Guest Posted: Mon Sep 08, 2003 8:30 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]mayall (AT) freemail (DOT) gr[/email] (stelios xanthakis) wrote in message news:<8a018872.0309060412.e9e0109 (AT) posting (DOT) google.com>... Quote: Auto functions is a new feature that has just been added to the lwc preprocessor and the goal is to achieve code expansion in a template-like schema. Here is what happens: If an auto function is not redefined by the programmer in a derrived class, the compiler will automatically redefine it by its most recent definition. As a result, a definition exists for every sub-object. [snip] Do you think this is a useful extension? Any flaws in it? As has already been pointed out, I think template mechanisms can already cover most of the optimization opportunities created by this extension. However, I can see a couple of places where automatically redefining forwarder functions could be useful (albeit kludgey). In particular, it might make interfaces (in the Java/C# sense) a bit more usable in C++. When I derive a class from an interface, all I really care about is ensuring that the class implements that interface. However, defining interfaces as abstract base classes with pure virtual function declarations requires that the concrete class inheriting from the interface *override* those pure virtuals, not just implement equivalent function signatures. So I can't write: class Base { public: virtual void foo() { /* implementation*/ } }; class Interface { public: virtual void foo() = 0; }; class Derived : public Base, public Interface { }; and have Interface::foo() "map" to Base::foo(). If Base::foo() were declared with your "auto", and the compiler generated an inline Derived::foo() forwarding to Base::foo(), this would solve the issue. Automatically generating covariant-return-type overrides might also be a mildly interesting area. Cheers, Mike [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top stelios xanthakis Guest Posted: Mon Sep 08, 2003 8:42 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote in message news:<memo.20030907153303.28313C (AT) brangdon (DOT) madasafish.com>... Quote: Note that is not actually necessary to redefine av() in every subclass. Only in subclasses that redefine f(). Actually. To be typically correct we should guarantee that a function exists for *every* derrived class. The compiler *may* check that there is no need to redefine a function. In this case it must still generate a new version which will just dispatch to the parent function. For example // in class C, nothing is changed! // compiler should do this int C::av () { return B::av (); } These kind of dispatch functions are also very optimizable. A decent compiler will not pop-repush the arguments, it will just upcast 'this' and use a 'jmp' on the function. regards stelios [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top stelios xanthakis Guest Posted: Mon Sep 08, 2003 10:26 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote in message news:<memo.20030907153303.28313C (AT) brangdon (DOT) madasafish.com>... Quote: Would auto affect the semantics in any way, or is it just for efficiency? Is there any reason a compiler cannot replicate a function in derived classes on its own, without the hint? This sounds a well-known compiler optimisation (at least in some circles) called "specialisation". Mainly for efficiency. However there is also a difference: the typeof 'this' changes in every class. As a result we could do something interesting like: class A { auto virtual int dynamic_sizeof () { return sizeof (*this); } I don't think that the compiler should do this on its own. The goal of OOP seems to be maximum code reuse. auto functions is like maximum code expansion, like templates. Quote: Optimisations are permitted provided they don't affect the visible behaviour of the program. In this case, the compiler would need to be sure that all the replications have the same address and use the same local statics. Were you planning any special treatment for statics in "auto" functions? Good point. Hmmm, seems like statics could be "common to the instances of a class". This is the one -interesting- choice. The other choice is that the compiler will extract the local statics into global variables with mangled names. Quote: class A { protected: virtual int f () { return 1; } public: auto virtual int av (); }; class B : public A { int f () { return 2; } } Note that is not actually necessary to redefine av() in every subclass. Only in subclasses that redefine f(). Exactly. Things that make a difference are: - all functions used by auto function, are the same - all virtual base classes accessed through the same shared object. - 'this' is not referenced directly. Also, in the above example, "f" does not even need to be virtual if the only place that calls "f" is "av", and "f" is private. However, this is left to the programmer of course. Quote: How is the compiler supposed to discover the source code for av() that it needs to replicate? Would it be easier to implement if A::av() were required to be inline? Ah yes. auto functions shall be treated like template functions. What happens with template functions is that they are probably placed in linkonce sections and collapsed by the linker: their definition should be in header files. Thus, auto functioning should be explict by the programmer. There is some sample code from lwc at: http://students.ceid.upatras.gr/~sxanth/lwc/ex10.html Thanks stelios [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Tue Sep 09, 2003 9:14 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]mayall (AT) freemail (DOT) gr[/email] (stelios xanthakis) wrote (abridged): Quote: Would auto affect the semantics in any way, or is it just for efficiency? Mainly for efficiency. However there is also a difference: the typeof 'this' changes in every class. OK, that is a bigger change than I thought. So presumably, if the language also had the "typeof" extension, we could do: class Base { public: auto virtual Base *clone() const { return new typeof(*this)( *this ); } }; This is more interesting than a mere optimisation. Go for it. Quote: How is the compiler supposed to discover the source code for av() that it needs to replicate? Would it be easier to implement if A::av() were required to be inline? Ah yes. auto functions shall be treated like template functions. Err, you mean they should be able to use the "export" keyword? // Base.h class Base { public: auto export virtual Base *clone() const; }; // Base.cpp Base *Base::clone() { return new typeof(*this)( *this ); } This is probably a good thing, but maybe should be thought about by someone who understands "export" better than me. Incidently, I have wondered if it would make sense to apply "export" to "inline" also. -- Dave Harris, Nottingham, UK [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top stelios xanthakis Guest Posted: Wed Sep 10, 2003 7:47 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]Mike.Capp (AT) tfn (DOT) com[/email] (Mike Capp) wrote in message news:<1fb5dc65.0309080441.27af680a (AT) posting (DOT) google.com>... Quote: As has already been pointed out, I think template mechanisms can already cover most of the optimization opportunities created by this extension. Indeed. Generally, templates can be used in many cases instead of a hierarchial approach with virtual calls. And more optimized too. If one thinks "optimization" (optimization is the root of all evil:), then clearly the object hierarchy model may be obsolete in many cases. However, IMHO, the OOP model is conceptually better: it leads to a better program structure. So instead using templates I was thinking of a schema that will achieve the same benefits (code expansion) in OOP style. Generic programming not there yet (although in a sci-fi scenario we could have virtual typedefs + all functions are auto) Quote: When I derive a class from an interface, all I really care about is ensuring that the class implements that interface. However, defining interfaces as abstract base classes with pure virtual function declarations requires that the concrete class inheriting from the interface *override* those pure virtuals, not just implement equivalent function signatures. So I can't write: class Base { public: virtual void foo() { /* implementation*/ } }; class Interface { public: virtual void foo() = 0; }; class Derived : public Base, public Interface { }; and have Interface::foo() "map" to Base::foo(). If Base::foo() were declared with your "auto", and the compiler generated an inline Derived::foo() forwarding to Base::foo(), this would solve the issue. Good catch. An alternative to virtual inheritance *is* something. stelios [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Sat Sep 13, 2003 8:00 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote (abridged): Quote: Would auto affect the semantics in any way, or is it just for efficiency? Mainly for efficiency. However there is also a difference: the typeof 'this' changes in every class. OK, that is a bigger change than I thought. Another possible application has just turned up in the thread "Virtual static functions !?!" over in news:comp.std.c++, started by [email]dsp (AT) bdal (DOT) de[/email] on 12 Sep. Daniel Spangenberg wanted a single function definition that could be called either as a static or as a virtual. A workaround is to have a virtual which calls a static. This means redefining the virtual in each derived class. With the "auto function" proposal it could look like: struct Base { static const char *sname() { return "Base"; } auto virtual const char *name() const { return sname(); } }; struct Derived: Base { static const char *sname() { return "Derived"; } }; The compiler generates Derived::name() automatically, which picks up the local version of sname(). We may need some thought about how the template notion of "dependant names" applies here. -- Dave Harris, Nottingham, UK [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top stelios xanthakis Guest Posted: Mon Sep 15, 2003 9:54 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote in message news:<memo.20030913142310.44767C (AT) brangdon (DOT) madasafish.com>... Quote: Daniel Spangenberg wanted a single function definition that could be called either as a static or as a virtual. A workaround is to have a virtual which calls a static. This means redefining the virtual in each derived class. With the "auto function" proposal it could look like: auto functions can do this. I keep discovering new possibilities too. But if the next step in C++ is going to include "auto functions", it should also include "virtual statics". static functions are functions that don't use/need 'this'. A virtual static is something like a good old C callback: it depends on the object's type but it does not use members. Makes sense... In the end, the request for "virtual static functions", seems to be a way to have "virtual variables": variables that are common to all the instances of a class and they belong in the virtual table. That's another things missing from c++. Quote: The compiler generates Derived::name() automatically, which picks up the local version of sname(). We may need some thought about how the template notion of "dependant names" applies here. I haven't thought about templates + auto functions. I'm not a template expert:) The procedure in lwc it's is like this: the "auto function" is completely reparsed in the scope of the derrived class --- as if it knew nothing about being an auto function and it was supplied by the programmer. Then the two versions of the function (derrived and parent) are compared to see if anything is different. will this work well with "dependant names"? BTW. another interesting case: class A { public: auto virtual void* most_derrived_object () { return (void*) this; } }; class B { ... }; class C : public B, public A { ... }; int main () { A *a = new C; delete a; // crash boom in g++! } Which can be used to call 'delete' when we have a pointer to a virtual base class or a base class not first in multiple inheritance. BTW, what does the standard say about this? Is it right to crash? If yes, auto functions can be a workaround. regards, stelios [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Falk Tannhäuser Guest Posted: Tue Sep 16, 2003 9:05 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? stelios xanthakis wrote: Quote: class A { public: auto virtual void* most_derrived_object () { return (void*) this; } }; class A { public: void* most_derived_object() { return dynamic_cast<void*>(this); } virtual ~A(); // needed to make dynamic_cast work }; should already do the job. However, I'm not quite sure what it could be good for... Quote: class B { ... }; class C : public B, public A { ... }; int main () { A *a = new C; delete a; // crash boom in g++! } Which can be used to call 'delete' when we have a pointer to a virtual base class or a base class not first in multiple inheritance. BTW, what does the standard say about this? Is it right to crash? This should work fine as long as class A has a virtual destructor. Quote: If yes, auto functions can be a workaround. I see a possibly useful application (if I understand the proposal well) to make the implementation of the 'virtual constructor' idiom easier. With today's C++, it looks like this: class A { public: A(A const&); virtual ~A(); A* clone() const { A* result = do_clone(); assert(typeid(*result) == typeid(*this)); // Be sure that overriding 'do_clone' has not been forgotten in any derived class return result; } private: A* do_clone() const { return new A(*this); } // making 'do_clone' purely virtual ( = 0) is not sufficient to force overriding everywhere }; class B : public A { A* do_clone() const { return new B(*this); } // must do this in all concrete derived classes! // note that 'do_clone' could also return 'B*' }; I'm not sure about the new syntax to adapt, neither if it would be worth the hassle... Falk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top llewelly Guest Posted: Wed Sep 17, 2003 10:11 am    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]mayall (AT) freemail (DOT) gr[/email] (stelios xanthakis) writes: [snip] Quote: BTW. another interesting case: class A { public: auto virtual void* most_derrived_object () { return (void*) this; } You are missing the famous virtual destructor. Quote: }; class B { ... }; class C : public B, public A { ... }; int main () { A *a = new C; delete a; // crash boom in g++! Add the virtual destructor and the crash goes away. Nothing to do with not being first. Quote: } Which can be used to call 'delete' when we have a pointer to a virtual base class or a base class not first in multiple inheritance. BTW, what does the standard say about this? Is it right to crash? [snip] The standard says the behavior is undefined. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Falk Tannhäuser Guest Posted: Wed Sep 17, 2003 7:55 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? Falk Tannhäuser wrote: Quote: class A { [...] private: A* do_clone() const { return new A(*this); } Of coure, here I meant virtual A* do_clone() const { return new A(*this); } Quote: // making 'do_clone' purely virtual ( = 0) is not sufficient to force overriding everywhere }; Falk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Mon Sep 22, 2003 10:20 pm    Post subject: Re: [RFC] Auto functions: an interesting feature? [email]mayall (AT) freemail (DOT) gr[/email] (stelios xanthakis) wrote (abridged): Quote: The procedure in lwc it's is like this: the "auto function" is completely reparsed in the scope of the derrived class --- as if it knew nothing about being an auto function and it was supplied by the programmer. That can fail, right? Suppose we had: struct Base { virtual auto int func( int x ) { return x + m_inc; } private: int m_inc; }; struct Derived: Base { }; Presumably the auto-generated Derived::func() is not allowed to access the private variable of Base? Quote: Will this work well with "dependant names"? With templates there's a distinction between names that depend on the template argument, and those that don't. Those that don't aren't looked up again. The aim is to prevent instantiations picking up function overloads accidentally, when the user may not have even realised the template used the function. That led to subtle bugs. I suspect something similar would be needed here (with the type of *this being the depended-upon type). Quote: BTW. another interesting case: class A { public: auto virtual void* most_derrived_object () { return (void*) this; } }; Which can be used to call 'delete' when we have a pointer to a virtual base class or a base class not first in multiple inheritance. Although we might naively hope deleting the void pointer would delete the object's memory, we couldn't expect it to call the object's destructors. It's just a void *. In fact, even the naive hope is wrong; formally it's undefined behaviour. Anyway, as other people have said, the functionality is already available through dynamic_cast<> and/or virtual destructors. So this isn't such an interesting case. -- Dave Harris, Nottingham, UK [ 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 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.