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 回答