Re: _SECURE_SCL and linking libraries
wickedmuc wrote:
I'm upgrading a visual studio v6 workspace with some libraries that link
together to form an exe. MS suggest using the following
_SCL_SECURE_NO_DEPRECATE
_CRT_SECURE_NO_DEPRECATE
_CRT_NONSTDC_NO_DEPRECATE
_SECURE_SCL=0
for various reasons. If we use these macros in the library projects but
NOT in the exe projects, certain functions exported from the library
cannot be resolved by the linker in the exe.
[...]
So, my conclusion is that using the macros above affects the iterator's
function signature - in fact you can see the name mangling is subtly
different.
Disclaimer: I'm not too familiar with Dinkumware's specific implementation
but only with STLport's, though I guess the mechanisms are the same.
Now: in checked mode (_SECURE_SCL=1), a container knows about all its
iterators just a (IIRC) an iterator knows (via a pointer) from which
container it came. This allows use of iterators to be checked, e.g. that
you don't erase() an iterator from a different container.
Without the checks, the pointers aren't necessary and therefore not present,
so iterators have different interfaces with different settings of
_SECURE_SCL. In practice, that means that that you will have to provide
three (or four) different flavours of your library and select it according
to the _SECURE_SCL setting. The flavours would be Debug, SecureDebug,
Release and possibly SecureRelease, though I'd omit the last one.
Now, concerning the *_NO_DEPRECATE flags, those only control whether
dangerous functions like sprintf() are flagged as deprecated with compiler
warnings but shouldn't affect the generated code at all.
I've browsed the stl iterator src code and I can't see the macros listed
above affecting the iterator interface only some typedef'ing and runtime
checking...
Try stepping through the code or inspecting it at runtime, then you'll see
where things are happening. Expect insanity from macro madness though!
Uli