When designing a compiled programming language, is it a bad idea to require a specific order of compilation of separate units, according to their dependencies?

To illustrate what I mean, consider C. C is the opposite of what I'm suggesting. There are multiple .c files, that can all depend on each other, but all of these separate units can be compiled on their own, in no particular order - only to be linked together into a final executable later.

This is mostly due to header files. They enable separate units to share information with each other, and thus the units are able to be compiled independently.

If a language were to dispose of header files, and only keep source and object files, then the only option would be to actually include the unit's meta-information in the unit's object file.

However, this would mean that if the unit A depends on the unit B, then the unit B would need to be compiled before unit A, so unit A could "import" the unit B's object file, thus obtaining the information required for its compilation.

Am I missing something here? Is this really the only way to go about removing header files in compiled languages?


3 Answers 3


One possible way is to generate metadata ("header files") for each compilation unit first. This normally does not require any dependency and can be performed independently.

Then when actual do type checking/code generation, each compilation unit can refer to other's metadata to get type information.

Otherwise you will have problem if unit A import unit B and unit B also import unit A, you cannot compile any of them without compile other one first.


The approach you're describing is what languages like Java and C# do. Instead of header files, the metadata is compiled into the object file. Those languages also don't compile each source file in a module (a .jar or .dll) separately; they take all the source files that make up a project and compile them all together, and then link them into an executable or library.

A consequence is that the modules' dependencies will dictate the compilation sequence. If module B depends on (references) module A, then module A must be compiled and linked first, so that module B can reference the metadata when it gets compiled. If classes in those modules really have a circular reference to each other, then those classes must be in the same module.

It's hard to see another approach. The linker needs to know the metadata of a compiled module, so that information has to be available somewhere. Either it's in source code, like a header file, or it's in the object code.

  • A language could specify that a compiler must be able to handle the interface-related aspects of all the files in passes, such that each stage only requires upon the result of previous passes of compilation for other files. The first pass might figure out what type names get defined in each file, the second define each type in terms of forward-defined types, etc.
    – supercat
    Dec 25, 2013 at 3:31

Yes, it's a bad idea although it's very common.

For situations where the application is spread across multiple source code files that potentially share cyclical dependencies, there is absolutely nothing preventing a compiler from reading and compiling all the source code together to avoid order sensitivity. Such a compiler should also offer incremental compilation to reduce compile times when small changes are made.

For other situations where there are libraries or components that are not to be recompiled, and are not dependent on client applications, the compiler should read meta data from the binary, generated by a previous compilation. There are dependencies, but they are natural and not a problem.

As it happens the above is not very far from what actually happens in C# and Java. Dependencies do arise at times, and it would be nice if they didn't.

The C++ header arrangement is truly awful, but we're stuck with it. No modern language designer would commit that crime again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.