On Jul 13, 2012, at 4:24 AM, Stewart, Robert wrote:
John Maddock wrote:
is there a way to don't include all the deprecated macros? Whoa - interesting question. I don't know of one.
However, all the deprecated macros are defined (I _believe_) in one place, in boost/config/suffix.hpp Making it so none of them are defined _should_ be straightforward.
Could I suggest to define all of them in a specific boost/config/deprecated.hpp file, so that we can add a deprecated warning when the file is included.
+1
I think it's too soon for that - as things stand you would basically be injecting that warning into every Boost header that includes boost/config.hpp.
Aren't there some that have been deprecated for long enough to get that sort of treatment?
Here's my proposal: There were a bunch of macros that were deprecated in 1.50. [ The BOOST_NO_0X* ones, replaced by BOOST_NO_CXX11_*, mostly ] As of last week, there are no uses of these macros on trunk. In the 1.51 release, there should be no uses of these macros. [ i.e, all the changes will get merged to release ] Immediately after the 1.51 release (or maybe 1.52 release, if people are worried), we should remove the old macros on the trunk. [ With an announcement on the MLs ] Then, merge to the release branch for the 1.52 release (or possibly 1.53).
IOW, create a mechanism for complaining about the use of old names and a policy for how long old names are defined without complaint, how long with complaint, and how long before they are removed.
Maybe an addition to the inspect tool?
If you can't ever remove the old names, then the set of names that can appear in Boost code grows uncomfortably large.
Indeed. And where is the incentive for maintainers to move to the new names? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki