1[/ 2 Copyright 2014 Renato Tegon Forti, Antony Polukhin 3 Copyright 2015-2019 Antony Polukhin 4 Distributed under the Boost Software License, Version 1.0. 5 (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) 6/] 7 8[section Design Rationale] 9 10[section ABI portability across compilers] 11 12During discussion of the library a lot of questions were about ABI stability and should the library 13take care about it. It was decided that making ABI stable could be a useful feature, but it will 14add a lot of overhead and make the library usage less simple. For those who do not require ABI 15stability across compilers such feature will be an overkill. 16 17It was decided to make this library more simple and low level, so that it could be used to make ABI 18stable plugins system for users that require it still not adding overhead for other users. 19 20[endsect] 21 22 23[section User's plugin API] 24 25There are some open C++ plugin systems. Most of them force user to have some predefined API. The 26problem is that all of those API differ. 27 28To be more usable Boost.DLL does not force API. It's up to user to design suitable API. 29 30[endsect] 31 32[section Performance and memory allocations] 33 34Some methods of the library use `boost::filesystem::path` or return `std::vector<std::string>`. This 35may look non optimal at first, but there is a reason to do so. 36 37`boost::filesystem::path` allows to transparently use Unicode strings with non-Unicode ones. Using it 38provides a more user-friendly interface for the library while the performance overhead is not noticeable 39because of a slow file system operations that occur in `boost::filesystem::path` accepting methods. 40 41`std::vector<std::string>` variables are returned by the `library_info` methods. Querying a library is a slow 42procedure anyway: it randomly reads parts of file from disc and executes algorithms that sometimes 43have linear complexity from sections or exported symbols count. Returning `std::vector<std::string>` 44simplifies implementation and does not require from user to keep an instance of `library_info` after 45query. Having not a very noticeable performance overhead in rarely called methods seems reasonable. 46 47Other methods are assumed to be hot paths and optimized as much as possible. 48 49[endsect] 50 51[section Self loading] 52 53There is a good big reason to make self loading via `shared_library(program_location())` instead of 54having some `shared_library::load_self()` member method. That reason is the requirement to have an ability to call 55`shared_library(this_line_location())` from any place, even from the main binary. We need that to link plugins 56into the binary and to create a transparent reference counting mechanism. 57 58Making multiple interfaces that do exactly the same things looks unreasonable to me, that's why 59`shared_library(program_location())` and `shared_library(this_line_location())` are used without 60`shared_library::load_self()`. 61 62[endsect] 63 64[section Aliases vs Mangling] 65 66Mangling depends on source code, for example `"boost::foo"` could be `foo` function or `foo` variable. 67Depending on that knowledge it must be mangled in different ways. More problems arise if `foo` is an 68overloaded function that accepts parameters: `"boost::foo(variant<int, short>)"`. In that case full 69name of parameter must be specified, which could be `boost::variant<int, short>` or `variant<int, short, void_, void_>` 70... 71 72There was an idea to allow user to forward declare function and generate mangled name from it: 73 74``` 75namespace boost { void foo(variant<int, short>); } 76 77std::string mangled_name = boost::dll::magic_mangle(boost::foo); 78``` 79 80But that idea has epic failed because of linker problems and no reliable way to get mangled symbol name 81from compiler internals at compile time. 82 83That's why aliases were considered a lesser evil: 84 85``` 86BOOST_DLL_ALIAS(boost::foo, foo_variant) // in plugin 87"foo_variant" // in plugin importer 88``` 89 90[endsect] 91 92 93[endsect] 94 95