From: Bronek Kozicki (brok_at_[hidden])
Date: 2006-06-18 06:32:26
>>> What interface would you consider appropriate? Right now
>>> bjam ... define=_SECURE_SCL=0 ...
>>> works with BBv2. Do you want some kind of more descriptive syntax?
this is *almost* fine. The problem is that when library is linked with program
that does have this macro defined as _SECURE_SCL=1 ...
> From MSDN:
> "_SECURE_SCL
> If defined as 1, unsafe iterator use causes a runtime error. If defined
> as 0, checked iterators are disabled. The exact behavior of the runtime
> error depends on the value of _SECURE_SCL_THROWS. The default value for
> _SECURE_SCL is 1, meaning checked iterators are enabled by default."
... there will be multiple *different* definitions of iterators, which clearly
is ODR violation. This will cause all kind of nasty problems. But we already
have (very) simple tool to protect against ODR violations - different names
for libraries built with different options.
Thus I suggest to extend msvc-8.0 toolset with definition of this feature AND
library filename tag (we could have "i - checked iterators" similar to "s -
static link to runtime; g - debug runtime" etc.) AND augment autolinking
feature to take _SECURE_SCL into account when defining library name to link
with. I also want to point out that msvc-8.0 is not the only toolset that
would benefit from it, as IIRC there are at least two implementations of
standard C++ library that provide some flavour (in very general meaning) of
"checked" iterators - Dinkumware and STLPort. It means that
"checked_iterators" feature does not have to be specific to msvc-8.0
B.