[CamperBob2]

How exactly does a compiler generate "riskier" optimizations from a single-header as opposed to separate translation units? I fail to understand how after the pre-processing phase, this would be less safe.

For instance, the optimizer might conclude that it's safe to either elide an inline function call or compile it very differently if it sees that you're referring to the same object in two separate parameters.

If the function is implemented in a separate file, the optimizer has to assume that the function does something it doesn't know about.

[printf_kek0]

Thank you. Please indulge me if you have time with two more questions:

1. In some libraries (SQLLite for instance, and libev too I think) the authors have a script that "amalgamates" all sources into a single translation unit.Their reasoning being that a compiler with full-visibility of the source can do global / interprodecural optimization that would not be possible otherwise. Is there any sense in this if it practical to do so for a small to moderate size library?

2. Please tell me what I should read so I can reach the same level of understanding that you have. <not a question>

[CamperBob2]

1. It's almost certain that the speed increase you'd get from intentionally merging a lot of source files into one is less than what you could achieve with a more intelligent profile-based refactoring approach. I wouldn't have a very high opinion of the approach you describe, not knowing any more about those libraries or their authors' motivations.

2. Read a lot of C code written by people like Sean Barrett. You would just pick up a lot of bad habits from mine. :)