Re: Using gtkmm with Visual C++ and _SECURE_SCL=0
Hallo Armin. Thanks a lot for your response. 1. In Visual-C++ the _SECURE_SCL-flag enables some special security checks within the STL-Container-templates. This means among others that the base-classes for all iterators get an additional member, a pointer to the referenced container. This pointer in turn is used to make additional runtime-checks, if an iterator is actually pointing into the container it is used with. To my opinion this is quite useful in debug-mode, but for release-versions, these checks can easily slow down the performance of programs by 10-20% and more, depending on the algorithms used. Since _SECURE_SCL=0 removes the additional pointer-member from the iterators, the binary-compatiblility with libraries in 'secure-mode' is broken. Anyway. MS has decided to make _SECURE_SCL=1 the default, for both release- and debug-mode. Which leads me to... 2. I totally agree with pre-built libraries compiled with the default-settings of a compiler. I did not really expect an additional customized build for my purposes. That's why I asked for a known workaround. It could be that sigc++ is the only source of problems, since it exchanges iterators in its interface (signal::connect()). If so, I would mail to their list, but I do not really know if there is other items somewhere in the libraries that are also affected and I cannot double-check the complete code... 3. I found the instructions on http://live.gnome.org/gtkmm/MSWindows/BuildingGtkmm . But I would rather like to rebuild exactly the libs and dlls, that come with the installer-packages. Where can I find out, which packages of libsigc++ ftp://ftp.gnome.org/pub/GNOME/sources/libsigc++, glibmm ftp://ftp.gnome.org/pub/GNOME/sources/glibmm, cairomm http://cairographics.org/releases/, pangomm ftp://ftp.gnome.org/pub/GNOME/sources/pangomm and gtkmm ftp://ftp.gnome.org/pub/GNOME/sources/gtkmm were exactly used for the installers? The idea is, if I rebuild exactly the same versions, I could just exchange the release-libs and -dlls of the standard gtkmm-installation and are finished. Maybe there is even a complete VisualC++-Workspace (sln) for all C++-libraries at once, that could be released along with the installers? Any aid in building a 'patch' for the installers would be welcome. regards Thomas Armin Burgmeier wrote: 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 ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using gtkmm with Visual C++ and _SECURE_SCL=0
On Mon, 2008-10-20 at 11:11 +0200, Thomas Frank wrote: Hallo Armin. Thanks a lot for your response. 1. In Visual-C++ the _SECURE_SCL-flag enables some special security checks within the STL-Container-templates. This means among others that the base-classes for all iterators get an additional member, a pointer to the referenced container. This pointer in turn is used to make additional runtime-checks, if an iterator is actually pointing into the container it is used with. To my opinion this is quite useful in debug-mode, but for release-versions, these checks can easily slow down the performance of programs by 10-20% and more, depending on the algorithms used. Since _SECURE_SCL=0 removes the additional pointer-member from the iterators, the binary-compatiblility with libraries in 'secure-mode' is broken. Anyway. MS has decided to make _SECURE_SCL=1 the default, for both release- and debug-mode. Which leads me to... 2. I totally agree with pre-built libraries compiled with the default-settings of a compiler. I did not really expect an additional customized build for my purposes. That's why I asked for a known workaround. It could be that sigc++ is the only source of problems, since it exchanges iterators in its interface (signal::connect()). If so, I would mail to their list, but I do not really know if there is other items somewhere in the libraries that are also affected and I cannot double-check the complete code... 3. I found the instructions on http://live.gnome.org/gtkmm/MSWindows/BuildingGtkmm . But I would rather like to rebuild exactly the libs and dlls, that come with the installer-packages. Where can I find out, which packages of libsigc++, glibmm, cairomm, pangomm and gtkmm were exactly used for the installers? The DLLs have a version resource that shows the Version in the Windows explorer when viewing the DLLs, or by choosing Properties on a DLL. The only exception to this is libsigc++ which has been built from SVN since there was no release with updated MSVC project files when the latest installer was built. The idea is, if I rebuild exactly the same versions, I could just exchange the release-libs and -dlls of the standard gtkmm-installation and are finished. Maybe there is even a complete VisualC++-Workspace (sln) for all C ++-libraries at once, that could be released along with the installers? There is no such solution yet, but I think this is a good idea. The only problem that I see is that this solution file needs to know the path to the libsigc++, glibmm, cairomm etc. source code, even if we ship it with gtkmm. Any aid in building a 'patch' for the installers would be welcome. The installer sources are in gtkmm SVN in the win32_installer directory. Adding a file that the installer is supposed to install is easy (if this is what you are looking for), just look how it's done for the existing files in gtkmm-installer.nsi.in, and remember to also add it to the uninstaller. regards Thomas Armin ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Using gtkmm with Visual C++ and _SECURE_SCL=0
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
Re: Using gtkmm with Visual C++ and _SECURE_SCL=0
On Sat, 2008-10-18 at 16:30 +0200, Maik Beckmann wrote: 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. We're building glibmm using a wrapper script called cccl, which emulates UNIX like cc options with the Microsoft compiler. As far as I know it was an abandoned project, but one of my collegues updated it somewhat to work better. As far as I know it still needs some magic to actually produce working binaries, but that's the best option I had so far to compile the gtkmm stack with MSVC++. What does the binary installer use to compile gtkmm on Windows? Or you are using mingw? So if anyone is interested I'd be willing to publish our cccl fork, maybe it could be cleaned up a bit. It would make it way easier to compile Windows binaries by ourselves and in that case binary-incompatible MSVC options would not bite that much. -- Bazsi ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Using gtkmm with Visual C++ and _SECURE_SCL=0
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? thanks in advance and regards Thomas ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
