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.
folks who continually reply with "RTFM" are immune to any suggestions / request to stop such behavior
That may be because that is the best answer. It is up to you to demonstrate that you have actually read what was recommended. The above question and its predecessor are two cases in point, where the answer was simply to read the documentation.
To add to Richard's comments about the manual. Very often the manual, or the resource suggested (e.g. cppreference.com) has a clearer and more accurate description of what's going on than the respondent could give "from scratch", as it were. If you've actually read the manual and/or consulted the suggested resource and don't understand the description given, you might be a bit more explicit about that. Which question would you be more likely to respond to?
I have a problem with widgets. Don't tell me to RTFM. I need an answer!
I'm looking at the manual for widgets and it says blah. I don't understand the part about bippity-bah, and my google-fu has failed me. Does bippty-bah mean that a widget needs to be frobincated, or does it do that when it's constructed?
Someone had to RTFM ... all your rant telegraphs is that you're above it and expect someone else to give you the Cole's Notes version. Your attitude makes anyone that actually knows anything not bother because they're not interest in your (negative) responses.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I totally understand you must be frustrated but look at it from the perspective of someone new seeing your post. Can't say I'm thrilled to spend time looking into your issue given the tone. And you may be 100% correct. I don't know. All we can see is someone was told to read a manual and they're upset. This same person couldn't even be bothered with filling out a name for their account.
Wish you the best buddy. It can be frustrating. Just hope you see it from our perspective.
So we're going way back in time here. Windows Embedded Compact 7 and maybe, just maybe one of the old timers have seen this. Searches via google have proved fruitless, as I think MS siloed all their data into their own websites. I cannot even find info there - it's all archived.
I support a WEC7 application. The OEM's old panel OS works reasonably well, but they had to change the hardware. As a result, they need to rebuild the OS image according to the new hardware. They're eating the learning curve, so to speak - it's a completely new team.
Setting aside random exceptions I'm working through, I keep getting this error in debug: "ERROR!!! calling xxx_GetProcessIndexFromID". Searching all of the mfc code supplied with the SDKs yields nothing. At first, I thought it was an ActiveX control thing (yeah, we're going that far back), but I've created a simple default dialog with a standard mfc pushbutton - and I get 21 of these errors.
Ever seen this?
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
i've been working w/ C++ includes lately . whilst examining those utilized in llvm i examined several h header files and found they are not templated and are not merely a declaration but a definition containing code and to my surprise are included in several cpp source files . closer examination revealed they define classes only which i suppose is okeedokee to include in multiple cpp files however does this not result in code bloat as each source must now generate the binary for each class's implementation . in my own work i insist placing the implementation of any non-templated class in it's own cpp source file and let the linker sort it out. i assumed this was sine qua non . is there something i do not understand as the writers of llvm are of course much more knowledgeable/experienced/clever/intelligent than myself . thank you kindly
Lately, it seems to be a move toward header-only libraries. Most probably, this is a reaction to Dependency hell (I'm a survivor of "DLL hell"). As each project has more and more dependencies, it becomes more difficult to make sure binaries are built properly and consistently and the easiest way out is to put everything in header files as inline functions and let compiler deal with it. This makes horrendous compile times and is clearly not a scalable solution, but for the time being, that's the way the cookie crumbles.
Last Visit: 31-Dec-99 18:00 Last Update: 29-Sep-23 7:35