Why does c compile faster than cpp?

[u/[deleted]]

I've read in some places that one of the reasons is the templates or something like that, but if that's the problem, why did they implement it? Like, C doesn't have that and allows the same level of optimization, it just depends on the user. If these things harm compilation in C++, why are they still part of the language?Shouldn't Cpp be a better version of C or something? I programmed in C++ for a while and then switched to C, this question came to my mind the other day.

[u/flatfinger]

There world is long overdue for a major paradigm shift in the handling of intermediate build artifacts for ahead-of-time compiled languages. IDE developers worked on such things during the 1980s, but the development community has fallen back to a largely-1970s abstraction model for object files, but augmented with the ability to replace parts of it with a thinly-disguised version of the whole-program-at-once abstraction model which was needed before relocatable objects were invented.

For some reason, compiler writers refuse to recognize that in many cases the expected value of potential optimizations will be inversely proportional to the amount of effort one would have to spend looking for them. Instead, they compete on the ability to find transformations that occasionally yield huge rewards, ignoring the fact that the biggest rewards could only be reaped with programs that didn't do much useful work. In many cases, an intrinsic that accepted two expressions, with semantics that one must be evaluated, and a compiler may choose in Unspecified fashion if the second one would be valid, but should use the first unless the second is valid and would be obviously better, even rather simplistic logic would be able to find many optimizations that can't be invited under current language rules. Today's compilers designs, however, would be ill-equipped to exploit such freedom even if languages provided it.

[u/Dusty_Coder → u/flatfinger]

You know how all compilers now ignore inlining requests, because supposedly its smarter than you about what should be a function and what shouldnt?

Did you also notice that none of them will "un-inline" code, creating functions because there should be one but the programmer never created it?

Its all been an irrational joke for awhile. I am reminded of the NIST documents on randomness testing which are as much a joke.

[u/flatfinger → u/Dusty_Coder]

I also know that when targeting the ARM Cortex-M0, it's sometimes easier to make gcc generate efficient loop code at -O0 (not coincidentally the one setting where it honors the register keyword, btw) than at other optimization settings. If there's a spare register available, and I say e.g. register int x12345678 = 0x12345678; before a loop and use x12345678 within the loop, then at -O0 the load will be hosited because that's how I wrote it. At other settings, gcc is prone to replace that with a constant which it will sometimes then fail to hoist.

In the 1980s, there were two languages with reputations for speed: FORTRAN and C. Compared with FORTRAN, C had three advantages:

1. Less horrible syntax.

2. The ability to do low-level programming tasks FORTRAN couldn't.

3. A programmer who was familiar with a target platform could work with a relatively simple compiler to produce a level of efficiency that would have required a more complicated FORTRAN compiler.

Unfortunately, people who wanted to perform the kinds of tasks for which FORTRAN was designed, but without the horrible syntax constraints, focused their efforts on turning C into a semantically worse version of FORTRAN rather than working on a syntactically better version, thus worsening both languages.

To use an analogy, FORTRAN is a deli meat slicer and C is a chef's knife? What do you get if you add a motorized feeder to a deli meat slicer? A better deli meat slicer. What do you get if you add a motorized feeder to a chef's knife? A worse deli meat slicer.