From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-11-02 04:22:33
Reece Dunn <msclrhd_at_[hidden]> writes:
> Cory Nelson wrote:
>> On 11/2/05, Mat Marcus <mat-lists_at_[hidden]> wrote:
>>>On 11/1/05, Stefan Slapeta <stefan_at_[hidden]> wrote:
>>>>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 Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk