-----Original Message----- From: Glen Fernandes Sent: Tuesday, August 28, 2018 1:25 AM To: mike.dev@gmx.de Subject: Re: [boost] A possible date for dropping c++03 support

On Mon, Aug 27, 2018 at 1:10 PM Mike Dev wrote:

...

Conditionally using a c++11/14/17 feature is (usually) not the problem although there are sometimes pitfalls as Peter mentioned. However, it also has limited utility. E.g. it doesn't make sense to simplify a function implementation using c++11 features like auto, range based for, decltype, constexpr instead of TMP, if you have to maintain the c++03 code path as well. In principle, you could conditionally get rid of some boost dependencies in c++11 mode, but again at the cost of maintaining two different code paths (as boost types often have slightly different semantics from c++11). So why do it? And you still can't deprecate the dependency itself because it is still needed in c++03 mode.

Why do it? I do it when it provides some benefit to the users:

e.g. If alternative implementation using C++14 constexpr results in faster compilation for users. If supporting C++11 move semantics results in better performance for the users. If supporting C++11 variadic templates results in a more flexible interface for the users.

i.e. If I'm the maintainer, and I'm happy to have that burden of maintenance, why does anyone else care that I support C++03/C++11/C++14 users, in addition to C++17 users?

Yes, these are the high value proposition cases, that you mention.

There's also no dependency to the user is there?. e.g. If a library obtain std::addressof from <memory> in C++11 mode and doesn't source it from Boost.Core, to the user, the library doesn't depend on Boost.Core.

...

So except for cases with a very high value proposition (move semantics, simplified api, c++11 only functionality) or simple annotations (noexcept, override) using c++11 features *conditionally* is usually not all that beneficial. My hope here is that at some point, those boost libraries will finally start to use c++11 features *unconditionally* in order to simplify things - not add even more complexity in the form of conditional compilation.

Simplify things for which party? Are you worried about users or Boost library authors/maintainers? I don't see how users are inconvenienced unless the user wants some feature only available in later C++ modes that the library maintainer refuses to implement.

Glen

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. 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, sometimes code size and tools (code highlighting, static analysis, refactoring etc.) that either get slower or totally break e.g. because they don't have a perfect emulation of the compilation environment and don't know which code paths are the currently active ones or are just not able to understand all the TMP. 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. Btw.: In case this was not clear: I'm not a boost contributor myself and for some time now, we (as in our company) are actively trying to avoid boost dependencies for various reasons that have more to do with boost-internal stuff and the boost eco system than with e.g. inconvenient interfaces. So yes, at least some end-users do really care about the internals of boost. But admittedly, I mostly work on (semi-) embedded projects where we have to compile (and on rare occasion even modify) boost ourselves - not sure how common that is. Best Mike