On 02/15/2012 10:13 PM, Roberto Fichera wrote:

Actually I cannot really answer because I haven't had yet a deeper look at the suggest "export" method details.

Neverthelss, what I need is an explicit string because certain format might require such information used to instantiate objects of the given class while deserializing in other languages (java or python for example). But also pure text formats optionally provide this information with the purpose of helping the user to understand/verify the content of the result of the serialization.

My library, which is written in pure C code for compatibility reasons, does solves easily the problem by stringify the given type via pretty straight macro inside the serialization function itself. Something like opening a type, serialize all the fields and close the type. The use of the macro obviously doesn't work at all when using it under any template declaration because the preprocessor is called earlier in compilation process.

I also tried the parsing of the __PRETTY__FUNCTION__ which works perfectly under template function, but this approach is even more un-portable then the demangler, so not really praticable.

By the way, I forgot to say that the demangling approach even if make easy to understand the real type behind a field, it will complicate a _lot_ the deserialization process when "regenerating" the given type into another language. Especially the type translation process into the given relative type, will not be really easy. As you know the type will be totally "unrolled" and all the nested typedef are solved till their relative basic type which in case of C++ with its templates, this process end up on generating very long demangled types. So, the best would be really to a have the type that the user can see in his code ... but I guess that it's not really easy to do without doing any changes. Finally, I would say that the boost serialization does handle really nicely all the C++ goodies, minimizing all the constraints into an acceptable solution, really a good job!

Sent from my ASUS Eee Pad

Larry Evans wrote:

...

On 02/15/12 12:38, Robert Ramey wrote:

...

Roberto Fichera wrote:

...

...

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. I agree totally with you! Actually my constraint is to use gnu toolchain, MSVC and pathscale compilers and eventually LLVM, but this one is not a priority at moment. But, any way still the problem of the demangling

On 02/15/2012 06:01 PM, Robert Ramey wrote: portability.

By the way, how did you solve the problem ... if you solved it, indeed ;-) ? It is already solved portably via the "export" functionality. Look it up in the documentation.

Robert Ramey Hi Robert,

Looking at:

http://www.boost.org/doc/libs/1_48_0/libs/serialization/doc/serialization.ht...

and reading:

The system "registers" each class in an archive the first time an object of that class it is serialized and assigns a sequential number to it. Next time an object of that class is serialized in that same archive, this number is written in the archive. So every class is identified uniquely within the archive. When the archive is read back in, each new sequence number is re-associated with the class being read. Note that this implies that "registration" has to occur during both save and load so that the class-integer table built on load is identical to the class-integer table built on save. In fact, the key to whole serialization system is that things are always saved and loaded in the same sequence. This includes "registration".

And paraphrasing part as:

So every class is identified by this uniquely assigned sequential number within the archive.

Then I'd infer that this "uniquely assigned sequential number" play a role similar to the role of the result of:

abi::__cxa_demangle( typeid( T ).name(), 0, 0, NULL );

in Roberto's post:

http://article.gmane.org/gmane.comp.lib.boost.user/72805

As you mention, Roberto's method is not portable between platforms (where, of course, a different compiler or even different version of the same compiler would be a different platform).

OTOH, as you also mention in the above quote, boost serialization requires:

things are always saved and loaded in the same sequence.

Roberto, would that be a problem for you?

-regards, Larry

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

---

Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users