Normalize the angle to <= 90 (right angle triangle); calculate the opposite and adjacent sides; offset origin x by (int) adjacent, and origin y by (int) opposite.
"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
Hello this is Gulshan Negi
Well, I want to know about how C and C++ differ in terms of their memory management and performance capabilities, and what strategies can be used to optimize code and improve performance in each language?
I need some suggestions on this.
Write a C program to Count the Lines, Words and Characters in a given text
*Write a C program to count the lines, words and characters in a given text.
*At the time of execution, the program should print the following message on the console as:
*Enter lines of text (enter END to complete)
For example, if the user gives the input as:
Enter lines of text (enter END to complete)
CodeTantra developed a Robotic tool
In the year 2016
then the program should print the result as:
Character = 51, Words = 9, Lines = 2
Note: Do use the printf() function with a newline character (\n) at the end
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
a blank then set was_blank = 1;
not a blank then, depending on the was_blank flag increment the word count (or do nothing), eventually clear the flag: was_blank = 0;
"In testa che avete, Signor di Ceprano?"
#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: