有没有现代编译器不支持旧标准的例子?

xcode 解君愁

vb6.0

MSVC++ 12.0 _MSC_VER == 1800 (Visual Studio 2013)
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
MSVC++ 6.0 _MSC_VER == 1200
MSVC++ 5.0 _MSC_VER == 1100

我没遇到，但是提供的编译宏难道不能兼容？

@across #3 感谢

@doraemon0711 #2 vb 是直接变成 vb.net 了吧 2333

有这个时间多写几行代码或者去把把妹

再补充一点背景, 老师让安装 vc6.0 或 vc2008, 我因此判断我们不会用到 vs2008 比 vc6.0 的特性
同学是用的是 vs2019
所以问题就是 vc6.0 的代码能在 vs2019 上运行吗?vs2019 上写出的仅使用 vc6.0 特性的代码能在老师的 vc6.0 上运行吗?

ps 为啥我的这个帖子没有 append 按钮

有可能的。
比如新的编译器默认开启了旧版编译器默认关闭的 option

@leoleoasd #7 vs2008 比 vc6.0 多的特性

@feather12315 #8 这是个问题

不都能 hello world 吗？

遇到过 VC 2005 有个项目文件在 VS 2012 上不识别，里面有 NT 4.0 什么的，从新项目里面复制一个过去覆盖就可以了。

VC 6.0 发布的时候还没有 C++ 标准，所以不存在支持旧标准的问题

旧的项目在新的 VS 上要作点调整是比较有可能的

vc6 可以认为只是 c++的一种方言。不兼容的地方多着呢。

正儿八经的 c/c++ 是没问题的。。。

如果是 ++i++++ 这种奇怪的东西。。。那你还是虚拟机装个 win7 装个 vc6.0 吧。学完考试结束一定要把这些忘掉。

说个题外话，这样的老师不是耽误人吗？浪费时间折腾根本不可能再用到的环境。也不确定学到的东西的兼容性、可持续性。

学校老师的古老 ppt 中针对 vc6 的 MFC 代码在 vs 下没法运行
还有老师古老 ppt 里的 8086 汇编代码也不能在 vs 下运行

@tigerfyj #17 是的🌚我就坚定的用 clang🌚

@ruimz #18 这门课是将 c 语法的 大一的入门的课 应该是不会涉及这些内容的吧

C++新标准有弃用旧标准的，具体有哪些不太清楚，印象中有一个是字符串字面量不能赋值给 char* 的变量。
C 语言的话 C11 弃用了不安全的 gets，需要用 gets_s 或者 fgets 替代。

不过显然不是所有代码都无法运行，小心写的话还是可以的。

有啥好讨论的，试一下不就得了
就算有肯定也是少数，稍微改一下就好

双方理由再充分也都是自己 YY

太新的 gcc 连旧的 gcc 都编译不了。。

VC/VS 啥时候成标准了 ...
首先，C++ 编译器的前端是逻辑很复杂的东西（特别还有一堆扩展），在维护的时候出 bug 不小心 break 掉之前的代码挺正常的，一般针对 C++ 编译器，有很多公开的和内部的 test suite 来尽量使这种事情不会发生，但是这显然并不是一个完全的保证。任何 C++ 编译器出 bug 都是很正常的事情，另外我不知道楼主听没听说过 bug-to-bug compatible 这个东西 ...

从更广义的角度讲，任何对于开发平台和依赖的迁移都应该评估可能造成的影响，这和标准不标准无关，任何语言的任何版本的编译器 /库更新都可能引入新的 bug

注意 C++ 这个语言的模式是 WG21 定标准，不同的 vendor 做实现，Bjarne 原来的实现早就不知道扔哪去了。你在不同的实现之间迁移的时候也会遇到类似的问题，同时还会遇到 extension 不兼容的问题（还会遇到 ABI 的问题 ...），包括看上去是同一个 extension，不同的 compiler 会有不同的实现。

