Boost logo

Boost :

Subject: Re: [boost] [Boost.DLL] Formal Review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-10-03 10:54:24

On 3 Oct 2014 at 14:28, Antony Polukhin wrote:

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

Both Itanium and MSVC mangling schemes happily have consistent
template parameter mangling, so if you wrap the thing you want to
mangle like the above and have template<class C> magic_mangle(C &&f)
call __func__ or its equivalent to fetch the mangled name of the
templated function, extracting the mangled template parameter is a
simple string chop. You chop off a fixed length beginning and end,
and prepend a little bit of mangling depending on its type of
function if it's a function and you should be done.

If you remember Antony I sent you a little demo of this back during
the review of TypeIndex.

> That's why aliases were considered a lesser evil:
> BOOST_DLL_ALIAS(boost::foo, foo_variant) // in plugin
> "foo_variant" // in plugin importer

The neato thing about such mangling generation support is that one
can examine, in a natural way, a series of DLLs for the presence of
some C++ API. You simply supply the prototype and name of what you
want, and it finds it.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at