Re: [boost] [1.35] System: error_code.cpp #definesmacroswithoutchecking if already defined

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-05 20:53:57

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.