blocks|key|305803|text|C+printf()-style输出通常比C%2B%2B+ostream输出更快。但当然，它不能处理C%2B%2B输出可以处理的所有类型。这是我所知道的唯一优点--通常，由于积极的内联，C%2B%2B可以比C快得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|305804|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

C printf()-style output is typically faster than C++ ostream output. But of course it can't handle all the types that C++ output can. That's the only advantage I'm aware of - typically, because of aggressive inlining, C++ can be a lot faster than C.

blocks|key|305779|text|在编写C%2B%2B时，请编写C%2B%2B。当你写C的时候，写C。不管谁说的不一样，都可能会对这些不同感到不舒服，或者认为C%2B%2B是一个“更好的C”。事实并非如此；C%2B%2B是它自己的语言，有它自己的特性，并且主要是为了简化转换而与C兼容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|305780|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When you're writing C++, write C++. When you're writing C, write C. Whoever says different is probably uncomfortable with the differences, or thinks of C++ as a "better C". That isn't the case; C++ is its own language with its own features, and is mostly C-compatible for the sole purpose of easing conversion.

blocks|key|3034243|text|就性能而言，我曾经是USACO的竞争对手。我很快发现我的一个程序98%25的运行时间都花在了C%2B%2B+IOStreams上。更改为fscanf可将开销减少到原来的十分之一。在性能方面，根本没有竞争。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3034244|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As far as performance goes, I used to be a USACO competitor. I quickly found that 98% of one of my programs' runtime was spent using C++ IOStreams. Changing to fscanf reduced the overhead by a factor of ten. Performance-wise, there's no contest at all.

blocks|key|3034263|text|我认为当你需要原始内存管理时，C风格更好。使用C%2B%2B构造做这件事有点麻烦，例如，您没有realloc()。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3034264|投反对票的人可能从来没有尝试过探索这个话题。|3034265|3034266|我很惊讶人们怎么不能想象自己身处不同的位置。我并不是说每个人都应该使用C风格的构造。我的意思是，当你的需要原始内存管理时，C风格更好。必须有人编写所有这些安全的类/库(包括标准库、垃圾收集器、内存池)。你从来不需要它的经验并不涵盖所有的情况。|offset|length|style|BOLD|3034267|3034268|另一种情况是当你编写一个库时。使用C你可以得到漂亮的符号表，它可以很容易地与许多其他编程语言绑定在一起。有了C%2B%2B，您将拥有name+mangling，这使得库更难(但并非不可能)在非C%2B%2B环境中使用。|3034269|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Name_mangling^0|0|0|0|1F|2|0|0|1Q|D|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|Y|8|@$G|Z|H|10|I|J]]|9|@]|A|$]]|$1|K|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|12|8|@]|9|@$G|13|H|14|1|15]]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

I think C style is better when you need raw memory management. It is a bit cumbersome to do that with C++ constructs and you don't have realloc() for example.

Someone who down voted that, probably never tried to explore the topic.

<hr>

I'm surprised how people can't imagine themselves in different positions. I'm not saying that everybody should use C style constructs. I'm saying that C style is better when you NEED raw memory management. Someone has to write all those secure classes/libraries (including standard library, garbage collectors, memory pools). Your experience in which you never need it does not cover all cases.

<hr>

Another situation is when you write a library. With C you get pretty symbols table, which can be easily binded with many other programming languages. With C++ you will have <a href="http://en.wikipedia.org/wiki/Name_mangling" rel="nofollow noreferrer">name mangling</a>, which makes library harder (but not impossible) to use in non-C++ environment.

