QuantumC

Multi File

Back to Home

Including

Ok, time to info dump. Quantum C has a Very confusing but Very Intresting and Very Powerfull include system. In Quantum C, you include with the syntax:

namespace Exported {
    #include <namespacename, path/to/file>
}

Let me break this down step-by-step. First, the line that actualy includes: #include.

In Quantum C you do not include files. instead, you include namespaces FROM files. You cannot include code from the global scope in Quanrum C, like the main function. You can only include namespaces from files.

Now, there are Certanly at least 2 people saying “Oh but what if we want to use the global scope instead of this namespace for X or Y reason, like DRY code?”. Quantum C has a answer for this. Introducing, the Exported namespace.

The exported namespace is a top level namespace That’s right Top level. That means that you MUST put the exported namespace without nesting. This is because it breaks all forms of nesting and dependancy logic, so it must be the First thing in the file. Not the first top level thing: the FIRST THING PERIOD What goes in the exported namespace, you may ask? The answer is 3 things.

• Global variables (semi global. You access them with Exported::thing)
• Global functions (same as above)
• Include statements.

Just to restate this:

The Exported namespace MUST:

• Be the _Very First Thing in the file other than comments.
• NOT be nested in any other namespaces

The Exported namespace may only contain:

• Global variables (E.G: Exported::name)
• Global functions (E.G: Exported::get_stats())
• #include statements

The exported namespace is Automatically merged with your exported namespace on include and run The reason for include statments going in the exported namespace? Dependancys. Let’s say we have 3 files.

file-a.qc

namespace Exported {
}
namespace Thingy {
    // blah blah blah
}

file-b.qc

namespace Exported {
    #include <Thingy, ./file-a.qc>
}
namespace OtherThingy {
    // blah blah blah
}

file-c.qc

namespace Exported {
    #include <OtherThingy, ./file-b.qc>
}
// blah blah blah

See the problem that would happen if includes were not in the Exported namespace? Because file-b uses file-a, if you included file-b and it didn’t have the include from file-a in it’s exported namespace, it wouldn’t be included, most likely breaking all the code in file-b, which is why we put it there. The resolve order in the above would be:

Include stack is [] See file-c Exported namespace In exported of file-c see include for OtherThingy of ./file-b

Scan file-b for OtherThingy and Exported namespace Merge the file-b exported namespace with file-c exported and save the include to a stack (include stack is now: [OtherThingy -> file-b]) In merged exported: see include for Thingy of ./file-a.

Scan file-a for Thingy and Exported Merge Exported and push Thingy to stack (stack is now: [Thingy -> file-a. OtherThingy -> file-b]) Proccess Exported and see nothing new.

Pop include stack and proccess Thingy Include from file-a. (include stack is now: [OtherThingy -> file-b])

Pop include stack and proccess OtherThingy Include from file-b. (include stack is now: []) Include stack is now empty. No more includes. Runs code.

The list of namespaces would be in this order:

namespace Exported (file-c)
namespace Exported (file-b)
namespace Exported (file-a)
namespace Thingy
namespace OtherThingy
file-c code