|
Boost : |
Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-02-18 21:36:59
On 2/18/2018 3:44 PM, Robert Ramey via Boost wrote:
> On 2/18/18 2:12 AM, Olaf van der Spek via Boost wrote:
>> On Sat, Feb 17, 2018 at 7:55 PM, Robert Ramey via Boost
>> <boost_at_[hidden]> wrote:
>>> What does "drop support" mean?
>>>
>>> a) libraries should fail to compile with C++03? Any library which
>>> does so
>>> should be considered "broken" in some sense?
>>>
>>> b) libraries should/must be implemented in C++11(+?)? Any library which
>>> isn't should/would be considered "broken"
>>>
>>> c) libraries should/must be compilable with C++11(+?)? Any libraries
>>> which
>>> don't would be considered broken.
>>
>> None of the above, but you already knew that, didn't you?
>
> No. It's a serious question. The phrase "drop support" is confusing to
> me in the context of Boost.
Exactly ! There has been lots of noise about "dropping c++03" support
but very little substance which explains what it means. As you and
others have mentioned, as long as a library, written for whatever
standard(s) it has specified in its doc, builds and works properly with
the latest C++ standards, why should anyone want to legislate against it
as far as what C++ features it uses are does not. One can encourage the
use of later C++ constructs and C++ compilation modes that may make it
easier to create an effective library, but it is wrong to force on a
library developer particular constructs for which he has no use.
I understand that some programmers may want library interfaces to
support C++11 versions of std libraries rather than the equivalent Boost
versions of those same libraries, because people compiling in C++11 mode
or above may be otherwise using the std versions of those libraries in
their code. I wrote CXXD as an attempt to solve that problem. But that
choice is up to the library developer and can't be legislated as a demand.
>
> Robert Ramey.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk