gcc 可以用旧的第三方库编译 C++17 代码吗?
Posted
技术标签:
【中文标题】gcc 可以用旧的第三方库编译 C++17 代码吗?【英文标题】:Can gcc compile C++17 code with older third party libraries? 【发布时间】:2017-07-27 16:10:48 【问题描述】:C++17 删除了 C++11 中已弃用的若干语言和库功能。
因此,一些完全使用 exception specifications 或 register
变量的旧库头文件无法编译。
gcc 是否有允许 C++17 代码包含已删除功能的标志?
【问题讨论】:
除了-std=c++11
,你的意思是?
你应该解决这些问题。你已经有六年这样做了。而且它不像register
或异常规范实际上在做任何事情......
auto_ptr
与 Wandbox 上的 -std=c++1z
一起编译:wandbox.org/permlink/w5o84WttALb35e4u。 “我的旧库头文件无法编译”是什么意思?
@ks1322 一个例子是 Oracle 的 "SQL Connector",它仍在使用异常规范。 (悲伤的脸)
#define register
#define throw(...)
技术上是 UB,但可能有用。
【参考方案1】:
通常,您可以使用 -fpermissive
恢复从语言中删除的功能。这不适用于 GCC7 中的 throw
说明符,这可以说是一个错误,您应该报告它。毕竟,-fpermissive
启用了隐式int
s 等好东西。
register
的删除现在只是一个警告,很容易用 -Wno-register
禁用。
【讨论】:
【参考方案2】:auto_ptr 和 register 应该是警告。您可以使用 -Wno-register -Wno-deprecated-declarations 来消除它们。我不知道你能不能对 throw 错误做点什么。
【讨论】:
"auto_ptr 和 register 应该是警告。" 如果它符合 C++17 规范,则不是。警告是针对已弃用的事物。它们没有被弃用;它们被删除(因为它们在一段时间之前已被弃用)。 @NicolBolas,标准是否禁止编译器供应商在 c++17 模式下提供已删除的功能作为扩展?它删除了描述并保留了一些名称,但这似乎还不够。 @xaizek:该标准对任何编译器扩展都保持沉默。只要产生诊断,实现就可以对格式错误的程序做任何事情。但考虑到这些功能在经过一段时间的弃用后被删除,很明显,符合标准的编译预计会停止。 @NicolBolas 然而,“僵尸名称”子句的重点是允许实现在保持一致的同时继续提供已删除的功能。 @T.C.:我很高兴您所说的部分实际上被命名为“僵尸名称”。 [zombie.names] 是 C++ 编程语言标准的真实组成部分。那好极了! ;)以上是关于gcc 可以用旧的第三方库编译 C++17 代码吗?的主要内容,如果未能解决你的问题,请参考以下文章
旧的 ARM32 二进制文件可以在 AARCH64 内核上运行吗?