|
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:
#ifdef DEBUG
#define Debug qDebug
#else
#define Debug
#endif
|
|
|
|
|
Copy the following in a file called script.awk
/qDebug/ {
print "#ifdef DEBUG"
print $0
print "#endif"
}
!/qDebug/
Then a command like
awk -f script.awk source.cpp >new_source.cpp 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
Good luck!
Mircea
|
|
|
|
|
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.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Create your own Debug class to do it, and change all the qDebug calls to call your class. Then inside your class you can pass the text to qDebug itself, and to your textbox.
|
|
|
|
|
That is C++, not C.
I show you how it could be handled in a similar scenario:
#include <iostream>
#include <sstream>
using namespace std;
#define STD_DEBUG
#ifdef STD_DEBUG
#define DBG(txt) cerr << txt
#else
#define DBG(txt) \
do { \
ostringstream os; \
os << txt; \
string s = os.str(); \
cout << "The debug string: " << s; \
} while (0)
#endif
int main()
{
DBG("foobar = " << 42 << "\n");
}
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
