vs2020编译器
A. VS编译器！
这个和c++没什么关系，所有c代码都可以直接移植，c++向下兼容c,代码不能用估计是编译器支持的c语言标准问题.
比如c99或者c11标准，如果是scanf不能用 需要改成s_scanf这样的错误，那就是c标准的问题了，
或者你编译器要是vs2010以上，十有八九就是编译器的问题了，修改你的函数吧，新的安全规则比旧的好，学新的没坏处
B. VS编译器
生成解决方案是相对于整个工程来讲的吧。
C. vs本地编译器一点就这样了是怎么回事
新建一个工程或者解决方案，工程类型选择Windows Console(控制台程序)，命名为ArrayTest（自定义）。然后选中工程ArrayTest，移除掉已经存在的ArrayTest.c或者ArrayTest.cpp，就是已经包含main函数的源文件。然后右键添加本地文件“二进制数组的使用.cpp”。编译即可。
D. vs code怎么 配置编译器
默认是GCC的编译器，CodeBlocks是不自带其他的编译器的，如果本机有安装列表中的其他编译器的话设置一下就可以用了。
设置编译器(rc.exe,link.exe,cl.exe)所在的文件夹
Program
Files
Additional
Paths
一般设置的路径和设置系统头文件的路径是一致的,比如:"
C:\Program
Files
(x86)\Microsoft
SDKs\Windows\v7.0A\Include
".说句题外话,着名按钮ID比如IDOK,IDCANCEL都是在以windows.h为首的头文件中被定义的.
E. 如图，为什么这个代码可以在VS2022里完美运行，可是在网站的编译器上却报错itoa
scanf_s是vs编译器提供的内置函数，与其他平台规定的scanf有冲突，故可以改为scanf，不要忘记让编译器忽略错误，在顶部加上#define _CRT_SECURE_NO_WARNINGS 1
F. 如何确定VS编译器版本
如何确定VS编译器版本
_MSC_VER是MSVC编译器的内置宏，定义了编译器的版本，_MSC_VER 值对应版本关系
MSVC++ 11.0 _MSC_VER = 1700 (Visual Studio 2012)
MSVC++ 10.0 _MSC_VER = 1600 (Visual Studio 2010)
MSVC++ 9.0 _MSC_VER = 1500 (Visual Studio 2008)
MSVC++ 8.0 _MSC_VER = 1400 (Visual Studio 2005)
MSVC++ 7.1 _MSC_VER = 1310 (Visual Studio 2003)
MSVC++ 7.0 _MSC_VER = 1300 (Visual Studio 2002)
MSVC++ 6.0 _MSC_VER = 1200
MSVC++ 5.0 _MSC_VER = 1100
example：
#if (_MSC_VER == 1300) //vc7
#import "acax16ENU.tlb" no_implementation raw_interfaces_only named_guids
#elif (_MSC_VER == 1200) //vc6
#import "acad.tlb" no_implementation raw_interfaces_only named_guids
#elif (_MSC_VER == 1400) //vc8
#import "acax17ENU.tlb" no_implementation raw_interfaces_only named_guids
#elif (_MSC_VER == 1500) //vc9
#import "acax18ENU.tlb" no_implementation raw_interfaces_only named_guids
#endif
在程序中加入_MSC_VER宏可以根据编译器版本让编译器选择性地编译一段程序。例如一个版本编译器产生的lib文件可能不能被另一个版
本的编译器调用，那么在开发应用程序的时候，在该程序的lib调用库中放入多个版本编译器产生的lib文件。在程序中加入_MSC_VER宏
，编译器就能够在调用的时根据其版本自动选择可以链接的lib库版本，如下所示。
#if _MSC_VER >= 1400 // for vc8, or vc9
#ifdef _DEBUG
#pragma comment( lib, "SomeLib-vc8-d.lib" )
#else if
#pragma comment( lib, "SomeLib-vc8-r.lib" )
#endif
#else if _MSC_VER >= 1310 // for vc71
#ifdef _DEBUG
#pragma comment( lib, "SomeLib-vc71-d.lib" )
#else if
#pragma comment( lib, "SomeLib-vc71-r.lib" )
#endif
#else if _MSC_VER >=1200 // for vc6
#ifdef _DEBUG
#pragma comment( lib, "SomeLib-vc6-d.lib" )
#else if
#pragma comment( lib, "SomeLib-vc6-r.lib" )
#endif
#endif
G. 如何在VS 编译器下 使用纯 C 语言编译器
C语言编译器都是独立运行并对c代码进行编译的，不像其他的类，库，项目那样可以在run time被调用或传参的。
H. 请问抛砖：VS的编译器到底做了什么
最近在学习并发程序设计，其中有个很重要的概念叫原子操作。网上有很多文章论述原子操作的，其中大部分文章不约而同的都使用到了这个例子++操作，来例证很多高级语言中的一条语句并非是不可拆分的原子操作。出于好奇，本人对++操作的原子性在VS2012下写了一个小程序以测试之，于是乎发现了下面的问题。//测试代码TEST(ConcurrenceTest, Atomic){ std::vector
<std::thread
threads; threads.push_back(std::thread(std::ref(thread))); threads.push_back(std::thread(std::ref(thread)));for(auto &
t : threads) { t.join(); } std::cout<<"total值："<<total<<
std::endl;}//线程voidthread(){for(inti =0; i <50000; i++) { total++; }}以上代码在release下结果都是100000，但在debug下会小于100000。
了解原子操作的朋友应该知道，debug下小于100000的结果应该属正常现象，因为++操作并不具有原子性，所有在并发的过程中会出现数据竞跑的现象。但是在release下所得到的结果却总是正确的（为了避免偶然性，本人用更多的线程，更大的数据类型同样做过测试，结果依然正确），这不得不怀疑编译器在release下对代码是否做过一定的优化？ 那么这种优化对于程序员来说是一件好事么？ 他会不会给一些对此了解不深的程序员造成一种正确的假象？本人是个初学者，写这些的目的只是抛个砖，以上的观点也仅是本人的一些小想法，希望有兴趣的朋友能来一起讨论。