Boost logo

Boost Users :

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


On 02/15/2012 06:01 PM, Robert Ramey wrote:
> 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.

Yes! Indeed!

> 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 !

Thanks for the suggestion, I'll have a look.

>> 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?
Yes! Actually the whole process maps the C++ object's hierarchy (in terms of serialization)
into the corresponding matlab's lowlevel types which are represented by an opaque
mxArray. The whole process is driven by using the lowlevel matlab sdk primitives. Finally,
the process is even more optimized since the matlab's object is being created once, and then
updated only.
> That might be interesting for someone.
I can imagine ;-) .

>
>> 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.

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 ;-) ?

>
> Robert Ramey
>
>
>
> _______________________________________________
> 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