[Serialization] Serialization of function pointers

Hello everybody This is my first post to the list. Can I serialize C++ function pointer ? I search around and found that it could not be done ( although I am not sure ). If it can not be done, whats the explanation about it ? Thanks

AMDG elizabeta petreska wrote:
Hello everybody This is my first post to the list. Can I serialize C++ function pointer ?
Not that I know of.
I search around and found that it could not be done ( although I am not sure ). If it can not be done, whats the explanation about it ?
If you serialize a function pointer, when you deserialize it, it should point to the exact same function. This is very hard to guarantee. For instance, if you recompile the program, the address of a function can change. This would make any archives containing a function pointer unreadable. In Christ, Steven Watanabe

On Thu, Nov 12, 2009 at 2:55 AM, elizabeta petreska < elizabeta.petreska@gmail.com> wrote:
Hello everybody This is my first post to the list. Can I serialize C++ function pointer ? I search around and found that it could not be done ( although I am not sure ). If it can not be done, whats the explanation about it ? Thanks
The location of a function pointer in the address space could change depending on a number of factors: - The binary being recompiled - Any function pointers to functions in shared libraries could be invalidated - On some obscure platforms, this could still fail, even with the same binary that doesn't load any shared libraries So, it could possibly work, but I would highly recommend that you don't do this. Other options: - Wrap your functions in classes, and use the standard serialization methods for class objects. - Have a function in your binary that registers all of the function pointers (a std::map would suffice) that you care about at startup, perhaps indexed by a string. Then, serialize the names of the functions that you want to save. Can you describe your use case in more detail? Jeremy

It can be done. I've wanted to add a "case study" to the documentation but never have gotten around to it.
Basically here is the procedure.
a) Use a function object rather than a function pointer. This should be easy to do.
b) derive your function object from a common base class make your function
a virtual member of this class
c) make sure that the common base class has at least one virtual function.
This makes it a polymorphic base class.
d) include a variable which is a pointer to the common base class - that
is a polymorphic pointer.
e) Assign a new function object of the desired derived type to the polymorphic
pointer.
f) Save the polymorphic pointer as you would any other polymorphic pointer.
g) Some other time and/or place, load the polymorphic pointer as you would
any other polymorphic pointer.
h) You can now call your original function through the pointer to it's base class
Note that this method is ocmplete portable at the compile level. Also
note that the function object calls are portable accross plattorms. That
is a function object saved on a VC platform can be loaded on a gcc
platform. The key requirement is that the function object be implemented
in both the savnig and loading programs.
Robert Ramey
"elizabeta petreska"

On Thu, Nov 12, 2009 at 1:00 PM, Robert Ramey
It can be done. I've wanted to add a "case study" to the documentation but never have gotten around to it.
Basically here is the procedure.
a) Use a function object rather than a function pointer. This should be easy to do. b) derive your function object from a common base class make your function a virtual member of this class c) make sure that the common base class has at least one virtual function. This makes it a polymorphic base class. d) include a variable which is a pointer to the common base class - that is a polymorphic pointer. e) Assign a new function object of the desired derived type to the polymorphic pointer. f) Save the polymorphic pointer as you would any other polymorphic pointer. g) Some other time and/or place, load the polymorphic pointer as you would any other polymorphic pointer. h) You can now call your original function through the pointer to it's base class
Arguably, with this technique you're not serializing a function pointer. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Thu, Nov 12, 2009 at 4:55 AM, elizabeta petreska < elizabeta.petreska@gmail.com> wrote:
Hello everybody This is my first post to the list. Can I serialize C++ function pointer ? I search around and found that it could not be done ( although I am not sure ). If it can not be done, whats the explanation about it ? Thanks
If you think about it, I mean it makes perfect sense. Consider a more common example: Serializing a directed graph. Each node of course has pointers to the nodes it can reach. When you serialize this graph, do you actually serialize the *pointer*? Of course not, because every time you run the program it's at a different memory location. So when serializing data pointers, you have to resort to different techniques. For example, give each node a unique id, serialize each node, and then the ids of the nodes that can be reached. On deserialization, reconstruct the transitions from the ids. Ultimately you're going to have to do the same thing here: Serialize enough information that allows you to determine upon deserialization which function is actually being referred to. For example, if this is an exported function, you could serialize the name of the module from which it's exported as well as the name of the function. Then you could reconstruct this at runtime by using dlopen/dlsym (linux) or LoadLibrary/GetProcAddress (windows). If it is not a function exported from any library, but an arbitrary private function that may point anywhere in your code base (or for that matter in the code segment of some other module that also happens to be loaded in your process), then you need to figure out a way to serialize enough information that you can reconstruct it at runtime and it's going to be complicated, although if it were really important I can think of a few areas to begin looking into.
participants (6)
-
elizabeta petreska
-
Emil Dotchevski
-
Jeremy Pack
-
Robert Ramey
-
Steven Watanabe
-
Zachary Turner