为什么 fputs 和 fprintf 反向流顺序答案

【问题标题】：why fputs and fprintf reverse stream order为什么 fputs 和 fprintf 反向流顺序
【发布时间】：2015-01-15 03:25:11
【问题描述】：

我不明白为什么 fputs 和 fprintf 反向流顺序。

int fputs (const char * str, FILE * stream);
int fprintf (FILE * stream, const char * format, ...);
ssize_t write(int fd, const void *buf, size_t count);

我知道 fprintf 把流放在前面支持可变参数，但是为什么 fputs 系列不保持一致性？？？

【问题讨论】：

发生在很久以前，我不确定是否有人可以绝对肯定地给出答案。我个人认为printf 是出于必要（正如您已经指出的那样）并且fputs 那时可能已经建立，因此将其反转以匹配被认为是站不住脚的。
Scott Meyers 刚刚发表了关于 API 设计的演讲，他强调这个确切的例子是“做错了”[youtube.com/watch?v=5tg1ONG18H8]。
stdio 总的来说是一个设计不佳的库：还有很多其他问题。
@EJP：我认为“设计不佳”是相当修正主义的历史。它比当时的大多数其他人都好，并且许多人现在可能认为“优越”的设计在当时的机器上可能根本站不住脚（即使手机现在有更多的内存和比设计时速度最快的大型机还要快）。
@JerryCoffin 一点也不。我记得我在 1979 年第一次看到它时是这样想的。例如：fwrite() 中的 size 参数意味着如果有部分写入，它不能告诉你写入了多少字节，只有多少元素，所以你可以永远不知道部分元素写入。最好省略它。将FILE * 参数放在末尾而不是开头是另一个示例。当时有设计更好的 API。

标签： c printf fputs

【解决方案1】：

因为这些东西是几十年前写的，所以通常只是历史学家感兴趣的问题:-)

可能只是一个设计决定（或缺乏决定）导致他们成为这种方式，并且由于 ISO 重视向后兼容性，他们从未改变过它。

可能是 puts 是最先编写的，当需要编写 fputs 时，开发人员只是简单地剪切'n'粘贴它，将新参数粘贴到末尾。即使printf/fprintf 存在相同的情况，由于需要将变量参数列表放在末尾，这也是不可能的。

但是，抛开假设不谈，既然我们心爱的丹尼斯走了，我们可能永远不会知道实际原因..

【讨论】：

愿上帝保佑丹尼斯！我只是对它感兴趣。我一直相信有一些原因。也许你是对的！谢谢你的回答！
但是似乎 puts 调用 fputs(str, stdout) 来打印一些东西，所以 fputs 应该更早设计吗？我不确定。
@qianchenglong, puts 现在可以打电话给fputs 但是，就像所有的历史一样，当时的情况可能完全不同:-)
如果没有记错的话，大部分 I/O 库实际上是由 Mike Lesk 设计和开发的。据我所知，他还活着（但我完全不相信他会确切地记得为什么要按每个函数的顺序排列参数）。
@JerryCoffin 我在这个方向做了一些研究。我相信fputs、fread 和fprintf 中的参数顺序在Unix v7 in 1979 中是一成不变的，因为在Unix v1 in 1971 到Unix v6 in 1975 中，I/O 原语大致没有改变并且非常原始：@ 987654332@ 等。因此，如果它们确实是 Lesk 的作品，那么他 1972 年的备忘录需要 7 年时间才能整合。 fputs 可能源自 putc(c, iobuf)。