为什么编写可移植的C程序很困难？

我想知道,为什么在没有包含胶水代码的情况下让程序在许多操作系统(如Windows和Linux)中运行太难了.它们都共享相同的架构(x86),所以我认为它应该很简单.此外,C是标准化的,那么为什么这些操作系统的实现不同？为什么难以遵循标准并为所有操作系统实现通用库？

我用C编程了将近两年,目前我使用glib来实现可移植性.

我不是在寻找这个问题的解决方案,我已经为此目的使用了glib.但是我想知道为什么它是必要的,为什么制造一个没有差异的C库是很困难的.

[加]

例如,当我在C/Glib中编写程序时,我使用gchar/gint等类型确实是C基元类型,在wikipedia中关于glib,它说:

"特征

在基本层面上,GLib提供了类型定义,取代了C原型char,int,float等,以提高可移植性"

为什么C原始类型不可移植和整个语言？

感谢所有的答案.

1> Matthias Wan..：

---

使您的基本C程序计算一点并打印结果工作很容易.

问题在于,任何实质性的C程序都将依赖于操作系统中的大量服务,并且这些服务在很多方面存在差异.文件I/O往往类似,但在图形方面,它们差别很大.这就是问题的症结所在.

---

即使是C标准库提供功能的文件I/O也是一团糟.尝试执行文件I/O和权限_securely_是一种痛苦,在许多情况下是不可能的.请考虑所有C文件I/O函数都需要用于标识的文件名.这可能导致(无害的)竞争条件,您检查文件的存在,然后打开一个相同的名称I/O. 有关更多信息,请参阅https://www.securecoding.cert.org/confluence/display/seccode/09.+Input+Output+%28FIO%29 :)

2> Norman Ramse..：

---

为什么C原始类型不可移植和整个语言？

在创建C时,最重要的是int使用目标机器的自然字大小(或半字大小)(当时在PDP-10上可能是18或36位!),并且不太重要一个int容易预测的位数,更不用说所有硬件上的位数相同.效率是最重要的考虑因素,一个程序没有太多的指令尤其重要,因此它可以被包装到当天的小记忆中.例如,没有人会想要在16位机器上模拟32位算术 - 这可能会使算术运算所需的指令数量增加三倍,从而无法将更大的程序放入内存中.

为什么实施通用库很难？

这根本不难.问题不在于没有通用的图书馆; 问题是人们无法就什么构成通用图书馆达成一致.(参见:GTK,KDE,QT,AT&T U/WIN + AST,等等令人作呕.)但实现一个好的库真的很难.至于为什么这很难:图书馆设计只​​是一个难题,合理的人可以而且对于什么是好的设计不一致.因此,多个设计激增,可移植性由董事会完成.

C语言中非常精简的标准库加剧了这种情况.但是,我们不要忘记,程序员很幸运能够获得64KB的代码和64KB的数据库.到C++出现的时候,他们可以像标准模板库那样标准化一个巨大的臃肿的猪.但是当设计C库时,事情必须很小.现在,当标准C库不适合当今更加雄心勃勃的应用程序时,所有C程序员都不同意单一标准.

---

戳一位教授,开个讲座......

---

我认为这可能有点修正.在创建C时,它旨在用于特定平台(PDP-11),并且只是自己传播给其他人.每个单独的实现者都自己决定制作各种`int`s的大小.当时没有标准,当标准确实产生时,它所做的一切都是在编译器社区中编纂现有的标准.我们今天所知道的C大部分都不是真正的设计,而是有机地增长.

3> dmckee..：

---

如果你坚持核心标准并不难(K&R中的例子通常会以最小的修正运行).但核心标准并不支持人们想要做的许多事情.小事如:

在文件系统中生根

比普通流式文本更复杂的IO

要求操作系统访问时钟,打印机和网络

与其他流程交谈

---

关于基元类型的可移植性:标准规定了这些类型的最小大小限制,但没有指定实际大小.大多数平台支持的尺寸大于最小尺寸,但并非所有平台都具有相同的更大尺寸.所以glib和其他跨平台项目定义了他们自己的类型,因此他们只需要一组#ifdef开关就可以正确地调整大小.

4> Carson Myers..：

---

您的C程序与之交互的任何内容都将成为依赖项.如果这些依赖关系在所有系统上的每个C实现中完全相同,那么你很幸运,你的程序是可移植的.

基本文件I/O操作就是这种方式.

但是,如果在系统上实现代码的方式存在一个差异,那么它就不再可以移植到该系统.

因此,如果您的代码没有触及任何内容,那么它就是可移植的.

我认为这里的主要思想是最大限度地提高可移植性,这样您就可以最大限度地减少必须更改的内容以便移植到新系统.