CODEWITHSUNDEEP
c++compilation
Jersey
Jersey

Reputation: 433

C++: When is the need to recompile problematic?

Under which circumstances is the necessity to recompile your code a problem?

I'm an interested layman without any professional coding experience trying to improve my understanding. The articles and books I'm using repeatedly deal with situations when the application of certain coding habits or design choices increases the likelihood of the need to recompile the program. The authors are clearly concerned about this but unfortunately they never explicitly explain the underlying problem.*

This question may seem obviously silly for any software professional but in none of my private coding endeavors was the necessity to recompile a true concern. I suspect that a certain context is needed for this to pose a real-world problem and I kindly ask any experienced software engineer to provide enlightenment for the ignorant.

Thank you.

* E.g. Scott Meyer's Effective C++: Item 30 about inlining

Upvotes: 1

Views: 83

Answers (1)

2785528
2785528

Reputation: 5566

A single topic history lesson:

In some languages, programmers (with certain kinds of experience) can learn that simply appending fields to an existing message has no impact to existing code. Any code which does not use any of the new fields does not need recompilation. This is not true for C++.

The same team might also capture these messages into a single 'message' file, because changing one message will have no impact on the others, adding a new message will only affect the code that uses it. Again, not so for C++.

In C++ changing any aspect of a single message (field name, size, field type, naming, etc) in a file of N messages, will trigger a recompile of all .cc files that include the file-of-N-messages.

On one large C++ project to which I contributed (100+ contributors at our site), an early morning complete build might finish in about an hour.That build was distributed across many processors (but shared by the team). By noon, the complete-build duration was typically more than 3 hours.

Environment note: A 1 to 3 hour build time is almost as pain full as sharing limited lab equipment (i.e. a sign-up for access, wait-for-your-turn, etc) upon which to debug the change.

Under which circumstances is the necessity to recompile your code a problem?

The edit-compile-test-debug cycle-duration dominates programmer productivity. It is a problem when this cycle-duration is large / slow.

For the large C++ project, we learned to merge (other submissions) at end-of-day, then launch a build and hope it completes by morning (often did not).

During the day (late morning thru end-of-day, you build only small changes, debug the work, and postpone the 'merge' of your code into other contributers code. That effort continues to grow.

During the day, (after early morning) you simply can not merge and complete a rebuild of the system for debugging your contribution.

This is the problem ... delivering working code is what a contributor is supposed to do.

For comparison:

At my home desktop, I can switch windows and completely rebuild the largest of my projects in a few minutes. Most of my apps cycle-durations are < 1 minute.

Upvotes: 1

Related Questions