On 7 Oct 2014 at 16:58, Antony Polukhin wrote:
<...> Prints:
18$$magic$$_fprinterILZN21$$magic$$_adl_barrier18export_me_functionE7v ariantIis5void_S2_S2_ES3_EE 18$$magic$$_vprinterILZN21$$magic$$_adl_barrier18export_me_variableEEE
Exported:
__ZN3foo11adl_barrier18export_me_functionE7variantIis5void_S2_S2_ES3_ __ZN3foo11adl_barrier18export_me_variableE
... which looks bang on. Simply replace the 8fprinter with 3foo and remove the $$magic$$_.
Still looks like something error-prone.
Not for the Itanium ABI which is very well understood and publicly documented. You can write a simple [1] Itanium type mangler using pure C++ metaprogramming, it's trivial in fact. The MSVC ABI is considerably harder. This is why I am advocating getting the compiler to do the mangling for you, then you transform its result according to some simple heuristics. [1]: By simple I mean only types with no repetition compression.
Actually, user could always get the list of mangled symbols using the boost::dll::library_info class methods on a compiled binary. So instead of using mangling voodoo macro and explicitly declaring exports in import module, user can find all the export_me_* mangled names and import them using any of the interfaces. Something close can be found in this example: http://apolukhin.github.io/Boost.DLL/boost_dll/tutorial.html#boost_dll.tutor...
Oh sure. But I think what we'd all love is for some long overdue type safety when binding symbols at runtime in C++. Otherwise out of step binaries make segfaults, security holes and buffer overruns instead of link failures.
... some dream of a nicest solution: Add attribute [[abi_name "new_abi_name"]], remove all the *_alias methods and member function, remove _ALIAS macro. Now user is free to do following things:
// in plugin: namespace foo { namespace adl_barrier {
[[abi_name "export_me_function_1"]] BOOST_SYMBOL_EXPORT boost::variant
export_me_function( boost::variant , boost::variant ) { return 0; } [[abi_name "export_me_variable_1"]] BOOST_SYMBOL_EXPORT boost::variant
export_me_variable; } // namespace adl_barrier } // in importer: dll::shared_library lib(lib_path); typedef boost::variant
vis_t; auto f = lib.get ("export_me_function_1"); auto v = lib.get ("export_me_variable_1"); Code from above looks nice, but requires abi_name attribute that was not even proposed to C++ standardization and until now existed only in my head.
Personally speaking, if a proper Componentisation ABI is considered still too hard for us, I'd simply standardise on the Itanium ABI. Your DLL library could provide a portable method for auto generating aliases with the Itanium ABI. As I mentioned, it is fairly trivial to write some metaprogramming which will output an Itanium mangling for some input type. You just then need to regex in the fully qualified name of the item, and finally run a pass collapsing repetition (a regex matcher will suffiice). Itanium is very logical, no surprises. I keep a quick cheat sheet document on symbol mangling at https://github.com/ned14/NiallsCPP11Utilities/blob/master/demanglers/c alling_conventions.pdf, you may find it useful. The official http://mentorembedded.github.io/cxx-abi/abi.html#mangling isn't bad either. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/