Problem with if statment

[almor3ebx2]

Hi

I've been programming a simple code recently and I kept receiving an error with if-statement.

expected identifier before '(' token

Any help?

[SuperSonic]

Whenever you have an if statement, you must surround the expression with parenthesis like this:
if(expression)

If, however, you would like multiple expressions, they must both be surrounded by another set of parenthesis:
if( (expression1) && (expression2) )

However, you are writing your if statement like this:
if (expression1) && (expressoin2)// You are missing a set of parenthesis.

Does that help any?

[TheIdeasMan]

I would have done this:

double Total = wid + giz + gen;

if( (Total >= 100.0) && (Total < 200) ){}

The introduction of new variable makes it much easier, and there is no need for parentheses around individual variables.

You should also be careful comparing floating point values, they aren't an exact representation.

Consider having a ShowMenu function.

Just another minor point - rather than put lots of code into case clauses, have your program call a function instead:

bool Quit = false;

while(!Quit) {
switch (choice) {
      case 1:
               //call function PurchaseWidget
                break;
      case 2:
               //call function PurchaseGizmo
               break;
      case 3:
               //call function PurchaseGeneric
               break;
      case 4:
               //call function PrintReceipt
               break;
      case 5:
               //Exit without doing anything
               Quit = true;
               break;
      default:
               //Invalid selection
                 break;
}//switch  I am too lazy to indent properly
} //while

return 0;
} //end of main

Also, cout statements don't have to be all on one line - you can split them up and still have the same effect.

HTH

[SuperSonic]

I would have done this:

double Total = wid + giz + gen;

if( (Total >= 100.0) && (Total < 200) ){}

It's better to use a calculation in place of a variable whenever possible. However, if you want to make your code shorter, you can use #define:

#define TOTAL (wid + giz + gen)

if((TOTAL >= 100.0) && (TOTAL < 200)) {...}

It would be just the same as writing:
if(((wid + giz + gen) >= 100.0) && ((wid + giz + gen) < 200)) {...}

[jim80y]

I believe it's better to always use a calculation instead of a variable if possible. To make code shorter, I like to use #define:

#define TOTAL (wid + giz + gen)

if((TOTAL >= 100.0) && (TOTAL < 200)) {...}

I'd prefer the variable every time. Doing it with a #define as per your example forces the re-evaluation of the expression represented by TOTAL. In this example it's not too bad, but consider the following (admittedly convoluted) example:

#define TOTAL (wid + (giz++) + gen)

if ((TOTAL >= 100.0)&& (TOTAL < 200)) {...}

After the if statement, giz has been incremented twice, and the two TOTAL values used in the if were different. It's obvious here, but what if giz was a function call?

You have to be very careful when using #define
Plus, the use of the variable will be optimised out by the compiler anyway.

Jim

[SuperSonic]

In this example it's not too bad, but consider the following (admittedly convoluted) example:

True, but in that case, you are doing more than just making a calculation. You are actually changing the value of a variable. In that case,you could store the result in a variable. However, when you are just adding variables together, or doing a simple calculation, it's better to use a function call or #define statement (I geuss it's really a personal preference).

[jim80y]

I did say it was convoluted ;-)

How about if that function performs some complex database operation, or some other operation that takes a long time? Then it's way more efficient to assign the result to a local variable than calculate the thing twice. And you won't always know what's going on internally.

Jim

[SuperSonic]

I did say it was convoluted ;-)

Haha, indeed.

How about if that function performs some complex database operation

