2008/10/18 Armin Burgmeier <[EMAIL PROTECTED]>: > 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 _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
