StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The conventional way of achieving that would be to place the source code for each module into a separate directory. Each directory can contain all the source and header files for the module.</p> <p>The public header for each module can be placed into a separate, common directory of headers. I'd probably use a symlink from the common directory to the relevant module directory for each header.</p> <p>The compilation rules simply state that no module may include headers from other modules except for the headers in the common directory. This achieves the result that no module can include headers from another module - except for the public header (thus enforcing the private barriers).</p> <p>Preventing cyclic dependencies automatically is not trivial. The problem is that you can only establish that there is a cyclic dependency by looking at several source files at a time, and the compiler only looks at one at a time.</p> <p>Consider a pair of modules, ModuleA and ModuleB, and a program, Program1, that uses both modules.</p> <pre><code>base/include ModuleA.h ModuleB.h base/ModuleA ModuleA.h ModuleA1.c ModuleA2.c base/ModuleB ModuleB.h ModuleB1.c ModuleB2.c base/Program1 Program1.c </code></pre> <p>When compiling Program1.c, it is perfectly legitimate for it to include both ModuleA.h and ModuleB.h if it makes use of the services of both modules. So, ModuleA.h cannot complain if ModuleB.h is included in the same translation unit (TU), and neither can ModuleB.h complain if ModuleA.h is included in the same TU.</p> <p>Let us suppose it is legitimate for ModuleA to use the facilities of ModuleB. Therefore, when compiling ModuleA1.c or ModuleA2.c, there can be no issue with having both ModuleA.h and ModuleB.h included.</p> <p>However, to prevent cyclic dependencies, you must be able to prohibit the code in ModuleB1.c and ModuleB2.c from using ModuleA.h.</p> <p>As far as I can see, the only way to do this is some technique that requires a private header for ModuleB that says "ModuleA is already included" even though it isn't, and this is included before ModuleA.h is ever included.</p> <p>The skeleton of ModuleA.h will be the standard format (and ModuleB.h will be similar):</p> <pre><code>#ifndef MODULEA_H_INCLUDED #define MODULEA_H_INCLUDED ...contents of ModuleA.h... #endif </code></pre> <p>Now, if the code in ModuleB1.c contains:</p> <pre><code>#define MODULEA_H_INCLUDED #include "ModuleB.h" ...if ModuleA.h is also included, it will declare nothing... ...so anything that depends on its contents will fail to compile... </code></pre> <p>This is far from automatic.</p> <p>You could do an analysis of the included files, and require that there is a loop-less topological sort of the dependencies. There used to be a program <code>tsort</code> on UNIX systems (and a companion program, <code>lorder</code>) which together provided the services needed so that a static (<code>.a</code>) library could be created that contained the object files in an order that did not require rescanning of the archive. The <code>ranlib</code> program, and eventually <code>ar</code> and <code>ld</code> took on the duties of managing the rescanning of a single library, thus making <code>lorder</code> in particular redundant. But <code>tsort</code> has more general uses; it is available on some systems (MacOS X, for instance; RHEL 5 Linux too).</p> <p>So, using the dependency tracking from GCC plus <code>tsort</code>, you should be able to check whether there are cycles between modules. But that would have to be handled with some care.</p> <p>There may be some IDE or other toolset that handles this stuff automatically. But normally programmers can be disciplined enough to avoid problems - as long as the requirements and inter-module dependencies are carefully documented.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload