Re: [boost] [also 1.33.1] VC8 deprecated library functions and impact on boost

From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2005-11-02 11:35:59

On Wed, Nov 02, 2005 at 12:42:15AM -0600, 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!
> > >
> > > 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