Using gtkmm with Visual C++ and _SECURE_SCL=0

["Maik Beckmann" <beckmann maik googlemail com>]

2008/10/18 Armin Burgmeier <armin arbur net>:
> On Fri, 2008-10-17 at 16:05 +0200, Thomas Frank wrote:
>> I searched for _SECURE_SCL in the archives but didn't get any results.
>> Has this ever been a topic?
>
> I didn't even know this option existed. Of course, we could enable this
> for the gtkmm runtime binaries, but then people need to set the same
> flag in their applications, which is just one step more that could go
> wrong. This is why I would rather avoid it.

_SECURE_SCL=1 is similar to libstdc++ Debug Mode
 - http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
<quote>
To use the libstdc++ debug mode, compile your application with the
compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes
and behavior of standard class templates such as std::vector, and
therefore you can only link code compiled with debug mode and code
compiled without debug mode if no instantiation of a container is
passed between the two translation units.
</quote>
which means binary incompatibility.

> We could also supply release binaries for both _SECURE_SCL=0 and
> _SECURE_SCL=1 (so we would have 6 different VC++ DLLs for each C++
> module). Again, I'm not quite happy with this considering the
> duplication it involves.
>
> How many applications do (need to) use the _SECURE_SCL=0 option? Is it
> kind of standard that it is used for release builds?

The VS default release build doesn't define _SECURE_SCL=0 by default,
AFAIK.  If you just compile the header files define _SECURE_SCL=1 by
default.

> If not, then I'm
> sorry, but I don't think it's reasonable to support all the different
> MSVC++ compiler settings that produce incompatible binaries. Just
> because there are too much of them.

My impressions is, that performance suffers when using std containers
and algorithm with _SECURE_SCL=1.  This might be a problem when i.e.
doing heavy duty text processing using the stl.

I for example was bitten by _SECURE_SCL=1 being the default :-).
Coding a ND-LookupTable, mingw-gcc-4.2.3 outperformed msvc-8.0 by a
factor of 2.5. A few month later I've read posting about this topic at
the boost-ML.  Rebuilding everything with _SECURE_SCL=0 made msvc
outperform gcc by a factor of 1.3.

> However, considering the rules posted on [1], I don't see an easy
> workaround for your problem without rebuilding the involved C++
> libraries.

It would be best to have generic build scripts for msvc.  Do the
autotools scripts work with CC=cl CXX=cl?

A workaround is using LoadLibrary to open _SECURE_SCL=0 compiled DSOs
containing performance critical code.

Best,
 -- Maik