Re: [boost] Macro for BOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or use BOOST_NO_NUMERIC_LIMITS_LOWEST

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? 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. For example, newly renamed macros might be kept in config/suffix.hpp for four releases before moving them to config/deprecated.hpp. Then, names in deprecated.hpp might remain for two releases before removing them altogether.
Besides I don't see what harm defining the old names does?
If you can't ever remove the old names, then the set of names that can appear in Boost code grows uncomfortably large. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

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

On Jul 13, 2012, at 2:32 PM, Marshall Clow wrote:
There were a bunch of macros that were deprecated in 1.50. [ The BOOST_NO_0X* ones, replaced by BOOST_NO_CXX11_*, mostly ]
I have just checked in a new version of the inspect tool that checks for deprecated macros. Revision 79723. -- 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
participants (2)
-
Marshall Clow
-
Stewart, Robert