我想说，printf的可扩展性不足是不完全正确的: 在C语言中，它是真的。但是在C语言中，没有真正的类。 在c++中，可以重载强制转换操作符，因此，重载char*操作符并像这样使用printf:

Foo bar;
...;
printf("%s",bar);

可以是可能的，如果Foo重载好的操作符。或者你有一个好方法。简而言之，printf对我来说和cout一样具有可扩展性。

我可以看到c++流的技术参数(一般来说…不仅是cout.)是:

类型安全。(顺便说一下，如果我想打印一个'\n'，我使用putchar('\n')…我不会用核弹杀死一只昆虫。) 更容易学。(不需要学习“复杂的”参数，只需使用<<和>>操作符) 本机使用std::string(对于printf有std::string::c_str()，但对于scanf?)

对于printf，我看到:

更容易，或至少更短(就书写的字符而言)复杂的格式。对我来说，可读性更强(我猜是品味问题)。 更好地控制函数所生成的内容(返回写入了多少字符并且有%n格式化程序:"Nothing printing . "参数必须是一个指向有符号整型的指针，其中存储到目前为止写入的字符数。”(from printf - c++ Reference) 更好的调试可能性。原因和上一个论点一样。

我个人倾向于使用printf(和scanf)函数，主要是因为我喜欢短行，而且我认为打印文本时的打字问题并不难避免。 我唯一对c风格函数感到遗憾的是std::string不受支持。在将其交给printf之前，我们必须通过一个char*(如果我们想读，则使用std::string::c_str()，但如何写?)

我不是程序员，但我曾是人为因素工程师。我觉得编程语言应该是容易学习、理解和使用的，这就要求它有一个简单而一致的语言结构。虽然所有的语言都是象征性的，因此，在其核心是任意的，但有惯例，遵循这些惯例使语言更容易学习和使用。

在c++和其他语言中，有大量的函数以函数(参数)的形式编写，这种语法最初是在前计算机时代用于数学中的函数关系。printf()遵循这种语法，如果c++的作者想要创建任何逻辑上不同的方法来读写文件，他们可以使用类似的语法简单地创建一个不同的函数。

在Python中，我们当然可以使用同样标准的对象进行打印。方法语法，即variablename。因为变量是对象，但在c++中它们不是。

我不喜欢cout语法，因为<<操作符不遵循任何规则。它是一个方法或函数，也就是说，它接受一个参数并对它做一些事情。然而，它被写成了一个数学比较运算符。从人为因素的角度来看，这是一个糟糕的方法。

我引用一下:

在高层术语中，主要的区别是类型安全(cstdio 没有它)，性能(大多数iostreams实现都有 比cstdio慢)和可扩展性(iostreams允许 自定义输出目标和用户定义类型的无缝输出)。

我想说，printf的可扩展性不足是不完全正确的: 在C语言中，它是真的。但是在C语言中，没有真正的类。 在c++中，可以重载强制转换操作符，因此，重载char*操作符并像这样使用printf:

Foo bar;
...;
printf("%s",bar);

可以是可能的，如果Foo重载好的操作符。或者你有一个好方法。简而言之，printf对我来说和cout一样具有可扩展性。

我可以看到c++流的技术参数(一般来说…不仅是cout.)是:

类型安全。(顺便说一下，如果我想打印一个'\n'，我使用putchar('\n')…我不会用核弹杀死一只昆虫。) 更容易学。(不需要学习“复杂的”参数，只需使用<<和>>操作符) 本机使用std::string(对于printf有std::string::c_str()，但对于scanf?)

对于printf，我看到:

更容易，或至少更短(就书写的字符而言)复杂的格式。对我来说，可读性更强(我猜是品味问题)。 更好地控制函数所生成的内容(返回写入了多少字符并且有%n格式化程序:"Nothing printing . "参数必须是一个指向有符号整型的指针，其中存储到目前为止写入的字符数。”(from printf - c++ Reference) 更好的调试可能性。原因和上一个论点一样。

我个人倾向于使用printf(和scanf)函数，主要是因为我喜欢短行，而且我认为打印文本时的打字问题并不难避免。 我唯一对c风格函数感到遗憾的是std::string不受支持。在将其交给printf之前，我们必须通过一个char*(如果我们想读，则使用std::string::c_str()，但如何写?)

来自c++常见问题解答:

[15.1] Why should I use <iostream> instead of the traditional <cstdio>? Increase type safety, reduce errors, allow extensibility, and provide inheritability. printf() is arguably not broken, and scanf() is perhaps livable despite being error prone, however both are limited with respect to what C++ I/O can do. C++ I/O (using << and >>) is, relative to C (using printf() and scanf()): More type-safe: With <iostream>, the type of object being I/O'd is known statically by the compiler. In contrast, <cstdio> uses "%" fields to figure out the types dynamically. Less error prone: With <iostream>, there are no redundant "%" tokens that have to be consistent with the actual objects being I/O'd. Removing redundancy removes a class of errors. Extensible: The C++ <iostream> mechanism allows new user-defined types to be I/O'd without breaking existing code. Imagine the chaos if everyone was simultaneously adding new incompatible "%" fields to printf() and scanf()?! Inheritable: The C++ <iostream> mechanism is built from real classes such as std::ostream and std::istream. Unlike <cstdio>'s FILE*, these are real classes and hence inheritable. This means you can have other user-defined things that look and act like streams, yet that do whatever strange and wonderful things you want. You automatically get to use the zillions of lines of I/O code written by users you don't even know, and they don't need to know about your "extended stream" class.

另一方面，printf要快得多，因此在非常特定和有限的情况下，可以优先使用它而不是cout。总是先做侧写。(例如，参见http://programming-designs.com/2009/02/c-speed-test-part-2-printf-vs-cout/)

Printf是一个函数而cout是一个变量。