jacob navia <email@example.com> wrote:
Traditionally, main.cpp contains command line parsing. You have the
argv, argc data, and it is the right place to do that.
If the complexity of the command line parsing is relatively simple
(personally I would put a limit of about 100-300 lines of code) then
that's indeed the case.
However, if and when the values that got parsed need to be transferred
to other modules, you either give these values to those modules when you
call them, or if this results in too much complexity with some of the
values (usually because they are needed by a large amount of separate
independent modules, many of them not called directly from main()),
you create a separate module for these system-wide settings, and pass
the command line values to that. (Obviously it's this system-wide settings
module which has a public interface, declared in its own header file.)
The simplest and most straightforward way of implementing the latter
is to simply have, for example, a header file named like Settings.hh
which contains either a namespace or a class named 'Settings', which
contains these system-wide values. The main function (or whatever function
parses the command line in main.cc) can pass the necessary values to this
'Settings' modules, from which other modules can then read them.
The reason why having a "main.h" file should intuitively feel wrong is
that it usually creates circular dependencies (ie. the 'main' module
depends on another module, which in turn depends on "main.h"). If you
have a separate "Settings" module, no circular dependencies are formed.
(And with "circular dependencies" I'm not talking about complications
in getting the program to compile. That's not the issue. I'm talking about
program design. While circular dependencies between modules is not something
to religiously avoid, they should nevertheless be minimized if possible.
It keeps the design simpler and the modules more independent.)