Boost logo

Boost :

Subject: Re: [boost] [Boost.DLL] Formal Review request
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-10-03 11:09:41


On Friday 03 October 2014 15:54:24 Niall Douglas wrote:
> On 3 Oct 2014 at 14:28, Antony Polukhin wrote:
>
> 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.

I think any such technique is non-portable since there is no portable way to
obtain mangled name of a function in compile time.

It works in TypeIndex because of its specifics, which I believe don't apply to
Boost.DLL. It is unspecified what string identifies a type and you generally
don't care about its format. This allows to use demangled function names or
whatever __func__ returns in TypeIndex.

This is not the case in a library ABI, which you define by Boost.DLL macros.
You should be able to precisely tell the symbol names you export, and these
names should be compatible with whatever restrictions the target system
requires. I.e. the standard __func__ will likely not work.

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

We should not forget about binding symbols in other languages.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk