Suggested policy for dropping C++03 support in Boost libraries
We need a policy on phasing out C++03 support in Boost. C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times. Library authors and maintainers need to have an approved mechanism for dropping C++03 support in their libraries. The suggested way forward is to allow library authors to declare C++03 support deprecated via a notice in the documentation and a message issued at compile time, then be allowed to drop C++03 support no earlier than three Boost releases later. For instance, a library may declare C++03 support deprecated in Boost 1.73, and drop it no earlier than in Boost 1.76. More at https://pdimov.github.io/articles/phasing_out_cxx03.html.
On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost <boost@lists.boost.org> wrote:
We need a policy on phasing out C++03 support in Boost.
C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times.
+1 Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2. There may be some tooling that assumes v1, but really, isn't it time to use the major version number? -- Rob (Sent from my portable computation device.)
On 2019-11-08 00:42, Rob Stewart via Boost wrote:
On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost <boost@lists.boost.org> wrote:
We need a policy on phasing out C++03 support in Boost.
C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times.
+1
Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.
There may be some tooling that assumes v1, but really, isn't it time to use the major version number?
If we are going to start purposely dropping C++03 then I agree it's time for Boost 2.x. Though I'm not sure exactly what is being proposed. Are we (library maintainers) expected to actively drop C++03 and port our libraries to C++11+? What if we don't, for whatever reason?
Andrey Semashev wrote:
Though I'm not sure exactly what is being proposed. Are we (library maintainers) expected to actively drop C++03 and port our libraries to C++11+? What if we don't, for whatever reason?
What is being proposed is a sanctioned mechanism for library maintainers to drop C++03 in an orderly manner. Any library maintainer who wishes to maintain C++03 support is free to do so.
On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Though I'm not sure exactly what is being proposed. Are we (library maintainers) expected to actively drop C++03 and port our libraries to C++11+? What if we don't, for whatever reason?
What is being proposed is a sanctioned mechanism for library maintainers to drop C++03 in an orderly manner. Any library maintainer who wishes to maintain C++03 support is free to do so.
I don't see any difference between this and the current policy. As far as I know no library developer has ever been required to provide support for other than the current standard. Of course if I'm wrong about this, then feel free to make this policy explicit. I don't see it changing anything. Robert Ramey.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
What is being proposed is a sanctioned mechanism for library maintainers to drop C++03 in an orderly manner. Any library maintainer who wishes to maintain C++03 support is free to do so.
I don't see any difference between this and the current policy. As far as I know no library developer has ever been required to provide support for other than the current standard. Of course if I'm wrong about this, then feel free to make this policy explicit. I don't see it changing anything.
It's different in this way: Some Boost authors and contributors do feel constrained even if the official policy is to support only the latest/current standard from breaking either an existing Boost library that depends on that library that supports C++03, or breaking some software that uses that Boost library which must be compiled in C++03. For example, during a Boost beta release, reports might come in from users saying that X library no longer works for them because they need C++03 support. Or after a release, a Linux distribution package set fails to build, because they compile those programs in C++03 mode, and the Boost library stops compiling in C++03 mode. But while that might have been the case three - maybe even two - years ago, it isn't likely to be the case now. e.g. More compilers default standard mode is C++14 now, not C++03. i.e. Those of us who were worried about that outcome are less worried about it now. Glen
On 11/7/19 6:23 PM, Glen Fernandes via Boost wrote:
On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
What is being proposed is a sanctioned mechanism for library maintainers to drop C++03 in an orderly manner. Any library maintainer who wishes to maintain C++03 support is free to do so.
I don't see any difference between this and the current policy. As far as I know no library developer has ever been required to provide support for other than the current standard. Of course if I'm wrong about this, then feel free to make this policy explicit. I don't see it changing anything.
It's different in this way: Some Boost authors and contributors do feel constrained even if the official policy is to support only the latest/current standard from breaking either an existing Boost library that depends on that library that supports C++03, or breaking some software that uses that Boost library which must be compiled in C++03.
Hmmm this is a big surprise to me. My understanding has been that anything that would compile with C++03 would be compilable with all the subsequent versions of C++. That is the guarantee of backward compatibility. There has been talk about breaking this guarantee, but as far as I know it is still guaranteed.
For example, during a Boost beta release, reports might come in from users saying that X library no longer works for them because they need C++03 support. Or after a release, a Linux distribution package set fails to build, because they compile those programs in C++03 mode, and the Boost library stops compiling in C++03 mode.
But while that might have been the case three - maybe even two - years ago, it isn't likely to be the case now. e.g. More compilers default standard mode is C++14 now, not C++03. i.e. Those of us who were worried about that outcome are less worried about it now.
Hmm - for example, the boost serialization library is C++03 compatible, but it compiles with std=C++14 just fine - exactly as guaranteed by the standard. Soooooo - you can make whatever policy you want, but I don't see how it would the maintainer of the serialization library in any way. Robert Ramey
Glen
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Nov 7, 2019, 10:13 PM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
What is being proposed is a sanctioned mechanism for library
On 11/7/19 6:23 PM, Glen Fernandes via Boost wrote: maintainers
to drop C++03 in an orderly manner. Any library maintainer who wishes to maintain C++03 support is free to do so.
I don't see any difference between this and the current policy. As far as I know no library developer has ever been required to provide support for other than the current standard. Of course if I'm wrong about this, then feel free to make this policy explicit. I don't see it changing anything.
It's different in this way: Some Boost authors and contributors do feel constrained even if the official policy is to support only the latest/current standard from breaking either an existing Boost library that depends on that library that supports C++03, or breaking some software that uses that Boost library which must be compiled in C++03.
Hmmm this is a big surprise to me. My understanding has been that anything that would compile with C++03 would be compilable with all the subsequent versions of C++. That is the guarantee of backward compatibility. There has been talk about breaking this guarantee, but as far as I know it is still guaranteed.
For example, during a Boost beta release, reports might come in from users saying that X library no longer works for them because they need C++03 support. Or after a release, a Linux distribution package set fails to build, because they compile those programs in C++03 mode, and the Boost library stops compiling in C++03 mode.
But while that might have been the case three - maybe even two - years ago, it isn't likely to be the case now. e.g. More compilers default standard mode is C++14 now, not C++03. i.e. Those of us who were worried about that outcome are less worried about it now.
Hmm - for example, the boost serialization library is C++03 compatible, but it compiles with std=C++14 just fine - exactly as guaranteed by the standard.
Soooooo - you can make whatever policy you want, but I don't see how it would the maintainer of the serialization library in any way.
Robert Ramey
Glen
This was already debated before. No need to rehash it. Maintainers are already empowered to drop C++03 support. They can start by updating their readme and docs and stop running their C++03 CI jobs. - Jim
On 11/7/19 7:24 PM, James E. King III via Boost wrote:
This was already debated before. No need to rehash it. Maintainers are already empowered to drop C++03 support.
Right. they've been empowered to do this for 20 years. How does this change anything
They can start by updating their readme and docs and stop running their C++03 CI jobs.
Is it being proposed that they should be required to do this?. If not what are library maintainers expected to do differently? Robert Ramey
On 11/7/19 21:37, Robert Ramey via Boost wrote:
On 11/7/19 7:24 PM, James E. King III via Boost wrote:
This was already debated before. No need to rehash it. Maintainers are already empowered to drop C++03 support.
Right. they've been empowered to do this for 20 years. How does this change anything
It would seem that you are not the audience. Some authors apparently feel conflict in dropping C++03 support. A clearly documented policy of how to do this provides no harm and may cause authors/maintainers to deprecate old compiler support.
They can start by updating their readme and docs and stop running their C++03 CI jobs.
Is it being proposed that they should be required to do this?. If not what are library maintainers expected to do differently?
The proposal does not say this. The proposal provides the minimum steps that should be taken when a library maintainer is going to deprecate C++03 support. It seems very reasonable to have a written policy. I fully understand that some maintainers will feel no additional power from such a declaration; however, it does allow a uniform process to be pointed to. michael -- Michael Caisse Ciere Consulting ciere.com
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Michael Caisse via Boost Sent: 8 November 2019 07:18 To: boost@lists.boost.org Cc: Michael Caisse <mcaisse-lists@ciere.com> Subject: Re: [boost] Suggested policy for dropping C++03 support in Boost libraries
On 11/7/19 21:37, Robert Ramey via Boost wrote:
On 11/7/19 7:24 PM, James E. King III via Boost wrote:
This was already debated before. No need to rehash it. Maintainers are already empowered to drop C++03 support.
Right. they've been empowered to do this for 20 years. How does this change anything
It would seem that you are not the audience. Some authors apparently feel conflict in dropping C++03 support. A clearly documented policy of how to do this provides no harm and may cause authors/maintainers to deprecate old compiler support.
They can start by updating their readme and docs and stop running their C++03 CI jobs.
Is it being proposed that they should be required to do this?. If not what are library maintainers expected to do differently?
The proposal does not say this. The proposal provides the minimum steps that should be taken when a library maintainer is going to deprecate C++03 support.
It seems very reasonable to have a written policy. I fully understand that some maintainers will feel no additional power from such a declaration; however, it does allow a uniform process to be pointed to.
I agree that the existing policy of 20 years has not changed, (but is frequently misunderstood) but agree that a statement of policy could be helpful to users. The essence of Peter Dimov proposal https://pdimov.github.io/articles/phasing_out_cxx03.html is Suggested Policy is " A library author or maintainer will be allowed to announce that C++03 support in the library is deprecated. This announcement will take the following forms: A note in the documentation; An item in the release notes in the Boost release deprecating C++03 support; A message issued at compilation time if a library header is included in C++03 mode. The recommended form of the code issuing the message will be #include <boost/config.hpp> #include <boost/config/pragma_message.hpp> #if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) || defined(BOOST_NO_CXX11_RVALUE_REFERENCES) || defined(BOOST_NO_CXX11_HDR_MEMORY) BOOST_PRAGMA_MESSAGE("C++03 support is deprecated in Boost.Library 1.73 and will be removed in Boost.Library 1.76.") #endif with the condition of the #if directive adjusted appropriately to reflect the actual library requirements. At least three Boost releases must ship with a deprecation notice before support is dropped. " Previously, I think we had suggested only two releases (my preference). But that still seems a reasonable policy to me. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
On Fri, 8 Nov 2019 at 11:46, Paul A Bristow via Boost <boost@lists.boost.org> wrote:
The essence of Peter Dimov proposal https://pdimov.github.io/articles/phasing_out_cxx03.html is
Suggested Policy is " A library author or maintainer will be allowed to announce that C++03 support in the library is deprecated. This announcement will take the following forms: A note in the documentation; An item in the release notes in the Boost release deprecating C++03 support; A message issued at compilation time if a library header is included in C++03 mode. The recommended form of the code issuing the message will be #include <boost/config.hpp> #include <boost/config/pragma_message.hpp> #if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) || defined(BOOST_NO_CXX11_RVALUE_REFERENCES) || defined(BOOST_NO_CXX11_HDR_MEMORY) BOOST_PRAGMA_MESSAGE("C++03 support is deprecated in Boost.Library 1.73 and will be removed in Boost.Library 1.76.") #endif with the condition of the #if directive adjusted appropriately to reflect the actual library requirements. At least three Boost releases must ship with a deprecation notice before support is dropped. "
Let's assume this policy is accepted and implemented. What happens to renegade libraries that switched to C++11 without following some/any of the policy rules? For example, for GIL we just agreed internally within maintainers on switch to C++11, made the grand clean up and announced it in the release notes of Boost 1.68. I understand GIL's impact on the world is much less than many of other Boost libraries, so deprecating stuff in GIL may be even unnoticed to majority of Boost users. I'm just using the case as illustration to my question. p.s. An off-topic digression regarding Stefan's comment on 1.x version, well, it feels to me the `1` has entrenched so well into the Boost version number that it will stay there fixed until the end of its life and one day longer. If it ever changes, I will remain in shock for weeks ;-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2019-11-08 05:23, Glen Fernandes via Boost wrote:
On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
What is being proposed is a sanctioned mechanism for library maintainers to drop C++03 in an orderly manner. Any library maintainer who wishes to maintain C++03 support is free to do so.
I don't see any difference between this and the current policy. As far as I know no library developer has ever been required to provide support for other than the current standard. Of course if I'm wrong about this, then feel free to make this policy explicit. I don't see it changing anything.
It's different in this way: Some Boost authors and contributors do feel constrained even if the official policy is to support only the latest/current standard from breaking either an existing Boost library that depends on that library that supports C++03, or breaking some software that uses that Boost library which must be compiled in C++03.
For example, during a Boost beta release, reports might come in from users saying that X library no longer works for them because they need C++03 support. Or after a release, a Linux distribution package set fails to build, because they compile those programs in C++03 mode, and the Boost library stops compiling in C++03 mode.
This new proposal doesn't change anything. If a developer feels the obligation to support C++03 then it is an obligation before users, and no document initiated by Boost changes that. If a developer wishes to break that obligation and switch to C++11 then nothing prevented him to do that before. Sure, there would be some fallout, and there will be still after this proposal, so the preferred way to do that is to introduce vX+1 of the library. The only thing that could be changed is to forcefully upgrade all libraries to require C++11 and call it Boost 2.x, but I'm not sure if that would be useful. It would save each library from vX+1 hassle, at least.
On 2019-11-07 4:42 p.m., Rob Stewart via Boost wrote:
On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost <boost@lists.boost.org> wrote:
We need a policy on phasing out C++03 support in Boost.
C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times.
I thought library authors already were at liberty to require C++11 for their project. Are you suggesting that at this point in time all Boost libraries are supposed to be compatible with C++03 ?
Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.
There may be some tooling that assumes v1, but really, isn't it time to use the major version number?
I never understood our versioning (numbering) scheme. Given that we don't have any metric to measure the degree of (in-)compatibility between two distinct Boost releases, I always thought a simple monotonically increasing number would be the simplest. Let's just get rid of the "1." as a meaningless prefix, rather than invent some semantics around an illusion. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On November 7, 2019 5:18:28 PM EST, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
On 2019-11-07 4:42 p.m., Rob Stewart via Boost wrote:
On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost
<boost@lists.boost.org> wrote:
We need a policy on phasing out C++03 support in Boost.
I thought library authors already were at liberty to require C++11 for their project. Are you suggesting that at this point in time all Boost libraries are supposed to be compatible with C++03 ?
Peter is only documenting how to go about making the transition, but my expectation is that it will encourage authors and maintainers to make the transition.
Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.
There may be some tooling that assumes v1, but really, isn't it time to use the major version number?
I never understood our versioning (numbering) scheme. Given that we don't have any metric to measure the degree of (in-)compatibility between two distinct Boost releases, I always thought a simple monotonically increasing number would be the simplest. Let's just get rid of the "1." as a meaningless prefix, rather than invent some semantics around an illusion.
Some tools probably expected a major and minor version number. (Even if that was the case, it may no longer be so.) I suppose a v2 of Boost is illusory, so there's something to your idea. -- Rob (Sent from my portable computation device.)
On 07.11.19 22:42, Rob Stewart via Boost wrote:
Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.
I like this idea, for two reasons: 1. It lets us point to a definite last version of Boost to support C++03. Have a project that is stuck on C++03, but compiles with the current latest version of Boost? This is the specific version of Boost that you should use. 2. It leaves open the door for an emergency maintenance release to the C++03 line, in case any truly terrible bugs end up in that final 1.x release. -- Rainer Deyke (rainerd@eldwood.com)
On 11/8/19 3:44 AM, Rainer Deyke via Boost wrote:
On 07.11.19 22:42, Rob Stewart via Boost wrote:
Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously,
Hmmm - I'm not seeing this this. so that
would be signified clearly by a move to Boost v2.
So I'm not seeing that changing to 1 -> 2 would signify anything.
1. It lets us point to a definite last version of Boost to support C++03. Have a project that is stuck on C++03, but compiles with the current latest version of Boost? This is the specific version of Boost that you should use.
I don't see this either. I'm sure that any library which works with C++03 will work with C++20. In fact, given that C++ purports to support ABI compatibility, one should be able to compile each source file with different C++ version switches.
2. It leaves open the door for an emergency maintenance release to the C++03 line, in case any truly terrible bugs end up in that final 1.x release.
I think that door is already open. And of course, given the backward source and binary compatibility presumably guaranteed by C++ the whole effort is pointless and will confuse some people into thinking that these C++ features don't exist. Having said this, I would expect that someday in the future, C++ will drop and/or modify requirements for one or both of backward source compatibility and ABI stability due to the burden that these place on the evolution of the language. At that point, one might think of changing boost 1.xx to 2.xx. But that day is not yet here. So the concerns raised here are premature. Robert Ramey
On Fri, Nov 8, 2019 at 7:43 AM Robert Ramey wrote:
I don't see this either. I'm sure that any library which works with C++03 will work with C++20.
What about this scenario: The maintainer of Boost.TypeTraits decides to stop supporting C++03 and removes all C++03 workarounds and tests for the 1.75 release. Serialization depends on TypeTraits, so in 1.75, Serialization cannot be used by C++03 users. Right now, the release managers would probably hold up the 1.75 release because of failing tests for Serialization. (Or if not failing tests, then maybe they might hold up the release if users complain about the 1.75-beta's Serialization not working for them). The idea is the release managers would not hold up the release, for something like that. i.e. C++03 Serialization tests wouldn't matter to the release managers, only the C++11+ tests. User complaints about C++03 support wouldn't matter to the release managers, because they would reply saying that the standard mode is no longer officially supported. As the Boost Serialization author, you would be free to reimplement those TypeTraits inside Boostorg/Serialization to keep your C++03 users happy. But the TypeTraits maintainer would feel like he can make that change without any concerns. If you believe that this is the way of things today, then there's nothing to worry about. Everyone's already in agreement about the state that we want to be in. Glen
On 11/8/19 4:58 AM, Glen Fernandes via Boost wrote:
On Fri, Nov 8, 2019 at 7:43 AM Robert Ramey wrote:
I don't see this either. I'm sure that any library which works with C++03 will work with C++20.
What about this scenario: The maintainer of Boost.TypeTraits decides to stop supporting C++03 and removes all C++03 workarounds and tests for the 1.75 release. Serialization depends on TypeTraits, so in 1.75, Serialization cannot be used by C++03 users. Right now, the release managers would probably hold up the 1.75 release because of failing tests for Serialization. (Or if not failing tests, then maybe they might hold up the release if users complain about the 1.75-beta's Serialization not working for them).
Hmmmm - good observation. My understanding of the policy "one is only obligated to support the latest legal version of C++" would suggest that release managers would not currently be required to enforce or even test for compatibility with C++03. So maybe this idea isn't aimed at library authors but at release managers. That would make sense.
The idea is the release managers would not hold up the release, for something like that. i.e. C++03 Serialization tests wouldn't matter to the release managers, only the C++11+ tests. User complaints about C++03 support wouldn't matter to the release managers, because they would reply saying that the standard mode is no longer officially supported.
Correct - this makes sense to me.
As the Boost Serialization author, you would be free to reimplement those TypeTraits inside Boostorg/Serialization to keep your C++03 users happy. But the TypeTraits maintainer would feel like he can make that change without any concerns.
Agreed. The same situation that I'm on now.
If you believe that this is the way of things today, then there's nothing to worry about. Everyone's already in agreement about the state that we want to be in.
Sounds like we all agree that we're already where we want to be and that no change in policy is necessary. Perhaps the only thing needed is for release managers to announce that lack of C++03 compatibility is not grounds for holding up a release so C++03 won't be tested any more. Actually, I was not aware that C++03 was still being used to test anything. One interesting thing - The author of a library developed under C++03 doesn't really have much if any incentive to "upgrade" the implementation to a later version. And normally he doesn't because it doesn't add anything but more work. Older libraries like serialization were developed depending on boost as it existed at the time. So in practice, the scenario you cite above doesn't seem to present itself much. The only time I can see it happening is when the author/maintainer of an older library might re-implement using more up-to-date techniques. Perhaps the intention of this announcement is to provide cover for maintainers who want to do this. Robert Ramey
Glen
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 07.11.19 21:10, Peter Dimov via Boost wrote:
We need a policy on phasing out C++03 support in Boost.
C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times.
Library authors and maintainers need to have an approved mechanism for dropping C++03 support in their libraries.
The suggested way forward is to allow library authors to declare C++03 support deprecated via a notice in the documentation and a message issued at compile time, then be allowed to drop C++03 support no earlier than three Boost releases later.
For instance, a library may declare C++03 support deprecated in Boost 1.73, and drop it no earlier than in Boost 1.76.
More at https://pdimov.github.io/articles/phasing_out_cxx03.html.
Perfectly fine with me/boost.test. *BUT* I see a lot of internal dependencies on boost.test and it looks to me that some of those libraries are not actively maintained. Would the CMT be taking care of that? Should the libraries be moved to boost.lightweighttest or should it be a copy of boost.test inside each of the libraries? Thanks, Raffi
Raffi Enficiaud wrote:
Perfectly fine with me/boost.test. *BUT* I see a lot of internal dependencies on boost.test and it looks to me that some of those libraries are not actively maintained.
Would the CMT be taking care of that? Should the libraries be moved to boost.lightweighttest or should it be a copy of boost.test inside each of the libraries?
Good questions without easy answers. We've been slowly moving undermaintained libraries to LWT where feasible, but there's still much work to do. But the options, were Boost.Test to switch to requiring C++11, would in general be either move to LWT, or drop C++03 in the dependent libraries as well. It's a bit more subtle than that though, because some libraries only use parts of Boost.Test, such as uuid: <boost/test/included/test_exec_monitor.hpp> from <libs/uuid/test/test_generators.cpp> <boost/test/test_tools.hpp> from <libs/uuid/test/test_generators.cpp> or qvm: <boost/test/tools/floating_point_comparison.hpp> from <libs/qvm/test/test_qvm.hpp> or property_map: <boost/test/minimal.hpp> from <libs/property_map/test/compose_property_map_test.cpp> from <libs/property_map/test/dynamic_properties_test.cpp> from <libs/property_map/test/function_property_map_test.cpp> from <libs/property_map/test/transform_value_property_map_test.cpp> So the amount of work will depend on whether some of these headers will continue to be usable under C++03. A major goal of my suggested policy is actually to answer this question for library users; if the header starts issuing deprecation warnings, C++03 users of it would need to transition to something else. If it doesn't, they wouldn't need to.
participants (12)
-
Andrey Semashev -
Glen Fernandes -
James E. King III -
Mateusz Loskot -
Michael Caisse -
pbristow＠hetp.u-net.com -
Peter Dimov -
Raffi Enficiaud -
Rainer Deyke -
Rob Stewart -
Robert Ramey -
Stefan Seefeld