To add to what Mircea has said, you may even include empty blocks e.g.
compiles without complaint.
While that seems rather silly, source code like that might be generated when a pre-processor #define is expanded or perhaps if you have some sort of code generator as part of the build process. e.g. something like Oracle Pro*C, or Postgresql ecpg.
It's because #ifdef is a preprocessor statement and the the preprocessor requires the #ifdef and the #endif to be on separate lines. What you could do is use Find/Replace to convert all qDebug calls to Debug (or some other unique name), and then add something like the following at the top of you source, or in a common header:
would put a pair of #ifdef/#endif on any line containing qDebug. Obviously replace source.cpp with your source file.
Translated into English, the script says: if line contains the string qDebug, print a line with #ifdef DEBUG, then print the line in question, then print a line with #endif. If line doesn't contain the string qDebug, just print it. The resulting output is put in file new_source.cpp
If you can get Notepad++ working on Linux through Wine, as per this page, you can record a script in it to do the job. Don't know how difficult it will be to do across multiple files, as far as opening them individually goes, but the script can be assigned a keyboard shortcut to make it easier. You can also use extended characters to search and replace every occurrence without having to trigger the macro for each instance in the file.
You can groupt include statements into a single header file which is then included in every module that requires them. But you should avoid including headers that are not required as that just adds to compilation time. And if you are building for Windows with Visual Studio you can use the "Precompiled Headers" option to make it faster. I do not know whether g++ has a similar option.
As mentioned elsewhere, include statements have nothing to do with make files.
g++ will create pre-compiled headers quite simply: g++ foo.hpp creates a foo.hpp.gch, and the compiler will search for a .gch file when processing a #include directive. If necessary, you can include -x c++-header flags to indicate to the compiler that the named sources are to be treated as header files rather than program source code. Also note that some compiler flags need to match for both PCH and source code. More details here: Precompiled Headers (Using the GNU Compiler Collection (GCC))
I'd say it doesn't matter. There are pros and cons to each solution. If you make it part of the main object you have fewer global/high-level objects but every time you access the configuration you go through the main object. This means at least more typing. If you make it a separate (global) object, the opposite is true.
My own take: some years ago I was going with the config as part of the main object for reasons of "code purity". These days I go with a separate object for pragmatic reasons.
Some objects require knowledge / access of / to previously configured objects
That is basically an incorrect way to think of that unless you stated it incorrectly.
You have class A1 which can have an instance a1. Now a1 not A1 is the only thing that is 'configured'.
Then there is class B1 which has instance b1. And instance b1 needs access to a1. Note that b1 does NOT have access to the configuration for a1. It should not even know that a1 is 'configured'.
Conversely if b1 needs access to the same configuration information as a1 then the configuration information should not be limited to a1 but should be generic.
As an example if you have UI objects that represent a Box and a Button and both use a 'configured' color X then you would call that X something like 'outline.color.border'. You would not call it 'Box.color.border'
Now AFTER you figure out the hierarchy of the configuration data then you figure out the best way to manage it.
Generally you would have a parallel set of configuration objects which in some way are related to each other and which expose the loaded configuration data.
C#, as one example, has a dynamic class structure which supports creating from configuration files. But the same thing can be achieved (and perhaps is easier to understand) just by have one class with a method that takes a name and returns a value.
But regardless the configuration object (or objects) is entirely independent from the classes that use the configuration.
As a reminder do not forget about error handling and default values. If the configuration file is not found or a configuration value is missing (because it is misspelled) then what do you want the application (and objects) to do.
So here is my latest attempt to resolve it and I sill need some real help , no RTFM PLEASE.
Just noting that many years ago I would spend time on a specific forum for the Perl language.
One of the leading authorities and author/co-author of a number of books would attend.
And his answers often were RTFM and sometimes (or often) ranting about it quite a bit.
So not much you can do about complaining about the quality or type of answers that you get. Although you might want to point out in any such question, explicitly, that you already did do some research but you did not find anything that actually answered the question. That might stop such answers.