|
This is your assignment, so you are expected to do the work. If you do not understand the assignment then you need to ask your teacher for guidance.
|
|
|
|
|
Read a line, fgets[^] is your friend.
If the line read is exactly END than your task is complete: report the line, word and character count.
On the other hand, if the line read is not the termination one, then increment the line count, and get the first character (incrementing the character count): if it is a blank then set a flag was_blank = 1; and go on. If it is not a blank then increment the word count and clear the flag: was_blank = 0; .
Go on with the next character (if any): increment the character count and if the character is
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
There is no simple answer to such a question as the lifetime of a variable will depend on its usage and requirements. You need to analyse your code to decide what is best in each specific case.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Easy peasy
#include <stdargs>
void ProcessCommand (char* command, ...)
{
va_list params;
va_start (params, command);
int narg=args_count(command);
for (i=0; i<narg; i++)
{
QString* pstr = va_arg (params, (QString*));
}
va_end(params);
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)
{
}
}
Mircea
|
|
|
|
|
This article can probably explain it a lot better than I can. In particular I did not know that the argument before the ellipses must not be something that is eligible for default parameter promotion (e.g a float, which gets promoted to double).
Modern C++ and Variadic Functions: How to Shoot Yourself in the Foot and How to Avoid 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
Keep Calm and Carry On
|
|
|
|
|
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.
|
|
|
|
|
Besides the other answers you might want to ask how many of these would be reasonable in the next 5 years of using this method.
So if you start with 2 now and there are 4 in 5 years ok.
But if you start with 2 now and in three months there are 20 then that is a problem. In that case a collection of some sort is better.
|
|
|
|
|
" in three months there are 20"
Nah, they're on to the next project.... who cares about code maintenance?
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.
|
|
|
|
|
|
It still requires enforcing correct usage which can only occur via discipline and/or careful code reviews.
And if you are doing that then you shouldn't have a problem in the first place. More careful designs can also reduce the problem.
|
|
|
|
|
My thoughts exactly. Seems more trouble than it's worth.
Mircea
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
It's not wrong. Empty statement is a valid C/C++ statement. You can try:
;;;;
Also, a very popular beginner mistake is to add a spurious semicolon at the end of a while and wonder why the while "body" is not repeated:
while (i>0); {
}
Mircea
modified 1-Mar-23 14:07pm.
|
|
|
|
|
|
Aren’t we all beginners constantly trying to learn new things? Do you think I saw that error in a book?
Mircea
|
|
|
|
|
To add to what Mircea has said, you may even include empty blocks e.g.
int main()
{
{}
std::cout << "Hello World!\n";
{}
}
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.
Keep Calm and Carry On
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
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
|
|
|
|