Thread: C++ vs C

Sure, silly post in silly thread.
Just like every other x vs. y thread has been, and any future x vs. y thread is going to be.

Salem you need your 30000th post to be here.

Originally Posted by Click_here

Salem you need your 30000th post to be here.

I'm personally more interested in what will happen to the site when Salem posts his 32767th and 32768th posts

Originally Posted by grumpy

I'm personally more interested in what will happen to the site when Salem posts his 32767th and 32768th posts

I think he will roll over and become a newb again!

Build time is most certainly not irrelevant. There is the whole module effort going on right now, which is somewhat about avoiding the pitfalls of the preprocessor, but mostly about reducing compile time. There are companies that hire consultants for the specific purpose of reducing the build time of their product. The language Go was designed from the start to be extremely fast to compile.

A program isn't built once. Even under the assumption that you write perfect code the first time, you will have multiple releases with additional features, and each of those needs to be compiled, possibly for multiple platforms. Of course, in the real world, you have far more compiling going on. You build several times to fix compile errors, or simply to check that there aren't any before you continue working. You fix bugs and recompile. You try something out. You add a test case.
Then there's the nightly build that your company has (or should have). If your system allows it, there may be a continuous integration system that kicks off a build every time something is committed to the central repository.
And don't forget the hidden builds. While you're typing in your IDE, it is struggling to keep up with you by parsing and reparsing your code so that it can mark compile errors and provide auto-completion information. How happy are you with the response time these features in Visual Studio compared to C#?

There's a whole development method, test-driven development, that is really hard to do in C++ because it relies on a rapid edit-recompile-test cycle that breaks down once even an incremental build takes more than a few seconds.

When Microsoft recently did a survey of what users want from their C++ compiler, improved compilation speed ranked at the top together with standards conformance.

So yes, build time is important.

Originally Posted by CornedBee

There's a whole development method, test-driven development, that is really hard to do in C++ because it relies on a rapid edit-recompile-test cycle that breaks down once even an incremental build takes more than a few seconds.

If your TDD workflow involves recompiling the entire product at every step I think you're doing something wrong. If we're talking unit tests, then you only need to compile enough code to test that single unit, and a unit should not be large. (And if you have to compile more that just the unit you are testing in order to test it, maybe something is wrong with your architecture). For integration tests, in my experience a good integration test takes long enough to write (multiple hours) that even a one-hour build time might be acceptable (though of course you'd rather it take less time).

One of the aspects of TDD is that it can drive your architecture indirectly, in exactly such ways.

If your TDD workflow involves recompiling the entire product at every step I think you're doing something wrong.

As I said, I've often enough seen incremental builds (i.e. recompiling only what changed) take too long. And if you change your unit test system to make the compiles even more minimal (say, by putting every single unit test into its own project, and split the headers even finer) the architectural overhead may just become too great. (Also, the process startup overhead when you do a full test run.)

Originally Posted by CornedBee

As I said, I've often enough seen incremental builds (i.e. recompiling only what changed) take too long. And if you change your unit test system to make the compiles even more minimal (say, by putting every single unit test into its own project, and split the headers even finer) the architectural overhead may just become too great. (Also, the process startup overhead when you do a full test run.)

A few observations: Changes to widely-used header files suck for incremental builds. That hurts C just as much as it does C++, but perhaps C++ architectures are more prone to it (I'm not sure if anyone has tried to measure it). Also, the compiler may be doing significant code generation at link time due to whole-program optimization which means it's actually recompiling many many files on each link, not just what has changed (and for development it's usually better to turn that off for just this reason).

But yeah, build time can be a factor. However, that has more to do with architecture than any inherent difference between C and C++, I think.

Originally Posted by brewbuck

That hurts C just as much as it does C++, but perhaps C++ architectures are more prone to it (I'm not sure if anyone has tried to measure it).

It's not so much C++ architectures, as it is particular architectures that are easy to overuse in C++ and difficult in C (or vice versa). An example would be excessive use of inheritance, which always causes a compile-time dependency.

I'm not sure how much work has gone into measuring such things though, except in particular use cases.

Template instantiation (which is a C++ feature, not C) can increase compile times. But it is debatable what the difference in compile times would be between "instantiate a template for a hundred types" and the rough C equivalent of "compile a set of one hundred inline functions that do the same things on one hundred different types". The differences, if something like that is being done, come down to quality of implementation issues between compilers, rather than being specific to C or C++.

Originally Posted by brewbuck

Also, the compiler may be doing significant code generation at link time due to whole-program optimization which means it's actually recompiling many many files on each link, not just what has changed (and for development it's usually better to turn that off for just this reason).

Compilers don't typically do significant code generation at link time. There are a few "smart linkers" that do, but not compilers. I've come across a couple of really neat smart linkers associated with (proprietary) C++ compilers, but have yet to come across such a smart linker associated with a pure C compiler.

Originally Posted by brewbuck

But yeah, build time can be a factor. However, that has more to do with architecture than any inherent difference between C and C++, I think.

I certainly agree with you that architecture of the program or system being developed is more critical than the choice of language. However, some particular architectural techniques are better supported by one language or the other.

Another factor is quality of implementation of individual compilers, and the vintage of those compilers. A lot of the laments about C++ overheads in comparison with C (eg exceptions) originated over a decade ago, when compiler technologies were less mature than they are now. Modern compilers are much less afflicted with such things, but the laments persist even when the justification for them is less than it was.

There is a tendency of people stacking the odds when doing "case studies" when they compare programming languages. I've seen a number of "case studies" that used professionally-written C code with a rather dodgy C++ code to argue about the virtues of C, and others that used professionally written C++ code and a dodgy C code to argue about virtues of C++. (The same sort of thing is more common in debates between C++ and Java, but it also happens in debates between C and C++).

Originally Posted by grumpy

Compilers don't typically do significant code generation at link time. There are a few "smart linkers" that do, but not compilers. I've come across a couple of really neat smart linkers associated with (proprietary) C++ compilers, but have yet to come across such a smart linker associated with a pure C compiler.

I have never heard of a compiler/linker that actually recompiles anything during linking. All LTO systems that I know instead compile the code to some intermediate representation and dump that to the object files instead of real object code, and have the linker only do optimization and final code generation during the linking.
But that capability is actually quite common. Intel's and Microsoft's proprietary compilers can do it, of course, but so can GCC (when used with the gold linker) and LLVM (with the gold or Darwin linker, or LLVM's prelinker).

But LTO is not something you enable during development.

You don't consider code generation from IL to be compiling? To me a linker is just a thing that links object code. The compiler is now split across two components (the "so-called-compiler" and the "so-called-linker") while the "so-called-linker" has both compilation and link-related functions. I think it's open to interpretation.

C++ headers tend to be heavier due to templates. Check out Doug Gregor's talk on Modules at the LLVM Developer's Conference for some numbers.

One of the proprietary (and paid-for in significant dollars) C++ compilers/linkers on Silicon Graphics (I can't remember the product name or version number offhand) in the mid 1990s handled templates with the help of an intermediate database. Based on information in object files (where template functions, etc were called) the linker would instantiate the templates by emitting object code using relevant information from the database. According to the documentation, function inlining was also done in the link phase, rather than when compiling.

Well, the interpretation in the documentation for that particular product characterised it in the way I described.

Depending on how you tie down the definition of a compiler, a linker is just a specialised compiler (with inputs being object files and libraries, and outputs being files in some executable formats) anyway.