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

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

On 3 Oct 2014 at 19:09, Andrey Semashev 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.

Who cares. All the major compilers do provide this, and a large 
number of the minor ones. When myself and Antony surveyed the 
situation during TypeIndex we were pleasantly surprised at just how 
widespread support is for some magic macro which expands to the 
mangled form of the enclosing function. Mangling schemes have also 
basically reduced to just two kinds in recent compilers, with the 
Microsoft mangling scheme considerably the harder to parse. Mangling 
schemes are also very stable over time. That makes this proposal 
tractable.

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

Depends on the use case. Any Boost.DLL should be capable on 
inspecting arbitrary shared libraries, not necessarily ones exporting 
a Boost.DLL built interface.

You're right if you want MSVC to inspect a Mingw DLL things get 
tricky.

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

On this part I do agree - a generalised partial AST library for 
constructing and destructing arbitrary mangled symbols would be 
super. However, it is not a trivial amount of work, some months of 
someone's time would probably be needed (I suggest replicating 
clang's internal C++ AST API, might as well not reinvent the wheel). 

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/