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