还有一种模式是没有 spec，实现就是 de facto standard。TypeScript 貌似是这样。OCaml 这种尽管是偏学术的语言，但是好像还是没有 spec，并且可以有 breaking change ( https://github.com/gasche/ocaml-releases-change-explanation/wiki/4.05.0-changes-explanation)，一个其他语言用户见不到的奇观是
check.ocamllabs.io ——为了官方发布新版本的升级过程更平滑，有人专门做了一个网站来监控所有包在新版编译器上的构建状况，因为社区小，所以这个事情可行。但是仔细看其中大多数都是第三方库等周边生态导致的问题，编译器本身还是尽量保持稳定的。Haskell 虽然有个标准当摆设，但是谁都看得出 GHC 是 de facto standard，所以同理 ...（典型： https://gitlab.haskell.org/ghc/ghc/wikis/migration/7.10 ）。

LLVM 不算是用户直接接触的编译器，但是简单来说 LLVM IR 的兼容性就是随缘，尤其是对于非核心部分。OpenGL、OpenCL 和 SPIRV 等作为工业标准，标准是分版本发布的，各个 vendor 通过提 extension 的方式加私货，每个 extension 都有自己的 ID。实现上则用 版本号+extension 集合 的方式标识兼容性，Khronos 官方提供 Conformance Test Suite。我觉得这个做得是比 C++ 要更成熟一点的。

至于楼主的问题，我认为对于学生项目来讲，这个没有太大的问题。这里涉及到一个比较现实的问题是 MSVC 的编译器版本和开发环境版本是绑定的，你想用新的环境必须用新的编译器。这个不完全是个好事也不完全是个坏事。需要注意的是现在“开发环境和编译器版本绑定”已经是一个不限于微软的趋势了——越来越多的编程语言开始更多地在交互开发体验上发力，微软的 C# 本来做得就很优秀，但是后来通过开源的 Roslyn 更进了一步。C++ 社区则有 Clang 梦，不对，是 Clang 的伟大复兴，不对，应该叫 Clang 崛起 ... 总的来说是开发环境的工具越来越依赖于编译器自身的 API，这部分一般是没有兼容性保证的，并且挺容易 break 的。

一些优秀的 C++ 项目的编码规范里面规定的不仅仅有项目使用哪个 C++ ISO 标准开发，还有当前兼容的编译器**最小版本**，因为规定“使用 C++14 开发”之类的是没用的，你还得考虑编译器自身实现的问题

很多 C++ 项目本来就有跨平台的需求，这样所要面临的环境和工具链差异会更大，然而这些项目确实做到了。
你并不必需把你自己的项目也做成跨平台的，也并不必需使用标准 C++ 开发。但是我认为处理编译器和平台之间正常的兼容性问题是干活的程序员的必备能力之一，就像前端需要处理浏览器差异一样。

微软官方的解释： https://docs.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp

另外为什么没人黑一下 Python 呢？

你的做法是对的，有新的为什么用旧的，尤其是学习阶段。
难道是为了要学一堆现在不支持的“特性”吗？

@ReVanTis https://en.wikipedia.org/wiki/Appeal_to_novelty

以前写 C/C++喜欢指定 register、auto，后来编译器优化智能了，不需要手动。再后来 C++11 里 auto 的意义也不一样了。

vc6.0 创建的项目直接拿到 vs2019 去编译我印象里是会报错的，但是和编译器还真没啥关系

这门课划水就好啦，大学生还是要脱离课本 通过网络学习

@secondwtq 现在 VS 的 IDE 和编译器版本已经不是绑定的了，最新版本的 IDE 也可以装旧版本的工具集。

@mxalbert1996 没记错的话从 VS2015 才开始把 MSVC 分离的。曾经 Python 2.x 官方用的是 VC++ 2008 编译的，要编译安装第三方包的话需要装整个 VS 才有 MSVC，然后当时的 VS 还捆绑 C# 等功能（这个好像是 2017 才改掉的）。最后微软还专门给 Python 搞了个独立的 MSVC。