[also 1.33.1] VC8 deprecated library functions and impact on boost
Hi all, As some of you know, there is currently a discussion on the C++ lib reflector about the fact that MS decided to "deprecate" some C/C++ standard library functions on their own behalf. Regardless of whether this may be considered good or not: there is definitely an impact on the boost library because this "feature" causes a LOT of warnings in the boost code. FYI, the log of the stage build printed by the VC 8 final release can be read here: http://tinyurl.com/bhxd8 (just search for "deprecated"). Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions! Thoughts? Stefan P.S.: This warning is printed upon EVERY call of cl.exe: cl : Command line warning D9035 : option 'Og' has been deprecated and will be removed in a future release
FWIW - for the serialization library and tests I tweaked the relevent Jamfiles to include a command line switch to suppress these warnings. I"m sure it would be easy for someone to include this in the toolset *.jam files. Of course one would have to add an explanation in some rationale some where why boost does it this way - but I wouldn't think that would be a big problem Robert Ramey Stefan Slapeta wrote:
Hi all,
As some of you know, there is currently a discussion on the C++ lib reflector about the fact that MS decided to "deprecate" some C/C++ standard library functions on their own behalf.
Regardless of whether this may be considered good or not: there is definitely an impact on the boost library because this "feature" causes a LOT of warnings in the boost code. FYI, the log of the stage build printed by the VC 8 final release can be read here: http://tinyurl.com/bhxd8 (just search for "deprecated").
Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions!
Thoughts?
Stefan
P.S.: This warning is printed upon EVERY call of cl.exe:
cl : Command line warning D9035 : option 'Og' has been deprecated and will be removed in a future release
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, 1 Nov 2005 10:04:46 -0800, Robert Ramey wrote
FWIW - for the serialization library and tests I tweaked the relevent Jamfiles to include a command line switch to suppress these warnings. I"m sure it would be easy for someone to include this in the toolset *.jam files.
Of course this doesn't help if the user project includes a headers that does something inline with one of these calls. So for date-time I've wrapped up the 'deprecated calls in the following magic: #if (defined(_MSC_VER) && (_MSC_VER >= 1400)) #pragma warning(push) // preserve warning settings #pragma warning(disable : 4996) // disable deprecated localtime/gmtime warning on vc8 #endif // _MSC_VER >= 1400 //make the deprecated calls... #if (defined(_MSC_VER) && (_MSC_VER >= 1400)) #pragma warning(pop) // restore warnings to previous state #endif // _MSC_VER >= 1400 In date-time this is easy b/c all these calls are in about 20 lines of code. This solution silences both library and user build -- allowing the user to decide on whether they want the warnings for their own code. BTW, b/c builds on the HEAD with VC8 are really few and far between these days, this change hasn't appeared in the regression results yet...
Of course one would have to add an explanation in some rationale some where why boost does it this way - but I wouldn't think that would be a big problem
I suppose no matter the solution some documentation is in order. What do you think the odds are we can get Microsoft to write it ;-) Jeff
Jeff Garland wrote:
Of course this doesn't help if the user project includes a headers that does something inline with one of these calls. So for date-time I've wrapped up the 'deprecated calls in the following magic:
#if (defined(_MSC_VER) && (_MSC_VER >= 1400)) #pragma warning(push) // preserve warning settings #pragma warning(disable : 4996) // disable deprecated localtime/gmtime warning on vc8 #endif // _MSC_VER >= 1400
//make the deprecated calls...
#if (defined(_MSC_VER) && (_MSC_VER >= 1400)) #pragma warning(pop) // restore warnings to previous state #endif // _MSC_VER >= 1400
(sorry for long citation, but I want to keep your solution visible) I believe that this is best solution, that should be used in other places in boost where we see these warnings. My opinion is based on experience with very large project where each compiler warning is treated as compilation error. We do have warnings (sometimes even in std:: headers) , thus we disable specific warnings in specific places where we believe particular warning is harmless. This allows our code (several MLOC) to compile sucesfully. B.
Bronek Kozicki <brok@rubikon.pl> writes:
Jeff Garland wrote:
Of course this doesn't help if the user project includes a headers that does something inline with one of these calls. So for date-time I've wrapped up the 'deprecated calls in the following magic:
#if (defined(_MSC_VER) && (_MSC_VER >= 1400)) #pragma warning(push) // preserve warning settings #pragma warning(disable : 4996) // disable deprecated localtime/gmtime warning on vc8 #endif // _MSC_VER >= 1400
//make the deprecated calls...
#if (defined(_MSC_VER) && (_MSC_VER >= 1400)) #pragma warning(pop) // restore warnings to previous state #endif // _MSC_VER >= 1400
(sorry for long citation, but I want to keep your solution visible) I believe that this is best solution, that should be used in other places in boost where we see these warnings. My opinion is based on experience with very large project where each compiler warning is treated as compilation error. We do have warnings (sometimes even in std:: headers) , thus we disable specific warnings in specific places where we believe particular warning is harmless. This allows our code (several MLOC) to compile sucesfully.
If we want to go that way, we're going to need standard prefix and postfix headers that we #include in every Boost header: #ifndef INCLUDE-GUARD # define INCLUDE-GUARD # include <boost/config/prefix.hpp> ...your code here # include <boost/config/postfix.hpp> #endif // INCLUDE-GUARD Otherwise it will be totally unmaintainable. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
If we want to go that way, we're going to need standard prefix and postfix headers that we #include in every Boost header:
#ifndef INCLUDE-GUARD # define INCLUDE-GUARD # include <boost/config/prefix.hpp>
...your code here
# include <boost/config/postfix.hpp> #endif // INCLUDE-GUARD
Otherwise it will be totally unmaintainable.
That is what I was suggesting elsewhere in this thread and which I raised some time ago w.r.t. warnings in general (not just the deprecated APIs). The feeling from that is to provide a guide to handling these warnings and try to fix them in the code where possible without using #pragmas. The deprecated APIs are an independant issue, primarily because they enforce their policy by default and that they impact the standard library APIs. Personally I agree that having the compiler/library deprecating standard library APIs *by default* is a bad thing. Therefore, the deprecation prevention macro should go in Boost.Config (possibly with a *deprecate the APIs* macro to control this so you can turn it on if you want the deprecation checks). One potential problem with this is if the user has: #include <string> // deprecation turned on #include <boost/lexical_cast.hpp> // disabling deprecation has no effect // ... - Reece
David Abrahams <dave@boost-consulting.com> wrote:
I believe that this is best solution, that should be used in other places in boost where we see these warnings. My opinion is based on experience with very large project where each compiler warning is treated as compilation error. We do have warnings (sometimes even in std:: headers) , thus we disable specific warnings in specific places where we believe particular warning is harmless. This allows our code (several MLOC) to compile sucesfully.
If we want to go that way, we're going to need standard prefix and postfix headers that we #include in every Boost header:
#ifndef INCLUDE-GUARD # define INCLUDE-GUARD # include <boost/config/prefix.hpp>
...your code here
# include <boost/config/postfix.hpp> #endif // INCLUDE-GUARD
Otherwise it will be totally unmaintainable.
Hm, as this is actually workaround, why not apply it only locally? That is, just around the location inside header file that needs such special treatment? This is how we manage these problems in our codebase. B.
Bronek Kozicki <brok@rubikon.pl> wrote:
David Abrahams <dave@boost-consulting.com> wrote:
If we want to go that way, we're going to need standard prefix and postfix headers that we #include in every Boost header:
Otherwise it will be totally unmaintainable.
Hm, as this is actually workaround, why not apply it only locally?
After second thought, you are right. We (eg. me & my colleagues working on single large codebase that has nothing to do with boost except using it here and there) do apply such workarounds directly in the place of warning in our codebase, but we also have "advantage" of using only single compiler family (two versions of Visual C++). Maintenance of such local worarounds in boost is going to be nightmare, therefore "prefix headers" and "postfix headers" are much more sensible solution B.
Jeff Garland wrote:
In date-time this is easy b/c all these calls are in about 20 lines of code. This solution silences both library and user build -- allowing the user to decide on whether they want the warnings for their own code.
[...] I think this is a nice solution but I'm not sure whether 1.33.1 could be reopened for these changes which would affect many header files in boost. Stefan
Stefan Slapeta wrote:
Jeff Garland wrote:
In date-time this is easy b/c all these calls are in about 20 lines of code. This solution silences both library and user build -- allowing the user to decide on whether they want the warnings for their own code.
I think this is a nice solution but I'm not sure whether 1.33.1 could be reopened for these changes which would affect many header files in boost.
It would be a good idea to have a <boost/warnings/push.hpp> and <boost/warnings/pop.hpp> that would disable then restore common warnings that occur in boost. You would then have #include <boost/warnings/push.hpp> // ... #include <boost/warnings/pop.hpp> in the affected Boost headers. This would then keep all the warning logic in one place, offer a more elegant solution to the VC8 deprecated function problem and help users of Boost that enable all warnings and warnings as errors. This idea was proposed previously, but there wasn't enough interest in it. If this seems a reasomable solution, I could look at providing an implementation of these headers with support for the Microsoft, Borland and Metrowerks compilers as it can be annoying to do: #pragma warnings ( push ) #pragma warnings ( disable : nnnn ) // disable some warning #include <boost-header> #pragma warnings ( pop ) whenever I want to include a boost header. - Reece
It would be a good idea to have a <boost/warnings/push.hpp> and <boost/warnings/pop.hpp> that would disable then restore common warnings that occur in boost. You would then have
#include <boost/warnings/push.hpp> // ... #include <boost/warnings/pop.hpp>
in the affected Boost headers. This would then keep all the warning logic in one place, offer a more elegant solution to the VC8 deprecated function problem and help users of Boost that enable all warnings and warnings as errors.
This idea was proposed previously, but there wasn't enough interest in it. If this seems a reasomable solution, I could look at providing an implementation of these headers with support for the Microsoft, Borland and Metrowerks compilers as it can be annoying to do:
#pragma warnings ( push ) #pragma warnings ( disable : nnnn ) // disable some warning #include <boost-header> #pragma warnings ( pop )
whenever I want to include a boost header.
The trouble is, who decides which warnings get suppressed? Or to put it another way, every warning needs a number one human eyeball to look over the code and decide whether there is an issue or not. And yes, many of the common, annoying warnings do sometimes result in genuine fixes to code. I'm sure this will be true of the new "deprecated" warnings as well, even though they are truly annoying in many cases. So... while we clearly need a policy to deal with this, I would rather it was something that encouraged authors to "do the right thing", which probably varies case by case. It would also help if Microsoft had more documentation on this: anyone know how to mark a user defined iterator as "unbounded" for example? John.
John Maddock wrote:
The trouble is, who decides which warnings get suppressed?
True.
Or to put it another way, every warning needs a number one human eyeball to look over the code and decide whether there is an issue or not.
And yes, many of the common, annoying warnings do sometimes result in genuine fixes to code. I'm sure this will be true of the new "deprecated" warnings as well, even though they are truly annoying in many cases.
So... while we clearly need a policy to deal with this, I would rather it was something that encouraged authors to "do the right thing", which probably varies case by case. It would also help if Microsoft had more documentation on this: anyone know how to mark a user defined iterator as "unbounded" for example?
This would be a good thing to have in the wiki, where developers can work on a database of known warnings in different compilers and how to fix them. I am not sure on how to mark iterators as unbounded, but someone who does could add that to the wiki. It would also be a good idea to move this to official Boost document (a "best practices" guide). One problem with this: including standard headers. The Microsoft standard libraries don't compile cleanly on level 4 warnings :( (e.g. the dead code warning when including <vector> or <map>). - Reece
John Maddock wrote:
The trouble is, who decides which warnings get suppressed?
IMO a library like boost should IN GENERAL not supress any! [...]
And yes, many of the common, annoying warnings do sometimes result in genuine fixes to code. I'm sure this will be true of the new "deprecated" warnings as well, even though they are truly annoying in many cases.
Yes, yes and yes. However, my question was not if it's good to ignore warnings or not. I'm very concerned about releasing a new boost library (1.33.1) that prints a bunch of warnings _in it's own code_ on one of the most popular compilers which definitely communicate to the users that there could be something wrong with this code.
So... while we clearly need a policy to deal with this, I would rather it was something that encouraged authors to "do the right thing", which probably varies case by case. It would also help if Microsoft had more documentation on this: anyone know how to mark a user defined iterator as "unbounded" for example?
I'm sure boost needs a policy for that but I'm also sure there has to be done something _now_ for 1.33.1 regardless of whatever decision is made to eliminate these warnings properly somewhere in the future. Stefan
On Wed, 2 Nov 2005 10:49:29 -0000, John Maddock wrote
...snip...
This idea was proposed previously, but there wasn't enough interest in it. If this seems a reasomable solution, I could look at providing an implementation of these headers with support for the Microsoft, Borland and Metrowerks compilers as it can be annoying to do:
#pragma warnings ( push ) #pragma warnings ( disable : nnnn ) // disable some warning #include <boost-header> #pragma warnings ( pop )
whenever I want to include a boost header.
The trouble is, who decides which warnings get suppressed?
I think it's always the same warning for all the deprecated functions (4996). On a more practical note, it's tough for us to actually find these b/c we don't get warnings from the regression tests unless there's an error :-(
Or to put it another way, every warning needs a number one human eyeball to look over the code and decide whether there is an issue or not.
And yes, many of the common, annoying warnings do sometimes result in genuine fixes to code. I'm sure this will be true of the new "deprecated" warnings as well, even though they are truly annoying in many cases.
So... while we clearly need a policy to deal with this, I would
Actually I'm not so sure we need a policy. If we do nothing people will complain. When they complain, we point them to the vendor. Then the vendor might do something. Hmm, maybe I should pull my fix out of the HEAD...
rather it was something that encouraged authors to "do the right thing", which probably varies case by case. It would also help if Microsoft had more documentation on this: anyone know how to mark a user defined iterator as "unbounded" for example?
I agree about that the Microsoft docs could be better. I also think it is too early to tell what the best solution is on a Boost-wide basis -- as I say, I think we don't really know the scope of the problem since authors don't see warnings on passing tests -- I only know about the date-time problem b/c VC8 actually broke tests. If we have to write a policy for how library developers/users should deal with this warning -- well let's just say I'd like to see the vendor have significant input. One last thing. There is no way we should hold 1.33.1 for this issue. If the Boost developers decide we are going to 'fix' this issue we can do a 1.33.2 release to address it. There are critical fixes in 1.33.1 that have been waiting long enough already... Jeff
The trouble is, who decides which warnings get suppressed?
I think it's always the same warning for all the deprecated functions (4996). On a more practical note, it's tough for us to actually find these b/c we don't get warnings from the regression tests unless there's an error :-(
I know: that's one feature that's missing from the new regression test harness that we had in the old one. However, once VC8 express is available as a general download I expect more folks will be able to test on their own machines.
Or to put it another way, every warning needs a number one human eyeball to look over the code and decide whether there is an issue or not.
And yes, many of the common, annoying warnings do sometimes result in genuine fixes to code. I'm sure this will be true of the new "deprecated" warnings as well, even though they are truly annoying in many cases.
So... while we clearly need a policy to deal with this, I would
Actually I'm not so sure we need a policy. If we do nothing people will complain. When they complain, we point them to the vendor. Then the vendor might do something. Hmm, maybe I should pull my fix out of the HEAD...
Understood, folks are sure going to complain though...
rather it was something that encouraged authors to "do the right thing", which probably varies case by case. It would also help if Microsoft had more documentation on this: anyone know how to mark a user defined iterator as "unbounded" for example?
I agree about that the Microsoft docs could be better. I also think it is too early to tell what the best solution is on a Boost-wide basis -- as I say, I think we don't really know the scope of the problem since authors don't see warnings on passing tests -- I only know about the date-time problem b/c VC8 actually broke tests. If we have to write a policy for how library developers/users should deal with this warning -- well let's just say I'd like to see the vendor have significant input.
One last thing. There is no way we should hold 1.33.1 for this issue. If the Boost developers decide we are going to 'fix' this issue we can do a 1.33.2 release to address it. There are critical fixes in 1.33.1 that have been waiting long enough already...
Violent agreement all round then! John.
On Nov 2, 2005, at 3:57 AM, Stefan Slapeta wrote:
Jeff Garland wrote:
In date-time this is easy b/c all these calls are in about 20 lines of code. This solution silences both library and user build -- allowing the user to decide on whether they want the warnings for their own code.
[...]
I think this is a nice solution but I'm not sure whether 1.33.1 could be reopened for these changes which would affect many header files in boost.
1.33.1 cannot be reopened for these changes. We need to answer this with either the sledgehammer approach (defining _SCL_SECURE_NO_DEPRECATE in a config header) or with some documentation. Doug
At 07:45 2005-11-02, you wrote:
On Nov 2, 2005, at 3:57 AM, Stefan Slapeta wrote:
Jeff Garland wrote:
In date-time this is easy b/c all these calls are in about 20 lines of code. This solution silences both library and user build -- allowing the user to decide on whether they want the warnings for their own code.
[...]
I think this is a nice solution but I'm not sure whether 1.33.1 could be reopened for these changes which would affect many header files in boost.
1.33.1 cannot be reopened for these changes. We need to answer this with either the sledgehammer approach (defining _SCL_SECURE_NO_DEPRECATE in a config header) or with some documentation.
at the risk of being told to "shut up and don't 'dis' people in the community that are "promoting C++" (whatever the heck THAT means)", I think Microsoft has messed up on this one. Their "secure" replacements rely on the programmer adding a parameter to give them some "lengths" for destinations. I say #define _SCL_SECURE_NO_DEPRECATE and be done with it. _Maybe_ it's nice for new code, but for people upgrading old code it's strictly a PITA and in my opinion adds _nothing_ to the sarfety of a program.
Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On 11/1/05, Stefan Slapeta <stefan@slapeta.com> wrote:
[snip] Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions!
Thoughts?
I believe that it Microsoft's unilateral decision to define an "unsafe" subset of STL algorithms will cause programmer confusion, library incomapatibilities and sometimes to inefficient code. Boost should take a stand and disable this "feature" in 1.33.1, not just via bjam, but by setting _SCL_SECURE_NO_DEPRECATE in a boost config file. - Mat.
On 11/2/05, Mat Marcus <mat-lists@emarcus.org> wrote:
On 11/1/05, Stefan Slapeta <stefan@slapeta.com> wrote:
[snip] Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions!
Thoughts?
I believe that it Microsoft's unilateral decision to define an "unsafe" subset of STL algorithms will cause programmer confusion, library incomapatibilities and sometimes to inefficient code. Boost should take a stand and disable this "feature" in 1.33.1, not just via bjam, but by setting _SCL_SECURE_NO_DEPRECATE in a boost config file.
I think boost should stay free from politics and let the developer decide what is best for him.
- Mat. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Cory Nelson wrote:
On 11/2/05, Mat Marcus <mat-lists@emarcus.org> wrote:
On 11/1/05, Stefan Slapeta <stefan@slapeta.com> wrote:
[snip] Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions!
I believe that it Microsoft's unilateral decision to define an "unsafe" subset of STL algorithms will cause programmer confusion, library incomapatibilities and sometimes to inefficient code. Boost should take a stand and disable this "feature" in 1.33.1, not just via bjam, but by setting _SCL_SECURE_NO_DEPRECATE in a boost config file.
I think boost should stay free from politics and let the developer decide what is best for him.
Yes, but deprecating the APIs by default results in hundreds of warnings which is *very* distracting. I suggest we provide the inverse: that is we define _SCL_SECURE_NO_DEPRECATE unless BOOST_USE_SECURE_STDLIB is defined in Boost.Config. That way the developer still has control and it will disable the warnings by default and we don't need to do anything immediately with the affected Boost code. One problem with this solution is #include order. You need to include Boost.Config before the standard library. - Reece
Reece Dunn <msclrhd@hotmail.com> writes:
Cory Nelson wrote:
On 11/2/05, Mat Marcus <mat-lists@emarcus.org> wrote:
On 11/1/05, Stefan Slapeta <stefan@slapeta.com> wrote:
[snip] Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions!
I believe that it Microsoft's unilateral decision to define an "unsafe" subset of STL algorithms will cause programmer confusion, library incomapatibilities and sometimes to inefficient code. Boost should take a stand and disable this "feature" in 1.33.1, not just via bjam, but by setting _SCL_SECURE_NO_DEPRECATE in a boost config file.
I think boost should stay free from politics and let the developer decide what is best for him.
Yes, but deprecating the APIs by default results in hundreds of warnings which is *very* distracting.
I suggest we provide the inverse: that is we define _SCL_SECURE_NO_DEPRECATE unless BOOST_USE_SECURE_STDLIB is defined in Boost.Config. That way the developer still has control and it will disable the warnings by default and we don't need to do anything immediately with the affected Boost code.
One problem with this solution is #include order. You need to include Boost.Config before the standard library.
Can we disable the warning(s) with a pragma? If so, we could include the pragma in boost.config (conditional on BOOST_USE_SECURE_STDLIB, as suggested) Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Anthony Williams wrote:
Can we disable the warning(s) with a pragma? If so, we could include the pragma in boost.config (conditional on BOOST_USE_SECURE_STDLIB, as suggested)
The warnings can be disabled via pragmas on most (but not all) compilers, including MSVC and Borland. The problem is locality... you don't want to disable the warnings globally because users might be dependant on some of those warnings. For example, disabling the "dead code" warning in Boost.Config would hide this subtle error: bool foo( int bar ) { if( bar > 0 ) ; // oops! return true; return false; } Disabling and restoring the warnings via pragmas in the warnings/push.hpp and warnings.pop.hpp headers is the best option as it restricts the locality to the Boost headers and doesn't spill over into user headers. - Reece
"Reece Dunn" <msclrhd@hotmail.com> writes:
Anthony Williams wrote:
Can we disable the warning(s) with a pragma? If so, we could include the pragma in boost.config (conditional on BOOST_USE_SECURE_STDLIB, as suggested)
The warnings can be disabled via pragmas on most (but not all) compilers, including MSVC and Borland.
Only VC8 currently issues these "deprecation" warnings. I know they can be disabled through definining a preprocessor directive, but I do not know whether there is a pragma for disabling them.
The problem is locality... you don't want to disable the warnings globally because users might be dependant on some of those warnings. For example, disabling the "dead code" warning in Boost.Config would hide this subtle error:
bool foo( int bar ) { if( bar > 0 ) ; // oops! return true; return false; }
The warnings under consideration are the new warnings generated by VC8 about "deprecation" of certain standard library functions, because they are deemed "unsafe" by the VC compiler team. Since VC8 has only just been released, there should be almost no existing code relying on this behaviour. I agree that there are other warnings that we might rather didn't get triggered in boost code, for those cases where we know it's spurious, but which we don't want disabled for user code, such as your example.
Disabling and restoring the warnings via pragmas in the warnings/push.hpp and warnings.pop.hpp headers is the best option as it restricts the locality to the Boost headers and doesn't spill over into user headers.
This might be a sensible suggestion for both the new "deprecation" warnings, and other warnings generated by boost headers that are known to be spurious. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
On Wed, Nov 02, 2005 at 12:42:15AM -0600, Cory Nelson wrote:
On 11/2/05, Mat Marcus <mat-lists@emarcus.org> wrote:
On 11/1/05, Stefan Slapeta <stefan@slapeta.com> wrote:
[snip] Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions!
Thoughts?
I believe that it Microsoft's unilateral decision to define an "unsafe" subset of STL algorithms will cause programmer confusion, library incomapatibilities and sometimes to inefficient code. Boost should take a stand and disable this "feature" in 1.33.1, not just via bjam, but by setting _SCL_SECURE_NO_DEPRECATE in a boost config file.
I think boost should stay free from politics and let the developer decide what is best for him.
The decision to care about specific compiler versions is already the political decision here. The "support" for microsoft via Boost sucks resources, and makes the code more and more unreadable (already now I find using Boost as a *source code library* nearly impossible, due to the many compiler- and platform- switches). Isn't it the aim of writing good software to write it platform-independent? Now with all this madness (sorry, but I think that's exactly the clinical symptom here) about compiler warnings not only is the code modified due to a specific platform, even worse, it is written specifically for a specific compiler IN A SPECIFIC VERSION. I don't have any other word for this other than madness. You might say, mad is the world, and we have to live in it. So how to "let the developer decide" ?! First which "developer"? The Boost developer or the user of the Boost libraries?! Several times I wondered whether I should / could contribute something to Boost, but yet it didn't happen, and I fear it won't happen in the future, and perhaps the main reason is that I love the beauty of un-obfuscated code, sheer pure standard C++ and nothing else. The compiler should be just a tool, but, especially if it comes from microsoft, then it seems to be an object of adoration, a golden calve, with developers dancing around it and chanting about the specifics of its erratic behaviour. So it seems to me that if I would like to contribute something to Boost, then I had to knuckle down to this cult, and, as you might guess when reading this, I don't like this so much (and I have also many other things to do). So from the perspective of future Boost libraries, at least in my case the "good heart for broken compiler"-policy is counterproductive. (By the way, actually I don't know whether for example it is possible to submit a library to Boost which doesn't care about broken compilers, and then flags those all as unusable?) And also from the perspective of a Boost user, the usability of Boost is much reduced by not being able to read the source code. I would like to have the option of getting the "pure Boost library", without any compiler-adorations. Unfortunately, this is likely not feasible; the C++ standard ignores the whole compiler business, but "active libraries" need to address this issue. In the best of all worlds, one would have different "views" on the Boost library collection, showing us exactly what we want to see. So what is the practical point of all of this? I just wanted to raise my voice, saying that the assimilation of Boost to microsoft policies (which, by the definition of business, are driven by profit considerations, and it seems reasonable to believe that a good dose of client-lock-in is anticipated, using "security" as the bait) will likely reduce the value of Boost for me. Oliver
On Nov 2, 2005, at 11:35 AM, Oliver Kullmann wrote:
(By the way, actually I don't know whether for example it is possible to submit a library to Boost which doesn't care about broken compilers, and then flags those all as unusable?)
That depends on how high you set the bar. There are quite a few compilers out there that are reasonably conformant to the standard (e.g., GCC 3.4+, MSVC 7.1+, CodeWarrior 9+, anything EDG-2.45+-based), and those should be supported. At this point, no library would get rejected because it doesn't support the old, broken compilers out there. Doug
participants (14)
-
Anthony Williams -
Bronek Kozicki -
Cory Nelson -
David Abrahams -
Doug Gregor -
Douglas Gregor -
Jeff Garland -
John Maddock -
Mat Marcus -
Oliver Kullmann -
Reece Dunn -
Robert Ramey -
Stefan Slapeta -
Victor A. Wagner Jr.