释放闭包(Releasing closures)

 我已经找到了你的问题的合理副本，但只找到了有关假情报答案的问题。 所以： 
 
 您看到的窗口不是命令解释器，它是与命令解释器使用的窗口类似的窗口。 这些称为控制台窗口 。 您的可执行文件会生成一个新的控制台窗口，因为它默认标记为需要一个，因此当它不在控制台窗口中运行时，Windows会为它创建一个新窗口。 
 
 标记是可执行文件标题中的一个值，称为Windows子系统 ，它确定Windows需要哪些基本服务，Windows应如何处理它。 默认情况下，MinGW工具（以及标准代码，Microsoft的工具）使用控制台子系统生成可执行文件。 通常，用于普通应用程序的唯一其他子系统是GUI子系统 ，它与控制台子系统类似，只是它表示不需要控制台窗口。 
 
 使用MinGW g ++，您可以使用半文档选项-mwindows来生成带有GUI子系统的可执行文件。 
 
 或者，您可以为链接器指定[1] ，例如-Wl,-subsystem,windows 。 
 
 显然，在NetBeans中，您必须修改项目属性中的编译器/链接器选项。 
 
 对于其他IDE，它可以像通过复选框或列表中选择子系统一样简单。 
 
 
 使用MinGW工具，您可以通过objdump实用程序检查子系统。 还有其他方式。 但是，使用objdump ： 
 
C:\my\forums\so\070>objdump -p a.exe | find /i "sub"
MajorSubsystemVersion   5
MinorSubsystemVersion   2
Subsystem               00000003        (Windows CUI)

C:\my\forums\so\070>g++ foo.cpp -mwindows

C:\my\forums\so\070>objdump -p a.exe | find /i "sub"
MajorSubsystemVersion   5
MinorSubsystemVersion   2
Subsystem               00000002        (Windows GUI)

C:\my\forums\so\070> _
 
 使用Microsoft的工具，您可以类似地使用其dumpbin实用程序。 
 
 还有许多其他标头转储实用程序，但[2] Windows本身不提供可执行文件的子系统。 
 
 
 使用Microsoft的工具，没有像g ++ -mwindows这样的编译器选项，但是有一个子系统链接器选项 /subsystem:windows 。 使用此标准和符合标准的代码，还必须将机器代码级别入口点指定为调用标准main 入口点 。 即，链接器选项/entry:mainCRTStartup 。 
 
C:\my\forums\so\070>cl std.cpp /Feb
std.cpp

C:\my\forums\so\070>dumpbin /headers b.exe | find /i "sub"
            6.00 subsystem version
               3 subsystem (Windows CUI)

C:\my\forums\so\070>cl std.cpp /Feb /link /subsystem:windows /entry:mainCRTStartup
std.cpp

C:\my\forums\so\070>dumpbin /headers b.exe | find /i "sub"
            6.00 subsystem version
               2 subsystem (Windows GUI)

C:\my\forums\so\070> _
 
 对于在命令行中工作，可以通过使用LINK环境变量稍微简化一下。 
 
 许多人宁愿使用微软的monstrosity main功能替换，称为WinMain 。 这指导Microsoft的链接器默认采用GUI子系统。 当人们希望从代码的角度来看没有意义，并且是不可移植的（特别是g ++接受函数但忽略其子系统提示）时，它使控制台子系统更难以构建[3] ，以及可怕的冗长。 
 
 
 [1] -mwindows选项通常会添加一些常用的Windows API库，而不是由简单的子系统链接器选项添加。 您可以通过-dumpspecs选项转储配置来检查哪些库。 
 [2]我在这里谈论现代Windows。 在20世纪90年代后期，Windows 9.x确实通过其（现已停止的）“快速查看”功能呈现子系统值。 对于可执行文件，显然只是从dumpbin提供了完整的文本输出。 
 [3]使用Microsoft的工具， WinMain主函数和指定的控制台子系统，默认情况下，链接器会抱怨main缺失。 然后一个修复是链接器选项/entry:WinMainCRTStartup 。 

I've looked for a reasonable duplicate of your question, but found only questions with disinformation answers. So:
 
The window you see is not the command interpreter, it's a window of the same kind as used by the command interpreter. These are called console windows. Your executable produces a new console window because it is by default marked as requiring one, so when it's not run from within a console window, Windows creates a new one for it.
 
The mark is a value in the executable file's header called its Windows subsystem, which determines what basic services it needs from Windows, how Windows should treat it. By default the MinGW tools (and also, for standard code, Microsoft's tools) produce an executable with the console subsystem. Usually the only other subsystem used for an ordinary application is the GUI subsystem, which is just like the console subsystem except that it says a console window is not required.
 
With MinGW g++ you can use the half-documented option -mwindows to produce an executable with GUI subsystem.
 
Alternatively you can specify [1]that to the linker, like -Wl,-subsystem,windows.
 
Apparently in NetBeans you have to modify the compiler/linker options in the project properties. 
 
With other IDEs it can be as simple as choosing the subsystem via a check-box or in a list.
 
 
With the MinGW tools you can check the subsystem via the objdump utility. And also in other ways. But, using objdump:
 
C:\my\forums\so\070>objdump -p a.exe | find /i "sub"
MajorSubsystemVersion   5
MinorSubsystemVersion   2
Subsystem               00000003        (Windows CUI)

C:\my\forums\so\070>g++ foo.cpp -mwindows

C:\my\forums\so\070>objdump -p a.exe | find /i "sub"
MajorSubsystemVersion   5
MinorSubsystemVersion   2
Subsystem               00000002        (Windows GUI)

C:\my\forums\so\070> _
 
With Microsoft's tools you can similarly use their dumpbin utility.
 
There are also many other header dump utilities, but [2]Windows does not itself present the subsystem of an executable.
 
 
With Microsoft's tools there is no compiler option like g++ -mwindows, but there is a subsystem linker option, /subsystem:windows. With this, and standard-conforming code, one must also specify the machine code level entry point as the one that calls standard main. Namely, linker option /entry:mainCRTStartup.
 
C:\my\forums\so\070>cl std.cpp /Feb
std.cpp

C:\my\forums\so\070>dumpbin /headers b.exe | find /i "sub"
            6.00 subsystem version
               3 subsystem (Windows CUI)

C:\my\forums\so\070>cl std.cpp /Feb /link /subsystem:windows /entry:mainCRTStartup
std.cpp

C:\my\forums\so\070>dumpbin /headers b.exe | find /i "sub"
            6.00 subsystem version
               2 subsystem (Windows GUI)

C:\my\forums\so\070> _
 
For working in the command line this can be a little simplified by using the LINK environment variable.
 
Many prefer to instead use Microsoft's monstrosity main function replacement, called WinMain. This guides Microsoft's linker to assume the GUI subsystem by default. It makes it more [3]difficult to build with console subsystem when one desires that, is meaningless from a code point of view, and is non-portable (in particular, g++ accepts the function but ignores its subsystem hinting), as well as horrendously verbose.
 
 
 [1] The -mwindows option typically adds some often used Windows API libraries, not added by the simple subsystem linker option. You can check which libraries by dumping a config via the -dumpspecs option.
 [2] I'm talking here about modern Windows. Windows 9.x, in the late 1990s, did present the subsystem values via its (now discontinued) “Quick View” functionality. Which, for an executable, apparently just presented the full textual output from dumpbin.
 [3] With Microsoft's tools, a WinMain main function, and console subsystem specified, by default the linker will complain about a missing main. One fix is then the linker option /entry:WinMainCRTStartup.