Windows的cmd运行编译器(cmd运行c/c++、python等)
目录
一、cmd.exe
二、cmd.exe运行编译器gcc.exe/g++.exe执行C/C++程序代码
三、gcc.exe与g++.exe的区别及其使用注意事项
1、文件格式问题
2、标准库问题
3、语法规范问题
4、extern "C"声明问题与重载函数(overloaded function)
四、cmd运行python解释器执行python程序代码
Windows的cmd运行编译器(cmd运行c/c++、python等)
前面我们已讲述了编译器(Compiler)及C/C++编译器安装(c+安装)中的一、五，已经提到任何一种编程语言，只要安装了这个编程语言的编译器(compiler)，在windows平台中可以使用cmd调用该编译器运行该编程语言的程序代码。下面我们以C/C++为例，讲述windows的cmd.exe 运行C/C++，其它编程语言类似，只是编译器不同。下面讲到的C/C++编译器是基于MinGW-w64编译器套件的。
一、cmd.exe简介
cmd是 Windows 系统的一种命令行操作工具，用户可以通过输入命令来完成各种各样的系统或程序操作。
我们使用win+r快捷键(也即Windows+R)打开运行窗口，输入cmd并确定，打开cmd命令提示符窗口，进入图1-1界面，右键cmd.exe顶部，可以在弹出的菜单中选择属性进行设置，可以设置颜色、字体等。
图1-1 cmd.exe
在使用cmd时，需要熟悉windows的一些CMD命令，下面列出几个cmd命令：
按ctr+c键：cmd.exe中退出正在执行的命令操作，即中断执行命令；
cls:清屏，清除cmd屏幕的历史输入；
cd: 全称change directory，进入某目录(改变目录)；
cd 目录名为进入当前路径里的某个目录；
cd 目录1\目录2\目录3为进入当前路径里的子路径(多级目录构成的子路径)；
cd..为返回到上一级目录；
cd\为返回到根目录盘符；
进入某个盘符，直接输入盘符即可，比如：输入D:则返回到根目录盘符D:\；
help:显示常用的命令(有些命令没显示出)，help 命令名，显示该命令名的基本使用。
CMD命令有很多，使用这些命令，能实现目录操作、网络操作、进程操作、服务操作运行操作、计算机控制操作等。
二、cmd.exe运行编译器gcc.exe/g++.exe执行C/C++程序代码
我们以C语言为例。依据C语言的语法规范，我们把c代码写到.txt文件中，并保存为.c后缀的文件，我们把下面代码保存到cr.txt记事本中。
#include
int main(void) {
int i;
for (i = 50; i <= 100; i++) {
if (i%5==0)
printf("%d ", i);
}
printf("\n");
} 然后改cr.txt的后缀变成cr.c。在改后缀前应该先打开文件夹并单击查看图标，勾选文件扩展名，如图2-1所示，这样显示扩展名才能成功修改后缀，否则，隐藏了扩展名，实际修改为cr.c.txt，运行时也就会提示No such file or directory，no input files。
图2-1 文件夹的文件扩展名
启动cmd命令行窗口，在窗口输入如图2-2所示的操作，即可实现cr.c程序的运行。
图2-2 cmd.exe运行c
第一行操作cd cj是进入文件夹cj，文件cr.c在该文件夹中；
第二行操作gcc cr.c为调用gcc.exe编译器编译cr.c文件，默认生成文件名为a.exe可执行文件；
第三行操作运行可执行文件a.exe；
第四行操作gcc cr.c -o cr.exe为调用gcc.exe编译器编译cr.c文件且生成指定文件名为cr.exe可执行文件，o相当于output的简写。
第五行操作运行可执行文件cr.exe。
注意，上面提到的生成文件的后缀在不同操作系统时不同的，在windows生成的是.exe后缀格式，在linux系统生成的是.out后缀格式。
在cmd.exe中编辑或查看cr.c文件，可以使用命令notepad cr.c，如图2-3所示以文本编辑器打开cr.c文件，打开后就可以编辑(写)代码了，保存即可。
图2-3 cmd文本编辑器打开cr.c
c++(c plus plus)是在c的基础上发展出来的面向对象编程，因而，c语言的代码规范通常也适合c++(也即C语言的代码通常都可以用于C++)，当然也有特殊情形，毕竟后者是面向对象的，是在前者基础上的扩充。上面的代码也可以保存为cr.cpp称为C++文件，后缀cpp也就是c plus plus的简写。我们也可以用gcc.exe来编译C++文件cr.cpp，下面图2-4运行了c++文件cr.cpp和c文件cr.c。
图2-4 cmd.exe运行c++
上面都是先把程序通过编译器gcc.exe编译成可执行文件.exe，然后执行该文件，即可实现程序的执行。一般来讲，使用gcc.exe或g++.exe编译器都可以编译c和c++，但它们也有一定差异。另外，c/c++运行程序，程序中通常有一个主函数main。
三、gcc.exe与g++.exe的区别及其使用注意事项
gcc.exe或g++.exe运行并不是单个文件就能运行，它们都有依赖项(依赖文件)，与依赖项构成编译功能。
1、文件格式问题
gcc.exe在编译时将.c文件视为 C 文件(C源码文件)，将.cpp文件视为C++文件(C++源码文件)，而g++.exe在编译时将 .c 和 .cpp 文件都视为C++文件(也即都作为.cpp文件)。
2、标准库问题
使用gcc.exe编译.cpp程序时，如果程序需要链接到C++标准库(C++ Standard Library)，gcc.exe默认情况下不会链接到C++标准库，需要使用选项参数(也称为flag)-lstdc++，让编译器gcc.exe能连接到c++标准库。而用g++.exe编译.cpp程序时能自动连接C++标准库。C++标准库(C++ Standard Library)是C++自带的库。
#include
using namespace std;
int main(){
int i=3;
cout << i << endl;
return 0;
}
上面代码用g++ main.cpp可以编译，但gcc main.cpp 运行提示undefined reference to `std::ostream::operator，因为gcc.exe编译器不能链接到C++标准库，需要增加选项参数-lstdc++才能链接到C++标准库，即使用命令gcc main.cpp -lstdc++可以链接到C++标准库并完成编译。
3、语法规范问题
c++(c plus plus)是在c的基础上发展出来的面向对象编程，因而，c语言的代码规范通常也适合c++(也即C语言的代码通常都可以用于C++)，但也有特殊情形，毕竟后者是面向对象的，是在前者基础上的扩充，两者的代码规范仍然有一定的差异，当出现这种情形时，g++.exe编译.c文件时，把.c文件当着C++文件进行编译，可能会报错。
#include
int main(void)
{
int new = 2;
printf("new=%d\n", new);
return new;
}
上面代码用gcc main.c可以运行，但用g++ main.c会报错，提示expected unqualified-id before 'new'，因为g++ main.c是把.c文件当着.cpp来编译，而new是 C++ 中是保留关键字，不能用作变量名称。
因此，在cmd.exe操作中，对于c程序，我们最好用gcc.exe，对于c++程序，我们最好用g++.exe。gcc.exe和g++.exe是两个独立的编译器，它们没有互相调用的关系。
4、extern "C"声明问题与重载函数(overloaded function)
在c++代码中出现 extern "C" void func(int x, int y)，表示调用c中的函数。
由于c++中支持重载函数(overloaded function，函数重载)，也即只要函数参数有差异(参数个数，参数类型)，函数名可以相同，这在c或python等语言中是不支持这种形式的，因为它们的编译特点不支持区分。在c++中编译后的函数符号(函数名称)与原函数名和函数参数有关，而在c中编译后的函数符号(函数名称)只与原函数名有关，比如：void func(int x, int y)在c++中我们可以理解为类似编译为_func_int_int名称，但void func(int x, int y)在c中编译为_func名称，实际如何编译与编译器有关。因此，在c++中只要参数有差异，同名的函数名编译后还是能区分的，但在c中即使参数不同，同名的函数编译后是不能区分的，同理python也是类似。
在c++增加extern "C"声明后，即extern "C" void func(int x, int y)，则是告诉c++编译器是调用c中的函数，而不是调用c++中的函数，但知道调用哪个func函数后，函数func的代码是按C还是按C++编译由编译器决定。
/*头文件func.h：*/
#include
void func(); //声明declare
/*C文件func.c：*/
#include "func.h"
void func()
{
printf("Hi!\n");
}/*C++文件main.cpp：*/
#include "func.h"
int main()
{
func();
return 0;
}
上述三个文件使用命令gcc main.cpp func.c -o kk编译会报错，提示undefined reference to `func()'，这是因为main.cpp是按C++编译，main.cpp中的func编译后的符号名称与原函数名和参数有关，而命令中的func.c编译后的符号名称只与原函数名有关，因而，两者是不能匹配的，因此会出现找不到函数名的错误。但用g++ main.cpp func.c -o kk命令是可行的，因为命令中main.cpp和func.c都是按.cpp编译，因而编译后的func的函数符号名称是能够匹配的。
我们在main.cpp中增加extern "C"声明，记为main1.cpp文件：
extern "C" void func();
int main()
{
func();
return 0;
}
注意，代码中需要去掉#include "func.h"语句，若保留，相当于先调用函数，后extern "C"声明，产生冲突，去掉该语句后，先声明，然后调用才符合逻辑关系。这时候使用命令gcc main1.cpp func.c -o kk是可行的，这时main.cpp中函数func调用已指定使用.c文件的，而命令func.c也是按C文件编译，因此，两者能匹配成功，调用关系可行。但命令g++ main1.cpp func.c -o kk会报错，提示undefined reference to `func()'，因为main.cpp中函数func调用已指定使用.c文件的，而命令中的func.c按.cpp编译，两者不能匹配，因此，调用关系不可行。
当然也可以不在c++中extern "C"声明，而在.h头文件中进行extern "C"声明，也可以达到这种效果。
我们把头文件func.h中的代码增加条件判断，修改后的文件仍记为func.h文件(也可以记为其它名称，但其它文件调用的这个头文件名称也要修改)：
#ifdef __cplusplus//两个下划线_
extern "C"{
#endif
#include
void func();
#ifdef __cplusplus
}
#endif
这种修改相当于增加条件判断语句，也就是判断为c++文件，则进行extern "C"声明，否则不声明。这时候使用命令gcc main.cpp func.c -o kk是可行的，这时main.cpp中函数func调用已指定使用.c文件的(头文件进行了判断选择)，而命令func.c也是按C文件编译(头文件进行了判断选择)，因此，两者能匹配成功，调用关系可行。命令g++ main.cpp func.c -o kk也是可行的，因为main.cpp中函数func调用已指定使用.c文件(头文件进行了判断选择)，而命令中的func.c的代码虽然是按.cpp编译，但也已指定调用.c文件(头文件进行了判断选择)，因此，两者能匹配成功，调用关系可行。
此外，更多的gcc操作选项(操作参数)可以参考https://gcc.gnu.org/对应版本的GCC的documentation说明。
四、cmd运行python解释器执行python程序代码
CMD.exe运行python程序代码，原理类似cmd运行c/c++。依据python语言的语法规范，我们把python代码写到.txt文件中，并保存为.py后缀的文件，我们把下面代码保存到pr.txt记事本中。
d0=100
class AA:
a1 = 2
def __init__(self, b1):
self.b1 = b1
def func(self):
ge1=d0+self.a1+self.b1
return ge1
print(AA(1).func())
然后改pr.txt的后缀变成pr.py(后缀修改注意事项同二、)。启动cmd命令窗口，在窗口输入如图4-1所示的操作，即可实现pr.py程序的运行。
图4-1 cmd.exe运行python
从广义上讲，python解释器也是一个编译器。CMD是调用python的解释器来运行python程序代码，当然，在调用运行前，需要先安装python，并在windows中配置好python环境变量，可以手动配置环境变量(设置方法参见https://blog.csdn.net/thefg/article/details/131916203
中的四、)，但在安装python时会提示勾选在windows系统中生成python环境变量。
同理，其他编程语言也可以类似在windows的cmd.exe命令行中运行。
编译器(Compiler)及C/C++编译器安装(c+安装)：
https://blog.csdn.net/thefg/article/details/131916203
2023年最新VS Code安装详细教程及vs code配置：
https://blog.csdn.net/thefg/article/details/131752996