Re: Console screen from spawn_process
On Thu, 2008-10-16 at 15:01 -0200, Paulo Flabiano Smorigo wrote: Hi Armin, Thanks for the fast reply! I compile the child process with the -mwindows parameter but the problem is that I need to communicate with the child using stdin and stdout by the method spawn_process_with_pipes but with -mwindows there is no stdin and stdout... There still is, you just don't see it. You can use stdin and stdout for communication even when there is no console window. So, there is no solution? I will have to understand the CreateProcess API ? I did the same thing in Glom. Maybe it's helpful: http://svn.gnome.org/viewvc/glom/trunk/glom/libglom/spawn_with_feedback.cc?view=markup Even if I have a system() call in the application this blank console appears... :( If the bug is WONTFIX means there will be no fix? Most likely not. Thanks... Paulo Flabiano Smorigo 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
