Boost logo

Boost Users :

Subject: Re: [Boost-users] Developing a new boost archive
From: Roberto Fichera (kernel_at_[hidden])
Date: 2012-02-15 16:13:52


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.

Sent from my ASUS Eee Pad

Larry Evans <cppljevans_at_[hidden]> wrote:

>On 02/15/12 12:38, Robert Ramey wrote:
>> Roberto Fichera wrote:
>>> On 02/15/2012 06:01 PM, Robert Ramey 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
>>> 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.html#derivedpointers
>
>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_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/boost-users


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net