blocks|key|3248471|text|好样的老C！啊，ANSI之前的日子..。我当然怀念几乎没有对参数和返回值进行类型检查，或者让编译器假设任何非类型化的东西都是int而不是error。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3248472|不过，说真的，有一个相当好的理由反对使用异常作为错误处理。我读了一个相当不错的系统级工作的decent+argument+against+exceptions，大多数时候我认为问题是你不能简单地读一段代码就知道它不会抛出C%2B%2B，而你可以读大多数C语言并说“所有的错误(在这个级别)都被捕获了”或者“那些无关紧要的错误”。|offset|length|3248473|entityMap|0|LINK|mutability|MUTABLE|url|http://tratt.net/laurie/tech_articles/articles/how_can_c_programs_be_so_reliable^0|0|19|Y|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Good old C! Ah, the pre-ANSI days... &lt;sarcasm&gt;I certainly miss having practically no type checking on arguments and returns values or having the compiler assume anything untyped is an int and not an error.&lt;/sarcasm&gt; 

Seriously, though - there is a fairly good argument against using exceptions as error handling. I read a fairly <a href="http://tratt.net/laurie/tech_articles/articles/how_can_c_programs_be_so_reliable" rel="nofollow noreferrer">decent argument against exceptions</a> for system level work and mostly I think the problem is that you can't simply read a block of code and know it won't throw in C++, whereas you can read most C and say "all the errors (at this level) are trapped" or "the ones that aren't don't matter".

blocks|key|302842|text|我不能给你一个肯定的答案，但我发现这个相当过时的比较很有趣。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|302843|http://unthought.net/c%2B%2B/c_vs_c%2B%2B.html|offset|length|302844|entityMap|0|LINK|mutability|MUTABLE|url|http://unthought.net/c%2B%2B/c_vs_c%2B%2B.html^0|0|0|12|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I couldnt give you a conclusive answer; however i found this rather dated comparison interesting.

<a href="http://unthought.net/c++/c_vs_c++.html" rel="nofollow noreferrer">http://unthought.net/c++/c_vs_c++.html</a>

blocks|key|3248508|text|我不认为使用printf风格的函数通常比iostream更合理。iostreams大大加快了开发时间和调试时间，并且不容易出错(例如，考虑到缓冲区溢出、错误的%25类型说明符、错误的参数数量……最大的问题是编译器根本不能帮助你)。如果你在不需要的时候不使用endl，cout也不会比printf慢多少。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3248509|因此，通常你应该使用snprintf+iostream，只有当分析显示临界区由于iostream调用而花费太多时间时，才使用C风格的函数优化这些节，但确保使用更安全的函数版本，如C%2B%2B而不是sprintf。|3248510|示例：|3248511|考虑一下您有一个int+foo变量，您在许多地方使用printf，在以后的开发过程中，您意识到您需要将foo改为double。现在，您必须更改每个使用foo的printf样式调用中的类型说明符。如果你漏掉了一句话，欢迎来到未知行为的国度。|3248512|最近我遇到了一个例子，我的程序崩溃了，因为我遗漏了一个简单的逗号，而且由于很棒的printf风格的命令，我的编译器没有帮到我：printf("i+will+crash++%25s"+/*,*/+"here");。这种情况在iostreams中也不会发生。|3248513|当然，你不能扩展printf和friend的行为来使用你自己的类，就像你可以使用iostream一样。|3248514|entityMap^0|3I|4|3N|4|0|0|0|8|7|Q|6|1F|3|1K|6|23|3|27|6|0|1R|14|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1E|8|@]|D|@]|E|$]]|$1|P|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]]|Q|$]]

I dont think using printf style functions generally over iostreams is justified.
iostreams just greatly speed up development time and debugging time, and are much less error prone (e.g. think of buffer overflows, wrong % type specifiers, wrong number of arguments ... and the biggest problem is that the compiler cant help you at all). 
And if you dont use <code>endl</code> when it isnt needed, <code>cout</code> isnt that much slower than printf.

So generally you should go with C++ iostreams, and only if profiling shows that critical sections take too much time because of iostream calls, then optimize those sections with C style functions, but make sure to use the safer versions of the functions like snprintf instead of sprintf.

Examples:

