#include<stdargs>void ProcessCommand (char* command, ...)
va_list params; //opaque structure needed to process variable arguments lists
va_start (params, command); //initialize with the last fixed argument before ellipsis
// You need to know how many arguments to expect. Assume that args_count function tells you that
// args_count is your function not some standard function
for (i=0; i<narg; i++)
//Get next argument
QString* pstr = va_arg (params, (QString*));
// do something with the string
One of the problems with this code is that you need to know how many arguments to expect and the type of each one. Functions like printf explore format string and figure out from the '%' specifiers. There are countless stories about bugs occurring because they don't match. Sometimes, specially if your arguments are of the same type, you can add a count parameter just before the variable part:
void ProcessCommand (char* command, int count, ...)
Another thought: if you know that all parameters are of the same type, why not pass an array. Something like this:
void ProcessCommand (char *command, std::vector<QString*> verify)
for (auto& pstr : verify)
//do something with it
You should take note of the discussion of how the variadic function determines how many arguments it has.
I also have an idea that stdargs may not be the preferred way to write a variadic function in C++ any longer. There's a tickle in the back of my brain that perhaps variadic templates are a better way to go. If you're interested in that, check out Jason Turners C++ weekly episodes on You Tube: C++ Weekly - Ep 6 Intro To Variadic Templates - YouTube
It dpends om what type the extra parameters are. If they are all the same (e.g. all ints, chars etc.) then you are better using an array or a C++ container. But if you are passing a variable number of varying types then you need some way of identifying which type each parameter is. In the C library printf/scanf functions this is done with the format string, where each control item in the string tells the function what type to expect for the corresponding variable.
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))