Mat Marcus: ...
I'm surprised to hear you say this, as my experience is so different. To see whether this might be because things changed with in VC 9, I ran one of our benchmark suites to measure the _SECURE_SCL penalty for release builds.
A compiler that is good at removing the iterator abstraction penalty will show a bigger difference between _SECURE_SCL=0 and =1, so your results aren't surprising. I wasn't disputing that. My point was that if one habitually uses pointers to traverse performance-sensitive vectors, then _SECURE_SCL only affects the non-performance-sensitive vector accesses, where one presumably doesn't mind the extra safety. (One reason for avoiding vector::iterator is fear of abstraction penalty that may now be obsolete and unfounded; another legitimate one, however, is that pointers imply contiguous storage, and algorithms can take advantage of that.)
This strengthens my view that _SECURE_SCL for release builds as a misfeature, and I still am of the opinion that, at the least, boost build should disable 'secure' STL for release variations in the default case.
If we do that, we'll probably have to encode the _SECURE_SCL setting in the .lib names, to avoid mismatches.