Consider you have a <code>int foo</code> variable, which you <code>printf</code> in a number of places, later during development, you realize you need <code>foo</code> to be a <code>double</code> instead. Now you have to change the type specifiers in every <code>printf</code> style call which uses <code>foo</code>. And if you miss one single line, welcome in the land of undefined behaviour.

Recently i had a case where my program crashed because i missed a simple comma, and because of the great printf-style command, my compiler didnt help me: <code>printf("i will crash %s" /*,*/ "here");</code>. This wouldnt have happened with iostreams either.

And of course you cant extend the behaviour of printf and friend to work with your own classes like you can with iostreams.

blocks|key|300671|text|在哪些地方使用C%2B%2B功能可能会有问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|300672|300673|portability:+IMHO+C仍然是更多的portable|unordered-list-item|offset|length|style|BOLD|300674|mixed语言编程:从另一种语言调用C函数几乎不会有问题，使用C%2B%2B你很快就会因为名称混乱的问题而陷入麻烦:模板这样的功能可能会导致代码膨胀，临时对象创建也可能有巨大的影响，因为C%2B%2B比C更复杂，限制使用您希望以后维护您的代码的人能够使用的语言功能。|300675|300676|然而，如果小心使用，C%2B%2B的一些/大多数功能是非常方便和有用的。记住这句话：“使用C%2B%2B很难朝自己的膝盖开枪，但如果你这样做了，你就会失去整条腿”。|300677|entityMap^0|0|0|0|C|0|0|1A|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|V|8|@$F|W|G|X|H|I]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|P|$]]

Where using C++ features might be problematic:

<ul>
<li>portability: IMHO C is still more portable</li>
<li>mixed language programming: calling a C function from another language is almost never problematic, with C++ you quickly get in trouble because of name mangling etc.</li>
<li>performance issues: features like templates may lead to code bloat, temporary object creation may have a huge impact too, etc...</li>
<li>maintainability: Since C++ is more complex than C, Restrict use to language features you expect the person who is later maintaining your code to be capable of.</li>
</ul>

However, some/most of C++ features are quite handy and useful if used with care.
Remember the saying "With C++ it's harder to shoot yourself in the knee, but if you do, it will cost you the entire leg".

blocks|key|300632|text|当我不需要泛型代码时，我有时更喜欢指针和memcpy而不是迭代器和std::copy。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|300633|对于iostream也是如此，它们都很方便且可扩展，但在很多情况下，f%7Csprintf+/+scanf也同样简单。|300634|entityMap^0|K|6|X|9|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

I sometimes prefer pointers and <code>memcpy</code> over iterators and <code>std::copy</code> when I don't need generic code.

Same for iostreams, they are convenient and extensible but there are a lot of situations when [f|s]printf / scanf are as simple.

Recently i had a discussion with my boss (a long time C developer) who discouraged me in using C++ streams and stick to "good old" <code>printf</code> &amp; friends. Now i can understand why he is saying this and believe me i did not follow his advice.

But still this is bugging me - are there things in C that are still better in some cases than newer C++ implementations of the same/similar thing? By better i mean for example performance, stability or even code readability/maintainability. And if so, can someone give me examples? I'm mainly talking about similar differences like printf/streams, not about features like inheritance or OOP for that matter. The reason why i'm asking all this is that i consider myself a C++ developer and as such I always try to code the C++ way.

Situations where "old" C features might be better than newer C++ ones?

内存管理

编译器

最近，我和我的老板(一个长期的C开发人员)进行了一次讨论，他不鼓励我使用C++ streams，而是坚持使用“老朋友”printf & friends。现在我明白他为什么这么说了，相信我，我没有听从他的建议。但这仍然困扰着我--在某些情况下，C中有没有比相同/相似东西的更新的C++实现更好的东西呢？我所说的更好的意思是性能，稳定性，甚至代码的可读性/可维护性。如果是这样的话，有人能给我举个例子吗？

问“老的”C特性可能比新的C++特性更好的情况？
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问“老的”C特性可能比新的C++特性更好的情况？EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问“老的”C特性可能比新的C++特性更好的情况？
EN