Re: [boost] [Boost.DLL] Formal Review request

Subject: Re: [boost] [Boost.DLL] Formal Review request
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-10-03 06:28:17

2014-10-03 13:44 GMT+04:00 Mathias Gaunard <mathias.gaunard_at_[hidden]>:

> On 02/10/14 14:45, Antony Polukhin wrote:
>
>  Yes, you can. Though C++ name will be mangled and some `void
>> boost::foo(std::sting)` will change to something like `N5boostN3foosE`.
>> Importing function by `N5boostN3foosE` name does not looks user friendly,
>> especially assuming the fact that different compilers have different
>> mangling scheme.
>>
>> The alias name - is a not mangled name for C++ symbol.
>>
>
> Your library could simply be extended to support automatic
> mangling/demangling for whatever platform you're running it on.
> All compilers provide functions for demangling (__cxa_demangle,
> UnDecorateSymbolName/__unDName), however I'm not aware of functions being
> provided for mangling.
>

I've tried to do so, but mangling is a very big unsolvable (on a library
level) problem. Mangling depends on source code, for example "boost::foo"
could be foo function or foo variable. Depending on that knowledge it must
be mangled in different ways. More problems arise if foo is an overloaded
function that accepts parameters: "boost::foo(variant<int, short>)". In
that case full name of parameter must be specified, which could be
boost::variant<int, short> or variant<int, short, void_, void_> ...

There was an idea to allow user to forward declare function and generate
mangled name from it:

namespace boost { void foo(variant<int, short>); }

boost::dll::magic_mangle(boost::foo);

But that idea has epic failed... Because of linker problems and no reliable
way to get mangled symbol name from compiler internals at compile time. At
least I have not found one (any ideas are welcomed).

That's why aliases were considered a lesser evil:

BOOST_DLL_ALIAS(boost::foo, foo_variant) // in plugin
"foo_variant" // in plugin importer

P.S.: I'll add this question to design rationale

-- 
Best regards,
Antony Polukhin