On Saturday 04 October 2014 12:24:23 Niall Douglas wrote:
On 4 Oct 2014 at 12:41, Andrey Semashev wrote:
We had a similar discussion already. IMO, the library in its core should not rely on compiler specific features and should be implementable in pure C++ and standard APIs. This ensures its portability. It doesn't matter how many compilers implement the extension because there will always be the one that doesn't.
Andrey, please list here three C++ compilers which had at least one version release in the past five years which doesn't provide a magic macro expanding out to the mangling of the enclosing function.
I don't have such a survey, but I suspect you can't guarantee that every compiler out there supports it either.
In any case, I don't think that mangled names are useful for other reasons I mentioned.
With such support, the following:
plugin = dll::import_variable_alias
( lib_path / "my_plugin_sum", "plugin", dll::load_mode::append_decorations ); can become:
BOOST_DLL_IMPORT( lib_path / "my_plugin_sum", BOOST_DLL_AUTO_ALIAS(my_namespace::plugin), // import a variable BOOST_DLL_AUTO_ALIAS(my_namespace::function), // import a function BOOST_DLL_AUTO_ALIAS(my_namespace::object), // import a class implementation ... )
I'm not sure how is that an improvement. Maybe I just missed the point of your example.
For those very few compilers without sufficient support, I am sure a BOOST_DLL_EXPLICIT_ALIAS macro could let you manually specify the mangling for some imported symbol. This would be useful in any case for MSVC to inspect Mingw binaries or vice versa.
I don't mind if the library offers an optional functionality to obtain a mangled name of a symbol. But it should be exactly that - an optional feature, which is only supported on select compilers and works on certain platforms. In its core the library should still provide a platform-neutral user interface.