Roberto Fichera wrote:
On 02/13/2012 05:13 PM, Robert Ramey wrote:
Roberto Fichera wrote:
Hi All in the list,
I'm basically new to boost so I hope to find support here to integrate my own serialization library within the boost archive logic.
Just to say that I've solved all my problems. My own boost archive it's finally able to serialize everything that is defined in terms of boost serialization into my serialization infrastructure which finally maps everything into our supported formats.
Congratulations! I'm aware that doing a complete/correct job on such a task is trickier than it first appears. I would suggest that you run the test suite on your new archive. To see how to do this, look at the way the boost serialization archives (text binary, xml, etc) are tested. Plug in your own archive and you can run 50 different tests on your archives without writing even one line of code !
I had to do so because I need keep compatibility across different supported languages, framework and architecture using formats like matlab native mxArray or python native pyobject. Especially matlab was really important because now I can "materialize" boost object in the matlab workspace very easily.
hmmm - a archive implementation which serializes to/from matlab? That might be interesting for someone.
So far so good! Since I need to get dynamically the type name as string, I have actually implemented the "stringify" of the type name via the code below:
template< typename T > inline const char* type_name() { return (char*) #if defined(__GNUC__) && defined(__cplusplus) abi::__cxa_demangle( typeid( T ).name(), 0, 0, NULL ); #else typeid( T ).name(); #endif }
which of course uses the specific g++ demangler that follow a non standard way (I'd to follow a similar approach for the MSVC). So, my question is does the boost library provide a standard way to get the type name as string?
Doing something like this was considered from the very beginning but was explicitly rejected for a number of reasons. Here are main points. a) We need to relate a type to an external string in order to implement "export" functionality where by a polymorphic pointer is saved/loaded to the correct true type. b) I considered an approach to the above, but it would result in in non portable code and give me a task of trying to re-implement this for each different compiler/version. That is, it would create a secure job for me for the rest of my natural life. This would have been OK if the job were paid. But since it isn't this was unattractive. c) Even worse, the aproach above would make even text archives non-portable between platforms. Of course this is a non-starter. So you might want to re-think your approach above. Robert Ramey