Re: Using gtkmm with Visual C++ and _SECURE_SCL=0

[Armin Burgmeier <armin arbur net>]

On Fri, 2008-10-17 at 16:05 +0200, Thomas Frank wrote:
> Hallo.
> 
> I'm trying to introduce gtkmm (also) on windows as GUI to my non-GUI 
> libraries. As many other users of Visual C++ I need to #define 
> _SECURE_SCL=0 for the Release-versions of my libraries and any 
> application that uses them, to ensure a satisfying performance of the 
> STL-containers.
> 
> It turns out that "_SECURE_SCL=0" is incompatible with gtkmm from the 
> windows installer-package. All the release-versions of the libraries 
> here are compiled with the default (and slow) "_SECURE_SCL=1". This 
> would be no problem at all, if no public interfaces would instantiate or 
> exchange any STL-containers. But a sigc::signal for example, uses 
> std::list to store slots connected to signals and returns a 
> list::iterator with the connect()-function. This produces linker errors 
> when calling signal::connect() and compiling and linking an application 
> with "#define _SECURE_SCL=0" against gtkmm.
> 
> Has anybody ever ran into the same kind of problem(s) and found a 
> workaround other than recompiling gtkmm and all its dependant 
> C++-libraries?
> 
> I would like to enjoy the comfort and reliability of the installers both 
> for development and deployment. Using "_SECURE_SCL=1" with my own 
> source-code is definitely not an option, due to the absolutely 
> disappointing performance of the STL-containers in this mode.
> 
> 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.

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? 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.

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

Armin

 [1]
http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx#4617984