为什么UNIX文件描述符不是由它们自己的类型实现的,尤其是在C++中？

Question

我最近一直在使用相当数量的文件描述符,我一直在想为什么它们被实现为整数？

这意味着它们容易混淆其他整数,并且没有办法在没有上下文的情况下知道它们是什么,它们指向什么,它们是否是开放的等等.

在C中,FILE是一种不透明的struct类型.许多人也typedef例如status_t作为整数,因此它们的功能是显而易见的.似乎最好的做法是将它们实现为opaque类型,或者(例如在C++中)作为可以处理某些实现的类,并且还清理namespace一下(调用pipe()或open()看起来如此无害) ,如果没有上下文,你的管道或开放并不明显.例如std::file_descriptor,使用构造函数/工厂函数来创建管道或打开文件等.

我希望这是关于这个网站的主题; 我试图将其称为" 为什么做出了这个特别的决定？ "如果有人知道某个地方它更合适,请告诉我.

Answer 1

历史,如果没有别的.早在20世纪70年代,使用它似乎不是一个问题int(事实上​​,该值是固定大小表的索引).稍后,将其更改为其他类型会破坏代码.

Answer 2

您的问题可分为两部分:

为什么POSIX文件描述符int？

像已经建立的工具和库中的大多数事情一样,答案可能是历史原因.詹姆斯的回答指出了这一点.

使文件描述符不透明可能是一个好主意,但不是你提到的原因.使类型不透明对于基于某些参数具有不同类型是有益的.例如,在某些系统上,您可能需要一个long longas文件描述符.但是,由于似乎没有人同时需要20亿个打开文件,因此没有人愿意解决这个不存在的问题.

另一方面,这样的事情typedef int file_descriptor;不能解决你上面提到的任何问题:

这意味着它们容易混淆其他整数......

如果你混淆了你的变量,我会给你带来坏消息.编译器不会帮助你要么因为file_descriptor与int属于同一类型,所以在一个任何操作,也允许另一方.

......如果没有上下文,就没有办法知道它们是什么,它们指向什么,它们是否是开放的等等.

你也不能这样做FILE.这就是为什么你有功能查询你寻找的信息并将其返回,就像使用FILE.typedef这种类型不会给你任何额外的信息.

为什么POSIX没有C++包装器呢？

简而言之,因为除了微软之外,没有任何操作系统开发人员喜欢C++.Windows几乎没有POSIX,所以微软没有希望尝试改进任何POSIX.其他符合POSIX标准的操作系统都有一个C API作为事实上的系统编程语言(部分原因是因为nm说,几乎所有语言都可以绑定到C).

事实上,C++在应用程序开发人员中很受欢迎,但在系统程序员中并不多.POSIX委员会似乎对C++也不是特别感兴趣.这就是为什么你会看到C和仅有关于POSIX API的C解决方案和参数的原因.还要注意POSIX的创建是为了特别标准化UNIX的接口,它是用C语言编写的,其中一个最重要的后代Linux也强烈地绑定到C.