-----Original Message----- From: Glen Fernandes
Sent: Tuesday, August 28, 2018 7:11 PM On Mon, Aug 27, 2018 at 11:56 PM Mike Dev wrote:
There are (at least) three problems:
1) Not all dependencies are private. If a library e.g. uses boost::function in its interface (in particular if it returns one) the user is also directly affected by changes to that dependency.
If the user isn't using the interfaces of library Boost.X which use boost::function, but instead using the interfaces of library Boost.X that accept std::function, when boost::function changes, yes, library Boost.X is affected, but in what way is this painful for you as a user?
I was talking about interfaces that only use boost::function instead of std::function. If you are saying, you use the preprocessor to generate only one or the other version of an interface depending on the c++ language version, then this is indeed no real problem for the user, assuming both versions are tested and all parts of the final program are compiled with the same c++ version (which - especially on linux - may or may not be true). Dependency analysis/management tools will probably still think I have a dependency on boost::function though.
2) As you know, the c++ compilation model is incredibly leaky, meaning transitive dependencies are not hidden from the user. E.g. if you are using boost core in your header and I include it, I do get all the symbols (including macros) in my TU too. Boost has (usually) very good hygiene, so the main problems here are usually compilation times, [...]
In my example for this, if library Boost.Y only conditionally includes Boost.Core for boost::addressof, (e.g. only if BOOST_NO_CXX11_ADDRESSOF is defined) you won't get anything from Boost.Core, because for you, there will be no #include of anything from Boost.Core. For you, library Boost.Y would only be including <memory>.
Same answer as above: you are right, if Boost.Y really completely eliminates all direct and indirect dependencies on Boost.Core in c++11 then at least compile times should not be effected. However, I can tell you that this currently not the common case in boost. I checked it some time ago for boost::array and there were at least a dozen (probably dozens - I stopped at some point) libraries that directly or indirectly included boost.array unconditionally. And a quick check shows that boost function is also unconditionally included in at least a few libraries. Unfortunately, boostdep is afaik not preprocessor aware - that would make those kinds of analysis much easier.
3) Not every library in boost is as well maintained as yours and I as a user prefer "cleaner / simpler" libraries because they a) tend to have fewer bugs, b) I can more easily modify things myself if necessary, c) the easier the life of the maintainer, the more likely he has time to add new functionalities. Finally, if boost can deprecate and at some point even remove some libraries, then their maintainers (in particular the CMT) can focus their time on different projects.
Here's what I was trying to understand with my original question: What will change if we (Boost) make that announcement tomorrow? It's still up to the library maintainer. If Boost.Z maintainer still wants to support C++03 because of users that they care about, they will still reject your desire for it to use C++11 features unconditionally even if it makes the implementation internals of Boost.Z easier to read.
Absolutely, it still depends on the individual library maintainer. However, if boost would indeed make such announcement that alone would be an indicator that at least some maintainers want to make that change, but probably didn't dare to do it alone. If there is no interest from the side of the c++03 library maintainers, then this announcement will never happen. The big question is, what happens if most, but not all maintainers are for it and then actually migrate to c++11. Would the remaining libraries internalize all their former dependencies to stay c++03 compatible? Best Mike