[gil] Phasing out support C++11 and switching to C++17

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
Hi,

We're discussing [1] to start switching GIL to C++17
in the near future and, following Peter Dimov's policy
on phasing out C++XY support [2], we'd like to:

1. Declare C++11 support deprecated in 1.75 (December 2020)
2. Drop C++11 support in 1.77 (?)  (August 2021)

Could anyone help us validate and confirm that
it's a good plan or are we overlooking any policies
from Boost's release perspective?

[1] https://lists.boost.org/boost-gil/2020/10/0465.php
[2] https://pdimov.github.io/articles/phasing_out_cxx03.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
> Gesendet: Montag, 26. Oktober 2020 um 10:37 Uhr
> Von: "Mateusz Loskot via Boost" <[hidden email]>
>
>
> Could anyone help us validate and confirm that
> it's a good plan or are we overlooking any policies
> from Boost's release perspective?
>

Just a general comment from the perspective of a user
(that is a user of boost in general, not boost-gil specifically).
Part of declaring c++XX support deprecated should also be
listing the concrete compilers whose support you are
deprecating.
E.g. I think the first c++17 bits have been implemented in
gcc 6 and  gcc 7 had mostly complete support, but it took
till gcc 9 before the standard library gained support for pmr
and to_chars is - to the bestof my knowledge - still not
implemented for floating point types even in g++-10/11.

Best regards

Mike


>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On Mon, 26 Oct 2020 at 11:17, Mike via Boost <[hidden email]> wrote:

> > Gesendet: Montag, 26. Oktober 2020 um 10:37 Uhr
> > Von: "Mateusz Loskot via Boost" <[hidden email]>
> >
> > Could anyone help us validate and confirm that
> > it's a good plan or are we overlooking any policies
> > from Boost's release perspective?
>
>
> Just a general comment from the perspective of a user
> (that is a user of boost in general, not boost-gil specifically).
> Part of declaring c++XX support deprecated should also be
> listing the concrete compilers whose support you are
> deprecating.

This is a good point.

> E.g. I think the first c++17 bits have been implemented in
> gcc 6 and  gcc 7 had mostly complete support, but it took
> till gcc 9 before the standard library gained support for pmr
> and to_chars is - to the bestof my knowledge - still not
> implemented for floating point types even in g++-10/11.

One of motivations is to drop support for GCC 5,
It just seem simpler to assume C++17 as requirement
with comment that some compilers w/ partial C++17
support may still work.
It may also be possible to list required C++17 features
per Boost (GIL) release, but that list may change
in any next release, obviously.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:

