Warum sind C- und C ++ auch nach der Zusammenstellung anders?

Question

Ich vermutete es, war aber immer noch überrascht zu sehen, dass die Ausgabe dieser beiden in C und C ++ geschriebenen Programme, wenn er kompiliert wurde, sehr unterschiedlich waren. Das macht mich der Meinung, dass das Konzept der Objekte noch auf dem niedrigsten Niveau existiert. Fügt das hinauf?Wenn ja, ist es derzeit eine unmögliche Optimierung, den objektorientierten Code in den Prozedurstil umzuwandeln oder einfach sehr schwer zu tun?

HELLELORD.C generasacodicetagpre.

HELLELORD.CPP generasacodicetagpre.

so zusammengestellt: generasacodicetagpre.

erstellt diesen Code:

C-Montage generasacodicetagpre.

C ++ - Baugruppe generasacodicetagpre.

Answer 1

Different compilers produce different code. An early version of gcc versus the current version of gcc likely produce different code.

More importantly, iostream handles a lot of things stdio doesn't, so there's obviously going to be some substantial overhead. I understand that, in theory, these could be compiled down to indentical code, but what they're doing is not technically identical.

Answer 2

Your issue here isn't about objects or optimization: it's that printf and cout are fundamentally very different beasts. For a more fair comparison, replace your cout statement in the C++ code with printf. Optimization is a moot point when you're outputting to stdout, as the bottleneck will certainly be the terminal's buffer.

Answer 3

You're not calling the same functions in the C++ example as the C example. Replace the std::cout pipes with plain old printf just like the C code and you should see a much greater correlation between the output of the two compilers.

Answer 4

You have to realize that there are a whole lot of "other" things going on in C++. Global constructors for example. Also the libraries are different.

the C++ stream object is far more complicated than C io, and if you look through the assembler you can see all the code for pthreads in the C++ version.

It's not necessarily slower but it's certainly different.

Answer 5

I guessed it but was still surprised to see that the output of these two programs, written in C and C++, when compiled were very different.

I'm surprised you were surprised - they're totally different programs.

That makes me think that the concept of objects still exist at even the lowest level.

Absolutely... objects are the way memory is laid out and used during program execution (subject to optimisations).

Does this add overhead?

Not necessarily or typically - the same data would have to be somewhere anyway if the work was being coordinated in the same logical way.

If so is it currently an impossible optimization to convert object oriented code to procedural style or just very hard to do?

The issue has nothing to do with OO vs procedural code, or one being more efficient than the other. The main issue you observe here is that C++'s ostreams require a bit more setup and tear-down, and have more of the I/O coordinated by inline code, while printf() has more out-of-line in the precompiled library so you can't see it in your little code listing. It's not clear really which is "better", and unless you have a performance problem that profiling shows is related you should forget about it and get some useful programming done.

EDIT in response to comment:

Fair call - was a bit harshly worded - sorry. It's a difficult distinction to make actually... "only the compiler [knows] of objects" is true in one sense - they're not encapsulated, half-holy discrete "things" to the compiler the way they can be to the programmer. And, we could write an object that could be used exactly like you have used cout that would disappear during compilation and produce code that was equivalent to the printf() version. But, cout and iostreams involves some setup because it's thread safe and more inlined and handles different locales, and it's a real object with storage requirements because it carries around more independent information about error state, whether you want exceptions thrown, end-of-file conditions (printf() affects "errno", which is then clobbered by the next library/OS call)....

What you might find more insightful is to compare how much extra code is generated when you print one more string, as the amount of code is basically some constant overhead + some per-usage amount, and in latter regard ostream-based code can be as or more efficient than printf(), depending on the types and formatting requested. It's also worth noting that...

std::cout << "Hello world!\n";

...is correct and more analogous to your printf() statement... std::endl explicitly requests an unnecessary flushing operation, as a Standard-compliant C++ program will flush and close its buffers as the stream goes out of scope anyway (that said, there's an interesting post today where it seems someone's Microsoft VisualC++ compiler's not doing that for them! - worth keeping an eye on but hard to believe).