NOP in 'C'?

How do I write a No Operation in 'C'?

The code looks like this.

Code:

---


(
if ((A == 1) && (B == 2)
{
    NOP;
}
else
if ((C == 3) || (D == 4))
{
  A = C;
  B = D;
}
)

---

Just don't do anything. (And for that matter, why even check? Why not go to the next case?)

The closest you can get is a null statement:

Code:

---

if ( condition )
  ;
else if ( condition ) {
  /* Do something */
}

---

Ideally, rewrite the code to not do "reverse checking" - instead:

Code:

---

if ((A != 1) && (B != 2))
{
  if ((C == 3) || (D == 4))
  {
      ... do stuff ...
  }
}

---

Alternatively, as one condition [you can array the values in any order, as long as the parenthesized expressions are retained]:

Code:

---

if (((C == 3) || (D == 4)) && (A != 1) && (B != 2))
{
  ... do stuff ...
}

---

--
Mats

What matsp has used there is De Morgan's laws

Basically if you ever have an expression formed of two sub-expressions, you can modify the expression as follows and end up with an expression that is exactly equivalent.
Negate both sub-expressions, change the operator between then from 'and' to 'or' or vice-versa, negate the entire expression.
E.g.
(a && b) gives (!(!a || !b))
(x>0 || y<0) gives (!(!(x>0) && !(y<0))) or better yet, simplify that to (!(x<=0 && y>=0))
!(!c || d==42) gives !!(!!c && !(d==42)). Remove the double !'s and simplify to (c && d!=42)

The other useful transformations here are to go from:

Code:

---

if (a) {
    if (b) {
        foo();
    }
}

// to

if (a && b) {
    foo();
}

---

or from:

Code:

---

if (a) {
    foo();
}
else if (b) {
    foo();
}

// to

if (a || b) {
    foo();
}

---

Quote:

---

Originally Posted by tabstop

Just don't do anything. (And for that matter, why even check? Why not go to the next case?)

---

The next case is an else. The point of the code is if the first statement is true, then nothing happens. The else statement is not executed.

Maybe by making the inverse of the first statement anded with the second is a way to handle it.

I like the Null Statement as Prelude suggested best. I can comment it and have readable code, where DeMorganizing it makes the code unreadable.

Quote:

---

Originally Posted by danlee58

The next case is an else. The point of the code is if the first statement is true, then nothing happens. The else statement is not executed.

Maybe by making the inverse of the first statement anded with the second is a way to handle it.

I like the Null Statement as Prelude suggested best. I can comment it and have readable code, where DeMorganizing it makes the code unreadable.

---

I suggested a form that is not unreadable, I beleive.

In my programming life, I have never used a null-statement in a if-statement [aside from when macro expansion turns statements into nothing]. It's a bit like starting a statement with the excpetion, like this "except for ice-cream, our deserts are served warm". It is better (more straightforward and clear) to say "all our deserts are served warm, except ice-cream". If you want something to happen only when a != 1 and b != 2, then say so. Don't say "if a = 1 and b = 2 do nothing, else do ..."

If you feel you must do that, then make sure you make a comment, like you say.

--
Mats

You don't have to actually apply demorgan's rules if they make the code less clear. Just but the condition in parens and use !, as in :

Code:

---

(
if ( !( (A == 1) && (B == 2) ) && (C == 3 || D == 4))
{
  A = C;
  B = D;
}
)

---

Or if there are additional else's:

Code:

---

if (  !( (A == 1) && (B == 2) )  )
{
  if(C == 3 || D == 4))
  {
    A = C;
    B = D;
  } else ...
)

---

Well, my Compiler doesn't seem to like a Null IF statement, unless I'm using the wrong braces.

matsp, Your suggestion is not unreadable, but this a very complex nested IF-ELSE. The code that I showed was a simplified example. The execution has to exit the IF-Else at several points where a condition is true, but continue to fall through where conditions are false. I'm concerned that I'll never get it right if I make too many changes to the Intuitive statements.

I might have to do that, if the Compiler doesn't accept the Null If.

Quote:

---

Originally Posted by danlee58

The execution has to exit the IF-Else at several points where a condition is true but continue to fall through where conditions are false..

---

Isn't that just the logical flow? Also, in your first example you are not doing anything of the sort. If you want to exit, break. Otherwise the apple hits the ground. The NOP is definitely a no-op...

Quote:

---

Originally Posted by danlee58

Well, my Compiler doesn't seem to like a Null IF statement, unless I'm using the wrong braces.

matsp, Your suggestion is not unreadable, but this a very complex nested IF-ELSE. The code that I showed was a simplified example. The execution has to exit the IF-Else at several points where a condition is true, but continue to fall through where conditions are false. I'm concerned that I'll never get it right if I make too many changes to the Intuitive statements.

I might have to do that, if the Compiler doesn't accept the Null If.

---

If your compiler doesn't accept ; as the true part of an if, it is extremely extremely broken. I would venture that it is highly more likely that you have messed up the braces.

Quote:

---

Originally Posted by danlee58

Well, my Compiler doesn't seem to like a Null IF statement, unless I'm using the wrong braces.

matsp, Your suggestion is not unreadable, but this a very complex nested IF-ELSE. The code that I showed was a simplified example. The execution has to exit the IF-Else at several points where a condition is true, but continue to fall through where conditions are false. I'm concerned that I'll never get it right if I make too many changes to the Intuitive statements.

I might have to do that, if the Compiler doesn't accept the Null If.

---

Prelude's example should work. If you tried that and it didn't, post the smallest sample of code that demonstrates the failure.

The normal solution is still to negate the do nothing condition, and put the other alternatives in that if block.

I can't see what's so hard?
Instead of:

Code:

---

if ( condition A )
  Do Nothing;
else if ( condition B )
  Do Something;

---

It would make so much more sense to do:

Code:

---

if ( (Not condition A) && (condition B) )
  Do Something;

---

i.e. what matsp said.

Code:

---

if ( (A != 1 && B != 2) &&
    (C == 3 || D == 4) )
{
  A = C;
  B = D;
}

---

@matsp & Elysia

You don't seem to be applying Demorgan's correctly:
!( (A == 1) && (B == 2) )

is the same as

A!=1 || B!=2

Oh darn, I should have double-checked all examples given earlier.

I think that those of us who are happier to apply the rules and remove the empty if branch are more comfortable with changing our thinking about our problem.
Some people are happier when the way they solve a problem matches their thinking about the problem, but you typically get more optimal code if you change your thinking to fit the problem, as the problem unravels itself in the form of code.
If fact, sometimes when you change your thinking to fit the problem it comes around full circle. You simplify something much furthur, and as a result and come to see it in a new light and realise that you were seeing the problem wrong.
Well those are my experiences at least.

Just don't be afraid to remove the empty if-branch. It's not as difficult to get used to as you might think.

Quote:

---

Originally Posted by King Mir

@matsp & Elysia

You don't seem to be applying Demorgan's correctly:
!( (A == 1) && (B == 2) )

is the same as

A!=1 || B!=2

---

Ehh, you're right. Simple mistake. My mistake >_<

DeMorgans:

The negation of a conjunction is the disjunction of the negations.
The negation of a disjunction is the conjunction of the negations.

I don't see how it's confusing...

If you are not an A or a B:

Code:

---

!(A || B)

---

Then you're not an A, and you're not a B:

Code:

---

!A && !B

---

Think of it as distributing the negation -- it distributes to the predicates as well as the logical combinators (where the "negation" of OR is AND, and vice versa)

On a side note, this is why I always use straight-forward expressions such as
!A && !B
instead of
!(A || B)
Less room to make mistakes.