I was trying to figure out how Boost handles deprecated classes, functions, headers, macros, etc. The following command finds several approaches within boost $ grep -ir deprecate boost-1.44.0/include/boost/* \ | grep -v "This header is deprecated" \ | grep -v BOOST_SPIRIT_DEPRECATED Surprisingly, none of these use compiler support. e.g. http://stackoverflow.com/questions/295120/c-mark-as-deprecated Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean? Thanks, Daniel
AMDG On 03/17/2011 08:51 AM, Daniel Herring wrote:
I was trying to figure out how Boost handles deprecated classes, functions, headers, macros, etc.
The following command finds several approaches within boost $ grep -ir deprecate boost-1.44.0/include/boost/* \ | grep -v "This header is deprecated" \ | grep -v BOOST_SPIRIT_DEPRECATED
Surprisingly, none of these use compiler support. e.g. http://stackoverflow.com/questions/295120/c-mark-as-deprecated
Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean?
There is no standard for doing this. Right now, it's whatever each library author decides to do. In Christ, Steven Watanabe
Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean?
There is no standard for doing this. Right now, it's whatever each library author decides to do.
If someone would like to volunteer to document best practice on the Wiki though that would be great ;-) John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, March 17, 2011 4:47 PM To: boost@lists.boost.org Subject: Re: [boost] Deprecation guidelines?
Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean?
There is no standard for doing this. Right now, it's whatever each library author decides to do.
If someone would like to volunteer to document best practice on the Wiki though that would be great ;-)
OK - I hope this might be within my skill set? Shall I start with a new thread asking for views? Or shall I dream up and post up a 'strawman' proposal for others to shoot at? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
On Behalf Of John Maddock
Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean?
There is no standard for doing this. Right now, it's whatever each library author decides to do.
If someone would like to volunteer to document best practice on the Wiki though that would be great ;-)
OK - I hope this might be within my skill set?
Shall I start with a new thread asking for views?
Or shall I dream up and post up a 'strawman' proposal for others to shoot at?
When it comes to marking functions as deprecated, here's what I know: GCC: __attribute__((__deprecated__)) MSVC: __declspec(deprecated) GCC allows the attribute to precede the return type or after the argument list. MSVC requires the declspec to precede the return type. Therefore, I use a macro that is defined to one of the forgoing decorators, depending upon the compiler, and document that it must precede the return type for portability. It would be reasonable for the macro to take one parameter: the return type. It would then produce the decorator followed by the return type and force its use in the portable location. I haven't done that, but it is worth considering. Therefore: #if defined __GNUC__ # define BOOST_DEPRECATED(_return_type) \ __attribute__((__deprecated__)) _return_type #elif defined _MSC_VER # define BOOST_DEPRECATED(_return_type) \ __declspace(deprecated) _return_type #endif or just: #if defined __GNUC__ # define BOOST_DEPRECATED __attribute__((__deprecated__)) #elif defined _MSC_VER # define BOOST_DEPRECATED __declspace(deprecated) #endif _____ 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.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stewart, Robert Sent: Friday, March 18, 2011 10:56 AM To: boost@lists.boost.org Subject: Re: [boost] Deprecation guidelines?
Paul A. Bristow wrote:
On Behalf Of John Maddock
Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean?
There is no standard for doing this. Right now, it's whatever each library author decides to do.
If someone would like to volunteer to document best practice on the Wiki though that would be great ;-)
OK - I hope this might be within my skill set?
Shall I start with a new thread asking for views?
Or shall I dream up and post up a 'strawman' proposal for others to shoot at?
When it comes to marking functions as deprecated, here's what I know:
GCC: __attribute__((__deprecated__)) MSVC: __declspec(deprecated)
GCC allows the attribute to precede the return type or after the argument
list.
MSVC requires the declspec to precede the return type.
Therefore, I use a macro that is defined to one of the forgoing decorators, depending upon the compiler, and document that it must precede the return type for portability. It would be reasonable for the macro to take one parameter: the return type. It would then produce the decorator followed by the return type and force its use in the portable location. I haven't done that, but it is worth considering.
Therefore:
#if defined __GNUC__ # define BOOST_DEPRECATED(_return_type) \ __attribute__((__deprecated__)) _return_type #elif defined _MSC_VER # define BOOST_DEPRECATED(_return_type) \ __declspace(deprecated) _return_type #endif
or just:
#if defined __GNUC__ # define BOOST_DEPRECATED __attribute__((__deprecated__)) #elif defined _MSC_VER # define BOOST_DEPRECATED __declspace(deprecated) #endif
Perhaps this is not within my skill set after all? ;-) You clearly know much more that I do about the mechanics of this. So perhaps you'd like to take on the task? (I note the link to the https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#delet e_files examples is broken). Without the examples, I'm not sure it makes much sense (typos aside). But are there also the procedures for deprecating to consider? Should one or two Boost releases notice be given warning of future deprecation? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Paul A. Bristow-2 wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, March 17, 2011 4:47 PM To: boost@lists.boost.org Subject: Re: [boost] Deprecation guidelines?
Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean?
There is no standard for doing this. Right now, it's whatever each library author decides to do.
If someone would like to volunteer to document best practice on the Wiki though that would be great ;-)
OK - I hope this might be within my skill set?
Shall I start with a new thread asking for views?
Or shall I dream up and post up a 'strawman' proposal for others to shoot at?
I started long time ago this https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#Depre... Note that this doesn't takes care of the possibility provided by some compilers (gcc, msvc) to deprecated a single entity as at the time I wrote that I was not aware of the possibility. Deprecating a file seems simple. Just add a warning when the file is include #warning "This file is deprecated, please use another_file instead" But deprecating parts of a file is not supported by all compilers. So the idea is to use the file deprecation to deprecate parts of a file by including conditionally this part. Before // file.hpp ... ... After deprecation // file.hpp ... #if defined(BOOST_LIBX_DONT_INCLUDE_DEPRECATED_NAME) #include #endif ... // file with deprecated_part.ipp #warning "This file is deprecated, please use another_file instead" Note that the .ipp files don't protect themselves as include by a protected file. I don't know if we can build a macros that could allow us to simplify #if !defined(BOOST_LIBX_DONT_INCLUDE_DEPRECATED_NAME) ... #include #endif by BOOST_INCLUDE_DEPRECATED_PART(LIB, NAME) HTH, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Deprecation-guidelines-tp3384907p3386921.... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (6)
-
Daniel Herring -
John Maddock -
Paul A. Bristow -
Steven Watanabe -
Stewart, Robert -
Vicente Botet