Boost logo

Boost :

Subject: Re: [boost] A possible date for dropping c++03 support
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2018-08-28 11:11:03


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?

> 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>.

> 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.

(Which CMT maintainers are struggling today, because the library they
are maintaining has C++03 support? The CMT is voluntary, and they
should be encouraged to focus their time on projects they want to work
on in Boost, and let users who care about the unsupported libraries to
step up and volunteer to maintain them.)

Glen


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk