Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Subject: Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-04 13:57:16

on Thu Sep 04 2008, "Mat Marcus" <mat-lists-AT-emarcus.org> wrote:

> On Thu, Sep 4, 2008 at 10:26 AM, Peter Dimov <pdimov_at_[hidden]> wrote:
>>>  Feature: <checked-iterators>
>>>      'on'            --> _SECURE_SCL=1
>>>      'off' (default) --> _SECURE_SCL=0
>>
>> I believe that the default should match the VC default, which is 1.
>>
>> This has no performance implications.
> [snip]
>
> I wouldn't say that it has *no* performance implications. Default
> settings often have large impact since many people don't take the time
> to learn the meaning of the various settings or tune them. In my
> experience, this is especially true with a complex tool like boost
> build. I expect this would result in a large number of executables
> that are needlessly slow, as is the case today. Vendors are not
> infallible--I believe that Microsoft made a mistake in defaulting the
> flag to 'on' for release builds, and that most users just assume that
> they are not paying a release price for this "security". We have an
> opportunity to employ to follow conventional best-practices with boost
> build defaults, and I still lean in favor of doing so.
>
> Of course there are dangers. Mixing and matching a component built
> with the IDE defaults with a component built with (different) boost
> build defaults is a recipe for disaster. 

Yes, but unless you go out of your way to disable auto-link, that can't
happen.  IIUC the only thing that will happen if we "ship" something
different from MS's default is that people using the default settings
will find they can't link to the binaries we've "shipped."

Maybe we need 3 builds:

  debug       - Matches typical vendor debug settings
  release     - Matches typical vendor release settings
  performance - Modifies release settings as necessary to get maximal performance

Whether it makes sense to "ship" all three of these, I suppose, depends
on what we mean by "ship." ;-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com