Subject: [boost] A possible date for dropping c++03 support
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-08-28 03:55:53
> -----Original Message-----
> From: Glen Fernandes <glen.fernandes_at_[hidden]>
> Sent: Tuesday, August 28, 2018 1:25 AM
> To: mike.dev_at_[hidden]
> Subject: Re: [boost] A possible date for dropping c++03 support
>
> On Mon, Aug 27, 2018 at 1:10 PM Mike Dev <mike.dev_at_[hidden]> 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