|
Boost : |
From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-02 02:18:45
Cory Nelson wrote:
> On 11/2/05, Mat Marcus <mat-lists_at_[hidden]> wrote:
>>On 11/1/05, Stefan Slapeta <stefan_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk