Using gtkmm with Visual C++ and _SECURE_SCL=0
- From: "Maik Beckmann" <beckmann maik googlemail com>
- To: gtkmm-list gnome org
- Subject: Using gtkmm with Visual C++ and _SECURE_SCL=0
- Date: Sat, 18 Oct 2008 16:30:50 +0200
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
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.
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
> 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 , I don't see an easy
> workaround for your problem without rebuilding the involved C++
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.
] [Thread Prev