> Hi,
>
> We're discussing [1] to start switching GIL to C++17
> in the near future and, following Peter Dimov's policy
> on phasing out C++XY support [2], we'd like to:
>
> 1. Declare C++11 support deprecated in 1.75 (December 2020)
> 2. Drop C++11 support in 1.77 (?)  (August 2021)
>
> Could anyone help us validate and confirm that
> it's a good plan or are we overlooking any policies
> from Boost's release perspective?
>
> [1] https://lists.boost.org/boost-gil/2020/10/0465.php
> [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
>
> Best regards,
>

Just out of curiosity, what new features and/or benefits (if any) will
moving to conformance with C++17 add?

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On Mon, Oct 26, 2020 at 8:23 PM Robert Ramey via Boost <
[hidden email]> wrote:

>
> Just out of curiosity, what new features and/or benefits (if any) will
> moving to conformance with C++17 add?
>

just writing from the top of my head(will write details later), using C++17
GIL can be a stand-alone library.


--
Thank you,
Pranam Lashkari, https://lpranam.github.io/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr
> Von: "Mateusz Loskot via Boost" <[hidden email]>
>
> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <[hidden email]> wrote:
>
> > E.g. I think the first c++17 bits have been implemented in
> > gcc 6 and  gcc 7 had mostly complete support, but it took
> > till gcc 9 before the standard library gained support for pmr
> > and to_chars is - to the bestof my knowledge - still not
> > implemented for floating point types even in g++-10/11.
>
> One of motivations is to drop support for GCC 5,
> It just seem simpler to assume C++17 as requirement
> with comment that some compilers w/ partial C++17
> support may still work.

The problem I see  is: If you are pedantic, then there
isn't a complete c++17 toolchain on linux yet. So unless
you are saying, all current version of gcc/clang/libstdc++
"may still work" but are not really supported, you need
to be more specific in what you require and support.
Where support means (to me) "Will be regularly tested and
will continue to work for the next couple of releases/years".

> It may also be possible to list required C++17 features
> per Boost (GIL) release, but that list may change
> in any next release, obviously.

I wouldn't go there, because it isn't easy to actually verify
that the documented features and the used features stay in sync
and as a user, I also wouldn't appreaciate that mode,
because at that point it would probably be easier for me to
just try to compile your library and tests rather than corss-check
the feature sets of my toolchain and your list manually.

Just give me a stable lower bound on the officially supported
toolchain and language versions.

Of course all that doesn't mean that you can't add a note like
"Other toolchains may work too"
of course, but that is pretty much always the case anyway.

Best

Mike


>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 26 Oct 2020 at 15:53, Robert Ramey via Boost
<[hidden email]> wrote:

> On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
> >
> > We're discussing [1] to start switching GIL to C++17
> > in the near future and, following Peter Dimov's policy
> > on phasing out C++XY support [2], we'd like to:
> >
> > 1. Declare C++11 support deprecated in 1.75 (December 2020)
> > 2. Drop C++11 support in 1.77 (?)  (August 2021)
> >
> > Could anyone help us validate and confirm that
> > it's a good plan or are we overlooking any policies
> > from Boost's release perspective?
> >
> > [1] https://lists.boost.org/boost-gil/2020/10/0465.php
> > [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
>
> Just out of curiosity, what new features and/or benefits (if any) will
> moving to conformance with C++17 add?

e.g. make the library sexier for contributors who actually
expressed interest in developing features for the library
and who wish to use `-std=c++17` at least
when they develop pull requests for the library.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 26 Oct 2020 at 16:16, Mike via Boost <[hidden email]> wrote:

> > Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr
> > Von: "Mateusz Loskot via Boost" <[hidden email]>
> > On Mon, 26 Oct 2020 at 11:17, Mike via Boost <[hidden email]> wrote:
> >
> > > E.g. I think the first c++17 bits have been implemented in
> > > gcc 6 and  gcc 7 had mostly complete support, but it took
> > > till gcc 9 before the standard library gained support for pmr
> > > and to_chars is - to the bestof my knowledge - still not
> > > implemented for floating point types even in g++-10/11.
> >
> > One of motivations is to drop support for GCC 5,
> > It just seem simpler to assume C++17 as requirement
> > with comment that some compilers w/ partial C++17
> > support may still work.
>
> The problem I see  is: If you are pedantic, then there
> isn't a complete c++17 toolchain on linux yet.

GIL will not require feature-complete C++17 compiler
We should be good with the last of the GCC 6 kind [1]
or we may require GCC 7. The specifics will be decided
as we go, as contributors will require.
The deal is to announce C++11 phasing out early/now,
to let ourselves time, at least two releases, but in
practices it will be longer before we bump required
compiler versions high.

> So unless
> you are saying, all current version of gcc/clang/libstdc++
> "may still work" but are not really supported, you need
> to be more specific in what you require and support.
> Where support means (to me) "Will be regularly tested and
> will continue to work for the next couple of releases/years".

Yes, we will aim to cover claimed support with CI and Boost
regression tests matrix.

> > It may also be possible to list required C++17 features
> > per Boost (GIL) release, but that list may change
> > in any next release, obviously.
>
> I wouldn't go there, because it isn't easy to actually verify
> that the documented features and the used features stay in sync

I made a mistake.
Above I meant to write "Boost (GIL) release notes",
where we can list GIL's required C++17 features for
particular Boost release, just for user's convenience
and change/remove that list from release notes in future.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-10/msg00113.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On 10/26/2020 11:49 AM, Mateusz Loskot via Boost wrote:

> On Mon, 26 Oct 2020 at 16:16, Mike via Boost <[hidden email]> wrote:
>>> Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr
>>> Von: "Mateusz Loskot via Boost" <[hidden email]>
>>> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <[hidden email]> wrote:
>>>
>>>> E.g. I think the first c++17 bits have been implemented in
>>>> gcc 6 and  gcc 7 had mostly complete support, but it took
>>>> till gcc 9 before the standard library gained support for pmr
>>>> and to_chars is - to the bestof my knowledge - still not
>>>> implemented for floating point types even in g++-10/11.
>>>
>>> One of motivations is to drop support for GCC 5,
>>> It just seem simpler to assume C++17 as requirement
>>> with comment that some compilers w/ partial C++17
>>> support may still work.
>>
>> The problem I see  is: If you are pedantic, then there
>> isn't a complete c++17 toolchain on linux yet.
>
> GIL will not require feature-complete C++17 compiler
> We should be good with the last of the GCC 6 kind [1]
> or we may require GCC 7. The specifics will be decided
> as we go, as contributors will require.
> The deal is to announce C++11 phasing out early/now,
> to let ourselves time, at least two releases, but in
> practices it will be longer before we bump required
> compiler versions high.

Worrying about gcc6 and/or gcc7, when the current release is gcc 10.2,
seems a bit silly to me. I am not saying the current release(s) of gcc,
clang, and vc++ are perfect in their support for C++17, but they should
be good enough for any library wanting to target C++17. BTW wanting to
target C++17 because it is "sexier", as opposed to having some
feature(s) which the library wants to use, does not seem like a good
reason to target any C++ level. I assume GIL wants to target C++17
because of the latter.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On Mon, 26 Oct 2020 at 19:17, Edward Diener via Boost
<[hidden email]> wrote:

> On 10/26/2020 11:49 AM, Mateusz Loskot via Boost wrote:
> > On Mon, 26 Oct 2020 at 16:16, Mike via Boost <[hidden email]> wrote:
> >>> Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr
> >>> Von: "Mateusz Loskot via Boost" <[hidden email]>
> >>> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <[hidden email]> wrote:
> >>>
> >>>> E.g. I think the first c++17 bits have been implemented in
> >>>> gcc 6 and  gcc 7 had mostly complete support, but it took
> >>>> till gcc 9 before the standard library gained support for pmr
> >>>> and to_chars is - to the bestof my knowledge - still not
> >>>> implemented for floating point types even in g++-10/11.
> >>>
> >>> One of motivations is to drop support for GCC 5,
> >>> It just seem simpler to assume C++17 as requirement
> >>> with comment that some compilers w/ partial C++17
> >>> support may still work.
> >>
> >> The problem I see  is: If you are pedantic, then there
> >> isn't a complete c++17 toolchain on linux yet.
> >
> > GIL will not require feature-complete C++17 compiler
> > We should be good with the last of the GCC 6 kind [1]
> > or we may require GCC 7. The specifics will be decided
> > as we go, as contributors will require.
> > The deal is to announce C++11 phasing out early/now,
> > to let ourselves time, at least two releases, but in
> > practices it will be longer before we bump required
> > compiler versions high.
>
> Worrying about gcc6 and/or gcc7, when the current release is gcc 10.2,
> seems a bit silly to me. I am not saying the current release(s) of gcc,
> clang, and vc++ are perfect in their support for C++17, but they should
> be good enough for any library wanting to target C++17.

Yes, indeed.
I just explained that nobody there will die too hard for GCC 6,
if it prevents use of a particular feature, etc.

> BTW wanting to target C++17 because it is "sexier",
> as opposed to having some feature(s) which the library wants to use,
> does not seem like a good reason to target any C++ level.
> I assume GIL wants to target C++17 because of the latter.

We have more serious reasons indeed.
e.g. to get rid of Boost.Iterator [1], possibly replace it with
stl_interfaces [2] (but w/o investing time to go just C++14).

[1] https://lists.boost.org/boost-users/2020/03/90323.php
[2] https://lists.boost.org/boost-users/2020/03/90325.php

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Oct 26, 2020 at 8:38 AM Mateusz Loskot via Boost <
[hidden email]> wrote:

>
> On Mon, 26 Oct 2020 at 15:53, Robert Ramey via Boost
> <[hidden email]> wrote:
> > On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
> > >
> > > We're discussing [1] to start switching GIL to C++17
> > > in the near future and, following Peter Dimov's policy
> > > on phasing out C++XY support [2], we'd like to:
> > >
> > > 1. Declare C++11 support deprecated in 1.75 (December 2020)
> > > 2. Drop C++11 support in 1.77 (?)  (August 2021)
> > >
> > > Could anyone help us validate and confirm that
> > > it's a good plan or are we overlooking any policies
> > > from Boost's release perspective?
> > >
> > > [1] https://lists.boost.org/boost-gil/2020/10/0465.php
> > > [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
> >
> > Just out of curiosity, what new features and/or benefits (if any) will
> > moving to conformance with C++17 add?
>
> e.g. make the library sexier for contributors who actually
> expressed interest in developing features for the library
> and who wish to use `-std=c++17` at least
> when they develop pull requests for the library.

Really, the stated reason for dropping support for C++11 is that it will
make the library "sexier"?

I understand that this would enable GIL to be compiled as a standalone
library, and that's a good thing, but it would be better to provide that
functionality and not break what currently works. Or at least take a stab
at it and see how bad it is to support both. After all, Boost provides
excellent support for workarounds and compiler compatibility.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On Mon, 26 Oct 2020 at 20:40, Emil Dotchevski via Boost
<[hidden email]> wrote:

> On Mon, Oct 26, 2020 at 8:38 AM Mateusz Loskot via Boost <[hidden email]> wrote:
> > On Mon, 26 Oct 2020 at 15:53, Robert Ramey via Boost
> > <[hidden email]> wrote:
> > > On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
> > > >
> > > > We're discussing [1] to start switching GIL to C++17
> > > > in the near future and, following Peter Dimov's policy
> > > > on phasing out C++XY support [2], we'd like to:
> > > >
> > > > 1. Declare C++11 support deprecated in 1.75 (December 2020)
> > > > 2. Drop C++11 support in 1.77 (?)  (August 2021)
> > > >
> > > > Could anyone help us validate and confirm that
> > > > it's a good plan or are we overlooking any policies
> > > > from Boost's release perspective?
> > > >
> > > > [1] https://lists.boost.org/boost-gil/2020/10/0465.php
> > > > [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
> > >
> > > Just out of curiosity, what new features and/or benefits (if any) will
> > > moving to conformance with C++17 add?
> >
> > e.g. make the library sexier for contributors who actually
> > expressed interest in developing features for the library
> > and who wish to use `-std=c++17` at least
> > when they develop pull requests for the library.
>
> Really, the stated reason for dropping support for C++11 is that it will
> make the library "sexier"?

No. I dodged the questions like those about the exact list of C++17 features.

> I understand that this would enable GIL to be compiled as a standalone
> library, and that's a good thing, but it would be better to provide that
> functionality and not break what currently works. Or at least take a stab
> at it and see how bad it is to support both. After all, Boost provides
> excellent support for workarounds and compiler compatibility.

As I explained, one of major changes we will do is getting rid of Boost.Iterator
(we already removed Boost.MPL, Boost.TypeTraits, and several more).

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
> As I explained, one of major changes we will do is getting rid of Boost.Iterator
> (we already removed Boost.MPL, Boost.TypeTraits, and several more).

I think the questions that should be asked is

a) "what will be of the most value to users?"
b) "how will this expand the potential user base?"
c) It the above are positive, the next question would be "how much
effort would be required.

So I generally answer the above by required the oldest version of C++
which supports the features that the library needs.  This maximizes the
breadth of the potential audience while minimizing the effort required.
By the same token, if one isn't going to add features that users are
requesting, there isn't much point in investing more effort in the library.

So if it were me, I'd say - move it to C++ 11 or perhaps 14 to simplify
the code, and maintenance, and leave moving to C++17 or higher when
there will be some positive return on the effort.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On Mon, 26 Oct 2020 at 21:58, Robert Ramey via Boost
<[hidden email]> wrote:

> > As I explained, one of major changes we will do is getting rid of Boost.Iterator
> > (we already removed Boost.MPL, Boost.TypeTraits, and several more).
>
> I think the questions that should be asked is
>
> a) "what will be of the most value to users?"
> b) "how will this expand the potential user base?"
> c) It the above are positive, the next question would be "how much
> effort would be required.
>
> So I generally answer the above by required the oldest version of C++
> which supports the features that the library needs.

Yes, that will be the case for GIL too.
Simply, if 1) there are PRs with new features that are valuable to
users and 2) implementation of those features uses C++17
and 3) nobody offers time to port those to C++11 (or it's not
possible), then we have grounds to make the switch.


> So if it were me, I'd say - move it to C++ 11

FYI, GIL moved to C++11 in Boost 1.68
(w/ removal of MPL, TypeTraits, Variant, etc.)

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 26 Oct 2020 at 10:37, Mateusz Loskot <[hidden email]> wrote:
>
> We're discussing [1] to start switching GIL to C++17
> in the near future and, following Peter Dimov's policy
> on phasing out C++XY support [2], we'd like to:
>
> 1. Declare C++11 support deprecated in 1.75 (December 2020)
> 2. Drop C++11 support in 1.77 (?)  (August 2021)

We are also considering, with Samuel, a less revolutionary approach:
deprecate specific compiler/version in case it does not support
certain C++11 features properly or suffers from bugs.
For example, we may advertise dropping GCC 5 support
due to issues similar to this https://github.com/boostorg/gil/pull/526

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
Mateusz Loskot wrote:

> We are also considering, with Samuel, a less revolutionary approach:
> deprecate specific compiler/version in case it does not support certain
> C++11 features properly or suffers from bugs.
> For example, we may advertise dropping GCC 5 support due to issues similar
> to this https://github.com/boostorg/gil/pull/526

If you drop GCC 5, you can make the minimum requirement C++14, as it's the
default for GCC 6 and newer. (C++17 is default for GCC 11.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
On Tue, 27 Oct 2020 at 13:21, Peter Dimov via Boost
<[hidden email]> wrote:

> Mateusz Loskot wrote:
>
> > We are also considering, with Samuel, a less revolutionary approach:
> > deprecate specific compiler/version in case it does not support certain
> > C++11 features properly or suffers from bugs.
> > For example, we may advertise dropping GCC 5 support due to issues similar
> > to this https://github.com/boostorg/gil/pull/526
>
> If you drop GCC 5, you can make the minimum requirement C++14, as it's the
> default for GCC 6 and newer. (C++17 is default for GCC 11.)

Sounds fine too. I'll pass it to Samuel. Thanks.

--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/27/2020 8:20 AM, Peter Dimov via Boost wrote:

> Mateusz Loskot wrote:
>
>> We are also considering, with Samuel, a less revolutionary approach:
>> deprecate specific compiler/version in case it does not support
>> certain C++11 features properly or suffers from bugs.
>> For example, we may advertise dropping GCC 5 support due to issues
>> similar to this https://github.com/boostorg/gil/pull/526
>
> If you drop GCC 5, you can make the minimum requirement C++14, as it's
> the default for GCC 6 and newer. (C++17 is default for GCC 11.)

I do not think that is a good argument for the minimum level of C++ a
library decides to support. Programmers can always decide, if they wish,
not to use the default level of a compiler. I do however see little
wrong with dropping support for very old compiler releases when those
releases do not implement correctly the minimum level of the C++
standard which a library targets.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [gil] Phasing out support C++11 and switching to C++17

Boost - Dev mailing list
Edward Diener wrote:
> On 10/27/2020 8:20 AM, Peter Dimov via Boost wrote:
>
> > If you drop GCC 5, you can make the minimum requirement C++14, as it's
> > the default for GCC 6 and newer. (C++17 is default for GCC 11.)
>
> I do not think that is a good argument for the minimum level of C++ a
> library decides to support. Programmers can always decide, if they wish,
not to use the default level of a compiler.

Yes, in theory, but there aren't many reasons to downgrade GCC 6 to C++11,
as C++14 has very good backward compatibility.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost