1

我正在使用仍然有一些尘土飞扬的角落的旧 C 代码。我发现很多关于#ifdef操作系统、体系结构等的陈述，并为了可移植性而改变了代码。我不知道这些陈述中有多少在今天仍然适用。

我知道#ifdef在某些情况下这不是最好的主意，我一定会解决这个问题，但我在这里感兴趣的是正在测试的内容。

我在下面列出了它们。如果您能告诉我它们中的任何一个在当今时代是否绝对有用，或者它们所关联的机器或操作系统是否早已过期，那就太好了。另外，如果您知道这些的任何中心参考资料，我很想听听。

在此先感谢，罗斯

BORLANDC
BSD
CGLE
DRYRUN
HUGE
IBMPC
MAIN
M_XENIX
OPTIMIZED
P2C_H_PROTO
sgi
TBFINDADDREXTENDED
UNIX
vms
__GCC__
__GNUC__
__HUGE__
__ID__
__MSDOS__
__TURBOC__
4

6 回答 6

7

给你。

于 2010-07-08T14:20:53.243 回答
3

你来自错误的方向。与其问哪些代码可以安全删除，不如问——哪些代码必须保留。

找出必须支持的平台并删除其中未定义的所有内容。你会得到最干净的代码，但仍然可以保证工作。

于 2010-07-08T14:21:32.693 回答
2

这段代码使用的是什么上下文？

  1. 如果它是您组织之外的其他人正在使用的库，则除非您发布新版本并明确删除对某些操作系统的支持，否则您不应该接触这些东西。在后一种情况下，您应该删除所有相关的 IFDEF 代码作为发布新版本的一部分，并且应该明确说明您要删除的内容。
  2. 如果它是您组织内部的人员正在使用的图书馆，您应该询问这些人您可以删除哪些内容，而不是我们。
  3. 如果它的代码使用范围很窄（即您可以直接控制它的使用），如果您愿意，您可以安全地删除任何类型的编译器可移植性，因为您只使用一个编译器。
于 2010-07-08T14:30:11.813 回答
2

你问错人了：决定什么仍然有用的是你的用户（或潜在用户），而不是我们。首先找出您需要支持的平台，然后您可以找出不需要的平台。

例如，如果您不需要支持 16 位系统，则可以省去__HUGE__、__MSDOS__和__TURBOC__.

于 2010-07-09T06:52:18.153 回答
1

像这样注释的代码实际上很难维护。您可以考虑研究类似 autotools 之类的东西来为特定架构配置源代码。

于 2010-07-08T14:22:26.377 回答
1

任何#ifdef基于实现提供的任意预处理器定义都是过时的——尤其是那些在为应用程序保留的命名空间中的定义，而不是实现，因为大多数都是！实现这种可移植性的正确现代方法是使用配置脚本等检测#define HAVE_FOO不同接口/功能/行为的存在，基于此，直接测试标准预处理器定义（如UINT_MAX确定整数大小），和/或使用适当的HAVE_FOO定义为您想要支持的每个平台提供预构建的头文件。

旧式的“可移植性”#ifdef与您的源代码中的每个平台的知识紧密结合，当平台发生变化并采用新功能、行为或默认设置时，这将是一场噩梦。（想象一下，假设 Windows 是 16 位或 Linux 具有 SysV 风格的旧代码的混乱signal()！）现代风格隔离了平台的知识，并允许源文件中的条件编译仅依赖于存在/不存在/行为它想要使用的功能。

于 2010-07-08T14:21:52.043 回答