Hi, is there interest in a boost utility to implement (pseudo-) virtual function templates? real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: struct base : enable_vtemplate<derived1,derived2>{ template<class OutputIterator> void f(OutputIterator it){ BOOST_VTEMPLATE(f,(OutputIterator),(it)); it << "not overridden\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived1 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived1\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived2 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived2\n"; } BOOST_SUPPORT_VTEMPLATE(); }; the runtime overhead besides the virtual call is one switch().
On 20.02.2010 14:09, strasser@uni-bremen.de wrote:
Hi,
is there interest in a boost utility to implement (pseudo-) virtual function templates?
real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times:
struct base : enable_vtemplate<derived1,derived2>{ template<class OutputIterator> void f(OutputIterator it){ BOOST_VTEMPLATE(f,(OutputIterator),(it)); it << "not overridden\n"; } BOOST_SUPPORT_VTEMPLATE(); };
struct derived1 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived1\n"; } BOOST_SUPPORT_VTEMPLATE(); };
struct derived2 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived2\n"; } BOOST_SUPPORT_VTEMPLATE(); };
the runtime overhead besides the virtual call is one switch().
Interesting. I had a need in such a thing a couple of times. Is the code available somewhere?
strasser@uni-bremen.de wrote:
Hi,
is there interest in a boost utility to implement (pseudo-) virtual function templates?
real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: I'm a bit amiss on how is this different from Polymorphic Function Obejct, aka Callable Entity with template operator() ?
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Zitat von joel falcou <joel.falcou@lri.fr>:
real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: I'm a bit amiss on how is this different from Polymorphic Function Obejct, aka Callable Entity with template operator() ?
I've never used Fusion.Functional but at first sight I can't even figure out what they have in common. the code I tried to emulate, if C++ had runtime generics, is the following: struct base{ template<class OutputIterator> virtual void f(OutputIterator); }; struct derived : base{ template<class OutputIterator> virtual void f(OutputIterator); }; base *b=new derived; b->f(...); //calls derived::f how do you do something like that with Polymorphic Function Objects? Zitat von Andrey Semashev <andrey.semashev@gmail.com>:
Interesting. I had a need in such a thing a couple of times. Is the code available somewhere?
I have no generic implementation. what it could look like(pseudo-code): template<class T1,...> class enable_vtemplate{ protected: typedef mpl::vector<T1,...> vtemplate_types; virtual std::size_t vtemplate_index() = 0; }; #define BOOST_SUPPORT_VTEMPLATE(T) \ virtual std::size_t vtemplate_index(){ //return index of T in vector vtemplate_types } #define BOOST_VTEMPALTE(F,TARGS,ARGS) \ switch(this->vtemplate_index()){ case 0: return static_cast<T1 *>(this)->template F<TARGS>(ARGS); ... }
strasser@uni-bremen.de wrote:
Zitat von joel falcou <joel.falcou@lri.fr>:
real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: I'm a bit amiss on how is this different from Polymorphic Function Obejct, aka Callable Entity with template operator() ?
I've never used Fusion.Functional but at first sight I can't even figure out what they have in common.
Oh I missed the virtual part. Sorry then :o -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
strasser@uni-bremen.de wrote:
real virtual function templates are obviously not possible without a JIT-compiler
Wrong, you would just need to do link-time template instantiation, which is actually required by the C++ standard (but few implement it, and none had the idea to use it to implement virtual template functions as an extension).
but if all derived types are known to the base type,
Then you might as well use Boost.Variant.
the runtime overhead besides the virtual call is one switch().
It should be possible to be just a switch and no virtual call.
Zitat von Mathias Gaunard <mathias.gaunard@ens-lyon.org>:
real virtual function templates are obviously not possible without a JIT-compiler
Wrong, you would just need to do link-time template instantiation, which is actually required by the C++ standard (but few implement it, and none had the idea to use it to implement virtual template functions as an extension).
right, probably because it wouldn't work across DLLs.
but if all derived types are known to the base type,
Then you might as well use Boost.Variant.
it is similar from an implementation viewpoint, but the interface is vastly different. take e.g. a base class with a number of virtual functions struct A{ virtual void f(); virtual void g(); }; and then you'd want to add a template parameter to one of them. this would require you to refactor every use of class A to use Boost.Variant visitors. not an option imho.
the runtime overhead besides the virtual call is one switch().
It should be possible to be just a switch and no virtual call.
if you store the index of the most derived class in the base class, yes. but construction is more difficult that way, and my example also requires that every vtemplate is overwritten in a derived class. if you extend this so that functions can be optionally overwritten (like any regular virtual function) you'd have to store an index for each vtemplate function.
On Sat, Feb 20, 2010 at 6:09 AM, <strasser@uni-bremen.de> wrote:
Hi,
is there interest in a boost utility to implement (pseudo-) virtual function templates?
I've been looking for a way to implement virtual-functions for cases where the objects in question are stored within shared memory region, thus presenting the challenge that the overridden function addresses might be different for different processes. Would that be accommodated by your approach, or are you in fact storing pointers to functions on the base type?
Bob Walters a écrit :
On Sat, Feb 20, 2010 at 6:09 AM, <strasser@uni-bremen.de> wrote:
Hi,
is there interest in a boost utility to implement (pseudo-) virtual function templates?
I've been looking for a way to implement virtual-functions for cases where the objects in question are stored within shared memory region, thus presenting the challenge that the overridden function addresses might be different for different processes.
Typically, the function addresses lie within the vtable, not the object (the object has a pointer to the vtable). The vtable is in static memory, and contains function pointers as well as other things.
Would that be accommodated by your approach, or are you in fact storing pointers to functions on the base type?
While you would avoid the need to have the vtable at the same address, ultimately this doesn't appear to be sufficient to solve the problem: you would still need the function to be at the same address in memory.
Hi, ----- Original Message ----- From: "Mathias Gaunard" <mathias.gaunard@ens-lyon.org> To: <boost@lists.boost.org> Sent: Wednesday, February 24, 2010 1:32 AM Subject: Re: [boost] virtual function templates Bob Walters a écrit :
On Sat, Feb 20, 2010 at 6:09 AM, <strasser@uni-bremen.de> wrote:
Hi,
is there interest in a boost utility to implement (pseudo-) virtual function templates?
I've been looking for a way to implement virtual-functions for cases where the objects in question are stored within shared memory region, thus presenting the challenge that the overridden function addresses might be different for different processes.
Typically, the function addresses lie within the vtable, not the object (the object has a pointer to the vtable). The vtable is in static memory, and contains function pointers as well as other things.
Would that be accommodated by your approach, or are you in fact storing pointers to functions on the base type?
While you would avoid the need to have the vtable at the same address, ultimately this doesn't appear to be sufficient to solve the problem: you would still need the function to be at the same address in memory. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Bob, have you tried to separate the behavior and the shared data? The class specifying the behaviour will be a typical C++ class, having the possibility to have virtual functions and more, containing a handle to the shared data, that could contain all the non virtual functions. In this way you get the best of shared memory and process memory. Maybe a generic proxy framework could be designed to maintain the association between proxy and shared data. This could be done in two ways: * eager synchronization - at start-up the process creates all the proxies of the concerned shared memory and then is synchronized with the creation /destruction of shared memory objects, or * lazy synchronization - the proxies are created the first time they are needed. This framework could be used either for shared memory or for persistent objects. There are surely a lot of drawbacks to this approach, as the design is much more complex, synchronization could be lost, ...but maybe it is woth exploring it a little bit. Best, Vicente
participants (6)
-
Andrey Semashev -
Bob Walters -
joel falcou -
Mathias Gaunard -
strasser＠uni-bremen.de -
vicente.botet