Well, if you're working with a database, then it's usually best to retrieve your data from the database and then store it in variables (that's the long part). Then you can use a function to do calculations with those variables.

or some other operation that takes a long time

That's the one situation I can think of where you would store the results in a variable. However, I've never come across a pure calculation function that takes a long time.

[TheIdeasMan]

SuperSonic wrote:

It's better to use a calculation in place of a variable whenever possible

Not always. Consider what happens in a loop, the small number of instructions required for an assignment is better than the same number of instructions multiplied by how many times it loops.

It also goes back to code readability & ease of understanding. For a single if statement, what is the worth of worrying about a few instructions for assignment versus easy reading of the code.

I agree with Jim.

[SuperSonic]

It also goes back to code readability & ease of understanding.

Like I said before,

if you want to make your code shorter, you can use #define:

Again, it's really a personal preference. There's no "right or wrong" way to do something. There are just different ways to go about doing it.

[jim80y]

There's nothing wrong with #defining an equation to simplify code. What is 'wrong' is when you repeatedly use that #defined equation to re-calculate some figure, instead of doing it once and re-using the result.

Would you write the following code?

// This takes ten seconds to perform
double Calc();

if (Calc() >= 0.0 && Calc() < 1.0)
{
  // something
}
else if (Calc() >= 1.0 && Calc() < 2.0)
{
  // something else
}
else if (Calc() >= 2.0)
{
  // something else entirely
}

How long is that going to take if Calc() returns 3.0?

#defining the content of Calc() into a CALC macro and using that is exactly the same and will take 50 seconds for values >= 2.0

You would write it as

double v = Calc(); // or double v = CALC;

if (v >= 0.0 && v < 1.0)
{
  ...

[SuperSonic]

If you have a calculation that takes 10 seconds (or some insane time) to compute, then it's fine to put it in a variable. In fact, I stated that earlier

jim80y said:
or some other operation that takes a long time

I said:
That's the one situation I can think of where you would store the results in a variable. ..

However, almor3ebx2 is only adding three numbers together. Using your method would produce no noticeable time difference.

[jim80y]

I'm not talking specifically about this example, I'm talking about a general principal that can (and should) be applied across code in many situations - this is, after all, a beginners' forum where we're supposed to transfer our decades of experience, no?

It's all about maintainability, too.

What if, in the future, the definition of TOTAL changes to something more complex (and time consuming), or it's changed to have some side-effect on the data? It's far better to code with that in mind and not needlessly recalculate results.

<mild rant>
I guess what erks me is that the general consensus now seems to be, "Oh, CPUs are powerful enough, don't bother coding efficiently", and then everyone complains when software bogs down their shiny new PC. If we all optimised our code properly we could be running on much lower powered hardware.
</mild rant>

Jim

[SuperSonic]

What if, in the future, the definition of TOTAL changes to something more complex (and time consuming), or it's changed to have some side-effect on the data? It's far better to code with that in mind and not needlessly recalculate results.

That's true. Your code is bound to change in the future, and you must think about all the changes that might occur in advance. However, you also have to remember that the extent to which it can change is limited. All programs have a specific purpose, and no program will ever change its purpose. Photoshop will always be a photo editor, Code::Blocks will always be an IDE, etc. These programs undergo changes all the time, but their purpose remains the same. And so, there are boundaries to how much a program can change.

In this case, we know that the calculation may change and become more complicated, but (due to its purpose) will always remain a basic, arithmetic expression (It won't run loops, access a database, change data, etc). Since we know that, then we can assume that it's safe to put the expression in a function or macro. If the expression ever changes, we can go to wherever we #defined the macro or created the function and change it there.

One other thing I'd like to point out. You always want to avoid "stagnate" data. For example, let's say that we have a square class:

class Square
{
    public:
        unsigned int width, height;// I know this is a bad class, but it's just for demonstration purposes.
}

Let's also say that, at some point, we decide to add a function to calculate the area of the square. Let's also say that we use an 'area' variable to store the results so that we don't have to run the calculation several times when we want it's area.

class Square
{
    public:
        unsigned int width, height, area;
        unsigned int calculateArea() { area = width * height; return area; }// Again, I know this looks bad, but it's just an example.
}

The problem is that width and height are not constant variables. They may change later in time, and when/if they do, we'll have stagnate data. The area variable will no longer represent the true area of the square. If you wanted the real area, you would have to run the calculateArea() function again.

To avoid stagnate data, you may replace variables with calculations wherever possible. In this case, we can replace 'area' with a function.

class Square
{
    public:
        unsigned int width, height;
        unsigned int area() { return width * height; }
}

This way, you will never have stagnate data. Also, you know that this expression will never change, so you don't have to worry about that either.

<mild rant>
I guess what erks me is that the general consensus now seems to be, "Oh, CPUs are powerful enough, don't bother coding efficiently", and then everyone complains when software bogs down their shiny new PC. If we all optimised our code properly we could be running on much lower powered hardware.
</mild rant>

I agree with you on that too. However, you don't want to optimize your code too much or else, you get inefficient code.