Subject: Re: [boost] A possible date for dropping c++03 support
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2018-08-28 11:49:14
On Tue, Aug 28, 2018 at 7:37 AM Olaf van der Spek wrote:
> On Tue, Aug 28, 2018 at 1:32 PM, Glen Fernandes wrote:
> > On Tue, Aug 28, 2018 at 7:19 AM Olaf van der Spek wrote:
> >> Part of the problem is that there's no data / visibility on this.
> >> Who's using what compilers? When do they plan to move forward?
> >
> > Why is lack of data or visibility on this a problem for you?
>
> How would we know whether somebody is depending on something without data?
Who is the 'we' here? As a Boost user, why is that lack of data a
problem for you? What will you do different if you had that data?
> >> And what costs do others incur for (some of) Boost having to keep
> >> supporting this too?
> >>
> >> > What will change if we (Boost) make that announcement tomorrow? It's still
> >> up to the library maintainer.
> >>
> >> Is it?
> >> If one of your dependencies requires C++11...
> >
> > Sure. Let's say library Boost.Library today depended on Boost.Core for
> > boost::addressof and Boost.TypeTraits for boost::aligned_storage -
> > tomorrow and both Boost.Container and Boost.TypeTraits choose to break
> > C++03 compatibility: Tomorrow, if Boost.Library's maintainer is still
> > interested in supporting C++03 users, they will just provide the above
> > in boost::library::detail::addressof and
> > boost::library::detail::aligned_storage (either from the existing
> > implementations or their own).
> >
> > i.e. Even if we announce any such thing, it is still up to the
> > maintainer of Boost.Library to drop C++03 support. This might help
> > push them in that direction if they don't want the maintenance burden
> > sure, but it is no guarantee, especially if their users are more
> > important to them.
>
> Even if Boost.Config or .Test move to C++11?
> Would it be a free choice for the maintainers of those libs if they
> know a lot of libs depend on them?
Yes.
1. So many Boost libraries do not even use Boost.Test, and instead use
Boost.Core.Lightweight_Test for testing, so that one: I have no doubt
a library maintainer could migrate away it from if they have need to.
2. As for Config, it never needs to move away from any C++ version,
it's just macros for detection that will never impact the user of
library Boost.P or even how clean or maintainable library Boost.Ps
code looks
Glen