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/