<输入/输出库< stdio.h>不得使用。” [英] "The input/output library <stdio.h> shall not be used."
问题描述
我正在阅读 JSF AV C ++编码标准和该规则22说：
AV规则22（MISRA规则124，已修订）
输入/输出库
< stdio.h>不得。
是否有任何理由不使用< stdio.h> ？
我知道这些规则适用于 C ++ ，我们可以使用< iostream> ...，但是< stdio.h> ？
不时出现类似这样的问题，即为什么某些编码标准要求这样或那样
正确的答案应该始终是：无论该编码标准的作者打算什么。有时，编码标准给出了其规则的原因；这显然没有。因此，我们只能猜测您问题的答案可能是什么。
我将添加自己的猜测：
飞行器听起来确实是一项严肃的事情，对准确性和鲁棒性的要求非常高。 printf ， scanf 等使编写易于通过编译器但在运行时创建未定义行为的代码变得容易。
那些C函数确实对普通C ++流具有一个优点：格式字符串使编写国际化代码变得更加容易。考虑以下快速构造的示例，该示例使用 std :: ostream 来处理某些UI组件，例如客户管理应用程序中的按钮标签：
os<< 更新客户；
您可能希望动态添加客户的姓名：
os<< 更新<< customer_name<< \n;
您可能希望动态插入 Update的外语单词：
os<< InternationalString（id_update）<< << customer_name<< \n;
但是，这本质上是以英语为中心的。它将产生正确的英语字符串，例如 Update John或 Update Joe，但例如对于德语来说，该语法会失败，德语具有不同的语法，并且要求使用 John aktualisieren或 Joe aktualisieren之类的字符串，在这种情况下，其名称应位于动词之前。 b $ b
这是格式字符串发光的地方：
sprintf（s，FormatString（id_update_customer），customer_name）;
取决于应用程序的语言设置，例如 FormatString 函数可能返回更新％s 或％s aktualisieren 。
还是很危险的。实际上，如果在上面的示例中 customer_name 是 std :: string ，则您将没有定义
像 Boost.Format 尝试将格式字符串的灵活性与流的类型安全性结合起来。
回到您的实际问题，我的猜测是
如您所见，在航空业中，国际字符串的灵活性并不是什么大问题。编码标准的一个方面可以详细讨论。各个规则的原因可能并不总是那么明显，它们通常与编写标准的应用程序域有关。
如果您不能问编码标准的作者，那么您的问题就无法真正得到回答。
I'm reading the JSF AV C++ Coding Standards and the rule 22 says:
AV Rule 22 (MISRA Rule 124, Revised)
The input/output library
<stdio.h>shall not be used.
Is there any reason to not use <stdio.h>?
I know that these rules are for C++ and we can use <iostream>... but what's wrong with <stdio.h>?
Every now and then, there are questions like this, about why some coding standard mandates this or that.
The correct answer should always be: Whatever the authors of that coding standard intended. Sometimes, a coding standard gives reasons for its rules; this one apparently does not. Therefore, we can only guess what the answer to your question might be.
I'll thus add my own guess:
Air vehicles sounds like really serious business, with extremely high correctness and robustness requirements. printf, scanf et al make it easy to write code which happily passes the compiler but creates undefined behaviour at run time.
Those C functions do have one advantage to normal C++ streams: format strings make it easier to write internationalised code. Consider this quickly made-up example using an std::ostream for some UI component such as a button label in a customer management application:
os << "Update customer\n";
You might want to dynamically add the customer's name:
os << "Update " << customer_name << "\n";
And you might want to dynamically insert the foreign-language word for "Update":
os << InternationalString(id_update) << " " << customer_name << "\n";
However, this is inherently English-centric. It will product correct English strings like "Update John" or "Update Joe", but will e.g. fail for German, which has different grammar and requires strings like "John aktualisieren" or "Joe aktualisieren", with the name in front of the verb in this case.
This is where format strings shine:
sprintf(s, FormatString(id_update_customer), customer_name);
Depending on the application's language setting, such a FormatString function may return "Update %s" or "%s aktualisieren".
Still, it's very dangerous. As a matter of fact, if customer_name in my example above was a std::string, you'd have undefined behaviour already.
Libraries like Boost.Format try to combine the flexibility of format strings with the type safety of streams.
Going back to your actual question, my guess is that flexibility with regards to international strings is not a great concern in the air-vehicles business.
As you can see, every aspect of a coding standard can be discussed at great length. The reasons for individual rules may not always be so apparent, and they will often have something to do with the application domain for which the standard was written.
If you cannot ask the author of the coding standard, then your question cannot really be answered.
这篇关于<输入/输出库< stdio.h>不得使用。”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
