|
I think you'll have to explain in more detail what you want to accomplish.
Makefiles and include files are not directly related. Makefiles are "recipes" used to compile and link a binary. You write something like:
module1.o : module1.cpp inc1.h inc2.h
gcc $(CFLAGS) -o module1.o module1.cpp That would tell make that module1.o object file needs to be recompiled every time any of module1.cpp or inc1.h or inc2.h files changes and what is the command to compile it.
Mircea
|
|
|
|
|
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.
modified 15-Feb-23 5:18am.
|
|
|
|
|
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))
Keep Calm and Carry On
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
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.
Mircea
|
|
|
|
|
Presuming that I understand what you are saying.
Member 14968771 wrote: 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.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
No that doesn't help at all. Making it as simple as I can...
There is a set (one or more) objects that use the configuration.
There is another set (one or more) objects that manage the configuration (lets say read it from a file.)
The two sets must not be the same.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
The part in <> should be a type and the compiler is complaining that it doesn't know what data_list is. If it is a type, make sure you include the correct header so that it can be found.
If what you actually meant was for data_list to be the name of the function argument, it should be more like this:
explicit Form_SetupLocalAdapter(QList<*DataListType> data_list);
- replacing DataListType with the type (or base type) of data_list.
|
|
|
|
|
|
You probably meant something similar to
explicit Form_SetupLocalAdapter(QList <QString> * data_list);
(where the type you're actually storing in the list should replace the QString in the angular brackets)
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Member 14968771 wrote: 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.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: 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!
or:
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?
Keep Calm and Carry On
|
|
|
|
|
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
|
|
|
|
|
Gerry Schmitz wrote: our attitude makes anyone that actually knows anything not bother
Correction. It makes some of them not bother.
|
|
|
|
|
Member 14968771 wrote: are immune to any suggestions / request to stop such behavior ,
Except I said nothing about that.
Repeating what I said again, and what others said, is that you should point out what you already did (what part of the documentation you read) as part of your original post.
|
|
|
|
|
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.
Jeremy Falcon
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: you and everybody else have a choice to ignore it and you are not my mother to criticize my "tone".
Ok cool. You're a child and you'll never get help from me in the future. Enjoy your tantrum.
Jeremy Falcon
|
|
|
|
|
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?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
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.
Mircea
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
