4 ms·

Pretty neat! Would like to see if/how to handle field offsets/getters/setters that avoids loading/storing the whole encapsulated object. (Is that something the

Pretty neat! Would like to see if/how to handle field offsets/getters/setters that avoids loading/storing the whole encapsulated object. (Is that something the C++ templates can do without special annotations?) E.g. struct coord_t { float x; float y; }; remote_ptr<coord_t> p = getRemoteCoord(); p->x = 42.f; // as described by OP, only modifies local copy?

xiii1408 8y ago
Almost! This is something I've looked into, and hopefully I'll have time to write a whole blog post about it in the future. There are some fundamental syntax limitations due to the way that operator-> works (and that operator. does not exist). The best thing I have is a `pointerto()` macro that gets you a remote pointer to a member of a remotely stored object. This uses C++'s `offsetof` macro and a whole bunch of template voodoo to make the types work. struct coord_t { float x; float y; }; remote_ptr<coord_t> p = getRemoteCoord(); remote_ptr<float> p_x = pointerto(x, p); float x = rget(p_x); rput(p_x, x+1); You can make operator-> work as well, for both methods and members, but unfortunately right now it has to involve pulling the whole object, storing it inside a proxy object, accessing the member of the local object, and then storing it back in remote memory in the proxy object's destructor. It's a cool piece of code (I'm open-sourcing this library as soon as I have a free weekend to clean it up and document it). I hope that metaclasses or reflection in a future version of C++ will allow the syntax you wrote above, but right now this is the only way I've come up with.
kowa_ger 8y ago
While there is a possible solution for this (as the author describes in the previous comment), this is something you should not really consider a useful pattern in your application. Prefer a struct of arrays instead. This makes the code way cleaner results in better cache utilization.
- mwkaufma 8y ago
  Cache utilization... of a remote system access? What cache? This isn't RAM, Dogg.

xiii1408 8y ago

Almost! This is something I've looked into, and hopefully I'll have time to write a whole blog post about it in the future. There are some fundamental syntax limitations due to the way that operator-> works (and that operator. does not exist). The best thing I have is a `pointerto()` macro that gets you a remote pointer to a member of a remotely stored object. This uses C++'s `offsetof` macro and a whole bunch of template voodoo to make the types work. struct coord_t { float x; float y; }; remote_ptr<coord_t> p = getRemoteCoord(); remote_ptr<float> p_x = pointerto(x, p); float x = rget(p_x); rput(p_x, x+1); You can make operator-> work as well, for both methods and members, but unfortunately right now it has to involve pulling the whole object, storing it inside a proxy object, accessing the member of the local object, and then storing it back in remote memory in the proxy object's destructor. It's a cool piece of code (I'm open-sourcing this library as soon as I have a free weekend to clean it up and document it). I hope that metaclasses or reflection in a future version of C++ will allow the syntax you wrote above, but right now this is the only way I've come up with.

kowa_ger 8y ago

While there is a possible solution for this (as the author describes in the previous comment), this is something you should not really consider a useful pattern in your application. Prefer a struct of arrays instead. This makes the code way cleaner results in better cache utilization.

mwkaufma 8y ago
Cache utilization... of a remote system access? What cache? This isn't RAM, Dogg.