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