|
Boost : |
Subject: Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-14 19:11:58
On 14 May 2014 at 7:24, Charousset, Dominik wrote:
> All this really is only aiming at having at type_info that is actually
> useful, i.e., name() returns *the exact same string* on each platform
> and it provides you with an interface for (1) generating values, (2)
> serializing and deserializing values, and (3) compare values. When
> generating a value through an uniform_type_info, you'll get a
> uniform_value, which is bascially a wrapper keeping {uniform_type_info*,
> void*}.
Implementing this correctly would be quite a bit of work which is why
it was left out of TypeIndex, but very valuable I think. You need to
write a mangled symbol to partial AST parser for MSVC and GCC and
then you can compare the ASTs for equivalence.
Here is one based on Boost.Spirit which parses MSVC mangling:
https://github.com/ned14/NiallsCPP11Utilities/blob/master/SymbolMangle
rMSVC.cpp. It is fundamentally broken however because unlike the
Itanium mangling, the MSVC mangling is context sensitive i.e. its
grammar is non-trivial, so a working design would need at least a two
pass parser, not the single pass design here.
Someone may suggest you simply lift the mangled symbol to pretty name
code from clang as there should be both MSVC and Itanium ABI
implementations in there, and the pretty names might have similar
whitespacing etc. That might work, though be aware that I did not
find a fully correct and working MSVC demangler (usually called
__unDName) in any open source code when I last looked two years ago.
The MSVC demangling process needs a full two pass parser, anything
less won't cut it for really complex nested template template types.
The implementation for mingw or ReactOS simply does (did) not work.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk