A possible date for dropping c++03 support

classic Classic list List threaded Threaded
116 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

A possible date for dropping c++03 support

Boost - Dev mailing list
From the discussion about abi compatibility when the Boost.System library is
compiled e.g. in c++03 mode and then included in ac++11 project or vice
versa
(https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
g)

>
> When can we drop C++03 support? :D

This will probably be ignored or shouted down, but maybe someone just needs
to make a concrete suggestion about which people can discuss and vote so I'm
giving it a shot:

What about the first or second release in 2020 ?

By then, all major toolchains have had solid c++11 support for at least 5
years ( I think, msvc was the last one with VS2015) and at least partial
support for 7+ years (gcc 4.8, msvc 2013, clang 3.3). Also, most likely
c++20 will be released in that year, which means that c++03 compatible
libraries would have to support 5 different (and partial incompatible)
language versions by then (not to mention ABI-compatibility considerations
between different versions).

That should also be enough time to ensure that the last c++03 release (late
2019) is really solid (for projects that still can't upgrade to c++11) and
ideally there could be a few more bugfix-releases afterwards as is often
done by other software projects.

And before someone starts to raise straw mans: That of course wouldn't mean
that a particular library *must* no longer compile in 03 mode, but one can
no longer rely on the boost-internal dependencies remaining c++03
compatible.

Best

Mike


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
On 8/25/18 12:51 PM, Mike Dev via Boost wrote:
>  From the discussion about abi compatibility when the Boost.System library is
> compiled e.g. in c++03 mode and then included in ac++11 project or vice
> versa
> (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
> g)
>
>>
>> When can we drop C++03 support? :D


My understanding has been the boost only requires that libraries be
conforming to the current C++ standard. I don't think that requires for
support for C++03

Robert Ramey

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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/25/2018 1:51 PM, Mike Dev via Boost wrote:

>  From the discussion about abi compatibility when the Boost.System library is
> compiled e.g. in c++03 mode and then included in ac++11 project or vice
> versa
> (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
> g)
>
>>
>> When can we drop C++03 support? :D
>
> This will probably be ignored or shouted down, but maybe someone just needs
> to make a concrete suggestion about which people can discuss and vote so I'm
> giving it a shot:
>
> What about the first or second release in 2020 ?

Please define what is meant by "dropping C++03 support" ? This has come
up repeatedly in the past and I always ask the same question.
Unfortunately, whatever is meant by "Boost dropping C++03 support" is
never actually defined. Its is so convenient to say "let's drop C++03
support" when it does not mean anything. I it like saying "I believe in
freedom", which also means nothing. We are a technical group. Please
define what you mean. Then perhaps an intelligent discussion can ensue.

>
> By then, all major toolchains have had solid c++11 support for at least 5
> years ( I think, msvc was the last one with VS2015) and at least partial
> support for 7+ years (gcc 4.8, msvc 2013, clang 3.3). Also, most likely
> c++20 will be released in that year, which means that c++03 compatible
> libraries would have to support 5 different (and partial incompatible)
> language versions by then (not to mention ABI-compatibility considerations
> between different versions).
>
> That should also be enough time to ensure that the last c++03 release (late
> 2019) is really solid (for projects that still can't upgrade to c++11) and
> ideally there could be a few more bugfix-releases afterwards as is often
> done by other software projects.
>
> And before someone starts to raise straw mans: That of course wouldn't mean
> that a particular library *must* no longer compile in 03 mode, but one can
> no longer rely on the boost-internal dependencies remaining c++03
> compatible.
>
> Best
>
> Mike


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

A possible date for dropping c++03 support

Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Edward Diener via
> Boost
> Sent: Sunday, August 26, 2018 7:07 AM
>
> On 8/25/2018 1:51 PM, Mike Dev via Boost wrote:
> > From the discussion about abi compatibility when the Boost.System
> > library is compiled e.g. in c++03 mode and then included in a
> > c++11 project or vice
> > versa
> > (https://groups.google.com/forum/#!topic/boost-developers-
> archive/EWG5NVOZo_
> > g)
> >
> >>
> >> When can we drop C++03 support? :D
> >
> > [...]
> >
> > What about the first or second release in 2020 ?
>
> Please define what is meant by "dropping C++03 support

For me it means that

- a contributor can use c++11 language and library features
  (be it the library maintainer or someone else opening a PR
  on Github)

- A user (external or internal) may no longer expect a boost library
  to compile with a compiler not supporting c++11 (and we can have a
  discussion just which compilers that are) or when he tries
  to compile it in c++03 language mode (e.g. -std=c++03)

Is that definition precise enough?
What other definition did you have in mind (if any)?

If that is your concern:
I would certainly not expect that you start ripping out the guts
of an old, battle proven library and replace everything with c++11
features just for the fun of it. However, next time a feature is
added or a bug has to be fixed, you no longer have to restrict
yourself to c++03.
And maybe, over time, some people will contribute patches that
simplify / improve a library by replacing some complex c++03 solutions
with simpler c++11 solutions when applicable.

Best

Mike


 


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> Sent: Sunday, August 26, 2018 3:17 AM
>
> On 8/25/18 12:51 PM, Mike Dev via Boost wrote:
> >  From the discussion about abi compatibility when the Boost.System library is
> > compiled e.g. in c++03 mode and then included in ac++11 project or vice
> > versa
> > (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
> > g)
> >
> >>
> >> When can we drop C++03 support? :D
>
>
> My understanding has been the boost only requires that libraries be
> conforming to the current C++ standard. I don't think that requires for
> support for C++03

I certainly didn't want to claim otherwise as a lot of libraries already require
c++11 or later. However, I'm talking about dropping c++03 support in libraries
that did support it till now.

Considering the strong internal coupling between older boost libraries,
an individual library can't drop c++03 support without this decision
affecting many, many other boost libraries. And while external users that
can't migrate to c++11 have the option to just stick to an older boost
version, internal users (aka other boost libraries depending on it)
can't do that.
So, let's say the maintainer of Boost.iterator wants to drop c++03 support
and start using c++11 features. That would mean that at least a dozen or so
other libraries that depend on it would suddenly also no longer be c++03
compatible without them having any say in it.
If I were a boost library maintainer I'd certain not want to make the switch
to c++11 under those conditions, even if I'd do it with a standalone library
for which I can just release a new major version. This is, why I think,
such a decision needs to be made by all affected maintainers (or at least
by most of them) together.

Mike    

>
> Robert Ramey
>
> _______________________________________________
> 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: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/25/2018 10:42 PM, Mike Dev via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Edward Diener via
>> Boost
>> Sent: Sunday, August 26, 2018 7:07 AM
>>
>> On 8/25/2018 1:51 PM, Mike Dev via Boost wrote:
>>>  From the discussion about abi compatibility when the Boost.System
>>> library is compiled e.g. in c++03 mode and then included in a
>>> c++11 project or vice
>>> versa
>>> (https://groups.google.com/forum/#!topic/boost-developers-
>> archive/EWG5NVOZo_
>>> g)
>>>
>>>>
>>>> When can we drop C++03 support? :D
>>>
>>> [...]
>>>
>>> What about the first or second release in 2020 ?
>>
>> Please define what is meant by "dropping C++03 support
>
> For me it means that
>
> - a contributor can use c++11 language and library features
>    (be it the library maintainer or someone else opening a PR
>    on Github)

There are libraries which work with C++03 on up. If a contributor
decides to use a C++11 language or library feature with that library it
can no longer work with C++03. I think it should be up to the library
maintainer whether a library no longer works with C++03 or not.
Otherwise any contributor to a library can decide what C++ standard
level that library should support.

>
> - A user (external or internal) may no longer expect a boost library
>    to compile with a compiler not supporting c++11 (and we can have a
>    discussion just which compilers that are) or when he tries
>    to compile it in c++03 language mode (e.g. -std=c++03)

There are plenty of libraries which need some level of support from
C++11 on up. The user of that library currently expects that such a
library will not work when compiling at the C++03 level. OTOH there are
some libraries that will work with C++03 on up. Are you going to tell a
user that they should no longer expect to work with such a library at
the C++03 level even when it currently works fine at that level ? For
what purpose ?

>
> Is that definition precise enough?
> What other definition did you have in mind (if any)?

I had no definition in mind. Every time someone speaks of Boost
"dropping C++03 support" it means whatever that person wants it to mean.

>
> If that is your concern:
> I would certainly not expect that you start ripping out the guts
> of an old, battle proven library and replace everything with c++11
> features just for the fun of it. However, next time a feature is
> added or a bug has to be fixed, you no longer have to restrict
> yourself to c++03.

No library maintainer has to restrict his library to any C++ level.
The usual course when upgrading a C++ level is to tell end-users what
you intend to do, and then eventually do it in some later Boost release.
A new library may be written supporting any C++ standard level that it
wants. There is much encouragement in Boost for developers to use a C++
standard level which is useful for whatever they want their library to
accomplish. No library is forced to maintain backwards compatibility
with the C++03 level if it does not want to do so.

> And maybe, over time, some people will contribute patches that
> simplify / improve a library by replacing some complex c++03 solutions
> with simpler c++11 solutions when applicable.

Anybody is welcome to do that and a some people have already
successfully achieved that goal and had their library accepted into
Boost. Boost does not discourage anyone from creating a better version
of a library using a more modern C++ level and more modern programming
idioms.

My objection to the usual Boost "dropping C++03 support" is that there
is absolutely no reason for forcing libraries which do support C++03,
while being usable at any higher C++ standard level, to do anything. If
you think that some library which works with C++03 would be better by
using some later C++ standard level feature you can always suggest it
and maybe the maintainer will agree with you. But forcing a library to
use some idiom of a higher C++ standard level when the library itself
has no use for any such an idiom seems pretty foolish to me.

>
> Best
>
> Mike


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> By then, all major toolchains have had solid c++11 support for at least 5
> years ( I think, msvc was the last one with VS2015) and at least partial
> support for 7+ years (gcc 4.8, msvc 2013, clang 3.3).

compilers are one thing, compiler adoption is another ... i remember
that in the past "stable" linux distributions provided compilers that
were considered as "outdated", but that were used in production on HPC
systems.
but maybe this is less of an issue these days ..


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
Tim Blechmann wrote:
> > By then, all major toolchains have had solid c++11 support for at least
> > 5 years ( I think, msvc was the last one with VS2015) and at least
> > partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3).
>
> compilers are one thing, compiler adoption is another ... i remember
> that in the past "stable" linux distributions provided compilers that
> were considered as "outdated", but that were used in production on HPC
> systems.
> but maybe this is less of an issue these days ..

The current LTSes (Ubuntu Trusty, CentOS 7) are on g++ 4.8, which has
reasonable (but not quite complete) C++11 support.


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/25/2018 11:07 PM, Mike Dev via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
>> Sent: Sunday, August 26, 2018 3:17 AM
>>
>> On 8/25/18 12:51 PM, Mike Dev via Boost wrote:
>>>   From the discussion about abi compatibility when the Boost.System library is
>>> compiled e.g. in c++03 mode and then included in ac++11 project or vice
>>> versa
>>> (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
>>> g)
>>>
>>>>
>>>> When can we drop C++03 support? :D
>>
>>
>> My understanding has been the boost only requires that libraries be
>> conforming to the current C++ standard. I don't think that requires for
>> support for C++03
>
> I certainly didn't want to claim otherwise as a lot of libraries already require
> c++11 or later. However, I'm talking about dropping c++03 support in libraries
> that did support it till now.
>
> Considering the strong internal coupling between older boost libraries,
> an individual library can't drop c++03 support without this decision
> affecting many, many other boost libraries. And while external users that
> can't migrate to c++11 have the option to just stick to an older boost
> version, internal users (aka other boost libraries depending on it)
> can't do that.
> So, let's say the maintainer of Boost.iterator wants to drop c++03 support
> and start using c++11 features. That would mean that at least a dozen or so
> other libraries that depend on it would suddenly also no longer be c++03
> compatible without them having any say in it.
> If I were a boost library maintainer I'd certain not want to make the switch
> to c++11 under those conditions, even if I'd do it with a standalone library
> for which I can just release a new major version. This is, why I think,
> such a decision needs to be made by all affected maintainers (or at least
> by most of them) together.

You have things backward. How can all maintainers decide what level of
C++ support a particular library should have ? Library X has features
which determine what level of C++ support it needs. Simply because
dependent libraries A, B, and C use library X they certainly can not
decide for library X what level of C++ support it should have ?

I think you do not seem to understand that a library's level of C++
support depends on the C++ language and library idioms it uses, not on
some theoretical need to support some level of the C++ standard. If a
library works at the C++03 level and Boost decides to "drop C++03
support" in your terms, what do you actually propose to do with such a
library ?

I would really like to know your answer to that ?

Are you going to force it to use some C++11 on up feature in its code so
that it no longer compiles at the C++03 level, even when it has no use
for any C++11 on up feature anywhere in its implementation ? I am sure
you realize how silly that would be. Are you going to drop the library
from the list of Boost libraries even though the library works perfectly
well with users who compile it with C++11, C++17, or C++20 levels ? That
would really be absurd. Do you want to make an announcement on the Boost
web page that Boost libraries which support C++03 may not support that
level in the future and therefore Boost end-users are encouraged to use
a higher level of C++ when using Boost libraries ? That might be
reasonable, but then again we can say that for any library, ie. that it
might only work in the future with a higher level of the C++ standard
than it currently supports. So now can you see why your suggestion of
Boost "dropping support for C++03", like others in the past who have
said the same thing, is so generally meaningless ? It is because
practically there is nothing to be done except perhaps a general
announcement on the Boost web page, and even that has no affect on
libraries which support C++03 right now, nor should it.


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Edward Diener wrote:

> My objection to the usual Boost "dropping C++03 support" is that there is
> absolutely no reason for forcing libraries which do support C++03, while
> being usable at any higher C++ standard level, to do anything.

Boost dropping C++03 support means just that, we announce that Boost no
longer supports C++03. Individual libraries may or may not continue to
support it, but f.ex. trying "b2 install" with a C++03 compiler will no
longer be expected to work.

We could then consider building with -std=c++11 by default on g++ 4.8/4.9,
and with -std=c++14 by default on g++5 and possibly clang (although clang
c++14 doesn't quite work with libstdc++ 4.x so that'd be a problem).


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Edward Diener wrote:

> Are you going to force it to use some C++11 on up feature in its code so
> that it no longer compiles at the C++03 level, even when it has no use for
> any C++11 on up feature anywhere in its implementation ?

He wasn't suggesting anything like that. His point is simply that if a
library is heavily depended upon, the author's decision to drop C++03
support affects all downstream libraries, which by virtue of having this
dependency will also lose C++03 support even if they themselves use no
non-C++03 features.

Consequently, said author would be reluctant to break C++03 compatibility
because it would affect more than just one library.

But if we officially "drop C++03 support" he'll be freer to do so.


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Peter Dimov via Boost
> Sent: 26 August 2018 14:02
> To: [hidden email]
> Cc: Peter Dimov
> Subject: Re: [boost] A possible date for dropping c++03 support
>
> Edward Diener wrote:
>
> > Are you going to force it to use some C++11 on up feature in its code so
> > that it no longer compiles at the C++03 level, even when it has no use for
> > any C++11 on up feature anywhere in its implementation ?
>
> He wasn't suggesting anything like that. His point is simply that if a
> library is heavily depended upon, the author's decision to drop C++03
> support affects all downstream libraries, which by virtue of having this
> dependency will also lose C++03 support even if they themselves use no
> non-C++03 features.
>
> Consequently, said author would be reluctant to break C++03 compatibility
> because it would affect more than just one library.

Do we have any idea how many real examples of this dependency there are?
 
> But if we officially "drop C++03 support" he'll be freer to do so.

And feel less obliged to try to provide a 'workaround' where possible

#ifdef C++03
  do something old-school
#else
  do something trendier
#endif

and instead saying

#ifdef C++03
#error " C++03 not supported!"

Can we make may those who wish to 'Officially' drop support for C++03 feel better
(and quiet the repeated requests)
by

  Officially Deprecating  use of C++03 compilers and use of -std=c++03

(and next year deprecating C++11 ;-)

Paul





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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 08/26/18 15:46, Peter Dimov via Boost wrote:

> Tim Blechmann wrote:
>> > By then, all major toolchains have had solid c++11 support for at
>> least > 5 years ( I think, msvc was the last one with VS2015) and at
>> least > partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3).
>>
>> compilers are one thing, compiler adoption is another ... i remember
>> that in the past "stable" linux distributions provided compilers that
>> were considered as "outdated", but that were used in production on HPC
>> systems.
>> but maybe this is less of an issue these days ..
>
> The current LTSes (Ubuntu Trusty, CentOS 7) are on g++ 4.8, which has
> reasonable (but not quite complete) C++11 support.

The current Ubuntu LTS is 18.04 (Bionic), it ships with gcc 7.3 and
clang 6.0.0. 16.04 (Xenial) and 14.04 (Trusty) are stull supported,
though - until 2021 and 2019, respectively.

https://wiki.ubuntu.com/Releases

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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
Andrey Semashev wrote:
> > The current LTSes (Ubuntu Trusty, CentOS 7) are on g++ 4.8, which has
> > reasonable (but not quite complete) C++11 support.
>
> The current Ubuntu LTS is 18.04 (Bionic), it ships with gcc 7.3 and clang
> 6.0.0. 16.04 (Xenial) and 14.04 (Trusty) are stull supported, though -
> until 2021 and 2019, respectively.

That's what I meant by "current" - still supported. As I've said before, you
don't use an LTS if you keep upgrading at earliest opportunity.


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

A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Tim Blechmann via Boost
> Sent: Sunday, August 26, 2018 3:02 PM
>
> > By then, all major toolchains have had solid c++11 support for at least 5
> > years ( I think, msvc was the last one with VS2015) and at least partial
> > support for 7+ years (gcc 4.8, msvc 2013, clang 3.3).
>
> compilers are one thing, compiler adoption is another ... I remember
> that in the past "stable" linux distributions provided compilers that
> were considered as "outdated", but that were used in production on HPC
> systems.
> but maybe this is less of an issue these days ..

I don't know, what distributions are used in HPC computing, but if we have
a short look at common linux distributions that have any sort of long term
support, then I'd say things look pretty good there:

- The oldest Ubuntu version supported in 2020 will be 16.04,
  which ships with gcc-5 (and even 14.04 had an almost complete c++11
  toolchain with gcc-4.8)

- With Debian it is AFAIK Debian 8 (gcc 4.9).

- I'm not sure what counts as EOL for RHEL/CentOS (that might be the
  problematic one), but the way I read the matrix in
 (https://access.redhat.com/support/policy/updates/errata),
  the oldest relevant distribution in 2020 (although already in
  Extended Life-cycle Support) will be RHEL 6 which only shipped with
  gcc4.4.

  However, RH provides the developer toolsets which include current
  versions of gcc. I'm not familiar with the details though, so maybe
  someone using RHEL could chime in here.

- I'm somewhat expecting Windows to be the more problematic environment as msvc
  only got full c++11 support in 2015 (at least as far as you can call msvc
  standard conformant prior to the very latest version anyway) and extended
  support for 2013 ends in 2024.

I think in general the question is:
How many projects will there be in 2020 that (for whatever reason) still need to
compile in 03 mode, but at the same time are interested in the latest version of
boost? I'd expect that intersection to be very small, but of course it will be
non-zero - and probably remain so for at least another decade (maybe forever).
 
Maybe one could start survey, but in any case: does boost really want to provide
free and indefinite support for those projects considering that maintenance is
already a problem for some libraries?
And again: Projects outside of boost can always opt to remain at the last
version that had official 03 support.





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

A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Edward Diener via Boost
> Sent: Sunday, August 26, 2018 8:51 PM
>
> On 8/25/2018 11:07 PM, Mike Dev via Boost wrote:
> >> -----Original Message-----
> >> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> >> Sent: Sunday, August 26, 2018 3:17 AM
> >>
> >> On 8/25/18 12:51 PM, Mike Dev via Boost wrote:
> >>>   From the discussion about abi compatibility when the Boost.System library is
> >>> compiled e.g. in c++03 mode and then included in ac++11 project or vice
> >>> versa
> >>> (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
> >>> g)
> >>>
> >>>>
> >>>> When can we drop C++03 support? :D
> >>
> >>
> >> My understanding has been the boost only requires that libraries be
> >> conforming to the current C++ standard. I don't think that requires for
> >> support for C++03
> >
> > I certainly didn't want to claim otherwise as a lot of libraries already require
> > c++11 or later. However, I'm talking about dropping c++03 support in libraries
> > that did support it till now.
> >
> > Considering the strong internal coupling between older boost libraries,
> > an individual library can't drop c++03 support without this decision
> > affecting many, many other boost libraries. And while external users that
> > can't migrate to c++11 have the option to just stick to an older boost
> > version, internal users (aka other boost libraries depending on it)
> > can't do that.
> > So, let's say the maintainer of Boost.iterator wants to drop c++03 support
> > and start using c++11 features. That would mean that at least a dozen or so
> > other libraries that depend on it would suddenly also no longer be c++03
> > compatible without them having any say in it.
> > If I were a boost library maintainer I'd certain not want to make the switch
> > to c++11 under those conditions, even if I'd do it with a standalone library
> > for which I can just release a new major version. This is, why I think,
> > such a decision needs to be made by all affected maintainers (or at least
> > by most of them) together.
>
> You have things backward. How can all maintainers decide what level of
> C++ support a particular library should have ? Library X has features
> which determine what level of C++ support it needs. Simply because
> dependent libraries A, B, and C use library X they certainly can not
> decide for library X what level of C++ support it should have ?
>
> I think you do not seem to understand that a library's level of C++
> support depends on the C++ language and library idioms it uses, not on
> some theoretical need to support some level of the C++ standard. If a
> library works at the C++03 level and Boost decides to "drop C++03
> support" in your terms, what do you actually propose to do with such a
> library ?
>
> I would really like to know your answer to that ?
>

For almost all c++ libraries I'm aware of, the supported minimal c++ version
is a project management decision that comes first and based on that decision,
the developers use the features that are available to them (or enable later
features only conditionally via the preprocessor). Essentially it is a
tradeoff between being usable by as many projects as possible vs doing without
all the nice features that the new language standard provides

Of course, over time, project management might decide to drop support certain
c++ versions as client needs change (no need to stay compatible with c++03 if
none of your clients' needs that compatibility).

For boost, the clients are not only external users but also other boost libraries
that might want to provide c++03 compatibility to their clients and while no one
is *forced* to keep his or her library compatible to c++03, it creates a certain
level of peer pressure if you know that if you start using c++11 features, the
libraries that depend on you can also no longer be compiled in 03 mode or have
to implement the functionality themselves
(I mean no one wants to make life difficult for their colleagues right?)

> Are you going to force it to use some C++11 on up feature in its code so
> that it no longer compiles at the C++03 level, even when it has no use
> for any C++11 on up feature anywhere in its implementation ? I am sure
> you realize how silly that would be. Are you going to drop the library
> from the list of Boost libraries even though the library works perfectly
> well with users who compile it with C++11, C++17, or C++20 levels ?

Where do those ideas come from?

From my initial post:
============
And before someone starts to raise straw mans: That of course wouldn't mean
that a particular library *must* no longer compile in 03 mode, but one can
no longer rely on the boost-internal dependencies remaining c++03
compatible.
=============

or from my second mail:

=============
I would certainly not expect that you start ripping out the guts
of an old, battle proven library and replace everything with c++11
features just for the fun of it.
=============

I don't know why this has to be repeated over and over again.

> That
> would really be absurd. Do you want to make an announcement on the Boost
> web page that Boost libraries which support C++03 may not support that
> level in the future and therefore Boost end-users are encouraged to use
> a higher level of C++ when using Boost libraries ? That might be
> reasonable, but then again we can say that for any library, ie. that it
> might only work in the future with a higher level of the C++ standard
> than it currently supports. So now can you see why your suggestion of
> Boost "dropping support for C++03", like others in the past who have
> said the same thing, is so generally meaningless ? It is because
> practically there is nothing to be done except perhaps a general
> announcement on the Boost web page, and even that has no affect on
> libraries which support C++03 right now, nor should it.

I wonder if the reason it appears meaningless to you is because you deliberately
want to misunderstand the suggestion.

You as a library programmer should know better than anyone else that there is a
difference between supported (and hopefully) documented API behavior, which you
are committed to support and implementation details that might change at any moment
(and don't get me started on UB that happens to do what you expect in a particular
version of your  compiler).

Currently, many libraries are committed to support c++03, meaning they won't just
start to use c++11 features without prior announcement and some transition phase.
After officially dropping c++03 support (with prior announcement and appropriate
transition phase), whether a library happens to still compile with c++03 or not
becomes an implementation detail that might or might not change with every new revision.

Best

Mike



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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Paul A. Bristow via Boost
> Sent: Sunday, August 26, 2018 10:07 PM
>
>
>
> > -----Original Message-----
> > From: Boost [mailto:[hidden email]] On Behalf Of Peter Dimov via Boost
> > Sent: 26 August 2018 14:02
> > To: [hidden email]
> > Cc: Peter Dimov
> > Subject: Re: [boost] A possible date for dropping c++03 support
> >
> > Edward Diener wrote:
> >
> > [...]
> >
> > Consequently, said author would be reluctant to break C++03 compatibility
> > because it would affect more than just one library.
>
> Do we have any idea how many real examples of this dependency there are?
>

If you mean how many c++03 libraries are used by other boost libraries that
support 03, then I'm willing to determine this number if you want(might take a
bit though). But if you have a look at the boost dependency graph you'll see
that this a actually very common case.

What I don't know is of course, how many of those libraries are maintained
by people that would like to use c++11 or later if they did not have to care
about other libraries depending on them.

Maybe this thread will shine some light on it

Best

Mike



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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Mike Dev wrote:

> - I'm not sure what counts as EOL for RHEL/CentOS (that might be the
>   problematic one), but the way I read the matrix in
>  (https://access.redhat.com/support/policy/updates/errata),
>   the oldest relevant distribution in 2020 (although already in
>   Extended Life-cycle Support) will be RHEL 6 which only shipped with
>   gcc4.4.

CentOS say in https://wiki.centos.org/Download that 6 is supported as
"Production Phase 3" which they therefore don't recommend using.

"The CentOS team recommends that you start moving workloads from CentOS
Linux 6 to CentOS Linux 7."


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/26/2018 8:53 AM, Peter Dimov via Boost wrote:

> Edward Diener wrote:
>
>> My objection to the usual Boost "dropping C++03 support" is that there
>> is absolutely no reason for forcing libraries which do support C++03,
>> while being usable at any higher C++ standard level, to do anything.
>
> Boost dropping C++03 support means just that, we announce that Boost no
> longer supports C++03. Individual libraries may or may not continue to
> support it, but f.ex. trying "b2 install" with a C++03 compiler will no
> longer be expected to work.

What do you mean that it will no longer be "expected to work" with some
individual library ? We already have that for plenty of libraries that
will not work unless the level of support is C++11 or above. But this is
because compile errors will result if you compile the library in C++03
mode. Are you saying that b2 should be changed so that it detects if it
is being invoked with a C++ standard C++03 level and will therefore put
out a b2 error message instead of continuing ? Even if that were true
that will only affect running tests and building docs for such a library
if the library is a header-only library, and since the end-user of a
distribution hardly needs to build docs it will only affect running
tests for a header-only library.

>
> We could then consider building with -std=c++11 by default on g++
> 4.8/4.9, and with -std=c++14 by default on g++5 and possibly clang
> (although clang c++14 doesn't quite work with libstdc++ 4.x so that'd be
> a problem).

At least that is a practical proposal, but of course does not affect
header-only libraries.


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

Re: A possible date for dropping c++03 support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/26/2018 9:02 AM, Peter Dimov via Boost wrote:

> Edward Diener wrote:
>
>> Are you going to force it to use some C++11 on up feature in its code
>> so that it no longer compiles at the C++03 level, even when it has no
>> use for any C++11 on up feature anywhere in its implementation ?
>
> He wasn't suggesting anything like that. His point is simply that if a
> library is heavily depended upon, the author's decision to drop C++03
> support affects all downstream libraries, which by virtue of having this
> dependency will also lose C++03 support even if they themselves use no
> non-C++03 features.
>
> Consequently, said author would be reluctant to break C++03
> compatibility because it would affect more than just one library.
>
> But if we officially "drop C++03 support" he'll be freer to do so.

Only if "drop C++03 support" actually means something on a practical
level rather than just verbiage.


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