Emulating "implies" logical operator 1

[globos]

Hi,

I want to emulate the 'implies' (=>) logical operator in C++. There's no built-in support for it.
For this purpose, I firstly defined a macro :
# define implies(a, b) !(a) || (b)

And it works fine, especially if a is false then b is not evaluated. But syntactically speaking, this is pretty heavy, for example:
assert (implies (list.is_empty (),/* => */!result));

So I tried another approach, allowing to write in a more natural way, i.e. something like : assert (list.is_empty () implies !result);

To this end, I defined a class that handles the implies computation :

#  define implies	|| ImpliesHelper () ||

   //! Helper objects, used in the computation of implies expressions.
   class ImpliesHelper
   {
     friend ImpliesHelper& operator|| (bool left, ImpliesHelper& ih);
   public:
     bool operator|| (bool right)
     {
       return !_value || right;
     }
   private:
     bool _value;
   };

   ImpliesHelper& operator|| (bool left, ImpliesHelper& ih)
   {
     ih._value = left;
     return ih;
   }
[code]

The syntax effect is reached, but there is a big problem with this : everything is evaluated in a expression, for example, if you write :
[code]
Boolean kikette ()
{
  cout << "haaa" << endl;
  return true;
}

int main ()
{
  cout << "0 => kikette = " << (false implies kikette ()) << endl;

  return 0;
}

You'll get :
haaa
0 => kikette = 1

which means that "kikette" was called, and it should not be!
There is certainly a way to get this to work, I have try to move the expressions so that there are only 'and', but it doesn't work, second part of implies expressions get systematically evaluated.
Does the someone have a solution to this problem?

--
Globos

 

[Cagliostro]

First of all, let's be more precisious.
This expression looks a bit ambiguous:
!(a) || (b)
For me it looks quite the same as
!((a) || (b)) //operation nor
Or could also look as
(!(a)) || (b) //maybe you get this one?

By the way, have you used the debugger to see what is exactly iside?

Ion Filipski

 

[PerFnurt]

I see what you're getting at though I dont see the big advantage

assert (list.is_empty() implies !result);

has over

assert (implies(list.is_empty(),!result));

Anyway...if you can live a horrible macro:

#define implies ^1 ? 1 :

/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[PerFnurt]

thats live with

/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[PerFnurt]

To whom it may concern, accorning to DeMorgan
!a || b == !(a && !b)


/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[globos]

IonFilipski:
>This expression looks a bit ambiguous:
> !(a) || (b)

It's ok for this expression, no ambiguities.
a => b <=> not a or else b

In the C macro way:
#define implies(a, b) !(a) || (b)

For me and the compiler, no problems.

PerFnurt:
>I see what you're getting at though I dont see the big advantage
>assert (list.is_empty() implies !result);
>has over
>assert (implies(list.is_empty(),!result));

I agree, there is no big advantage. Second way is just more readable, more natural, less parenthesis, and to be honest : very Eiffel-like

>Anyway...if you can live a horrible macro:
>#define implies ^1 ? 1 :
Sorry, I don't understand this macro, can you elaborate a bit more on this?

I want to emphasize that the problem with the second means is that in "a implies b", b is evaluated even if a is false.
How to work around this?

--
Globos

 

[Cagliostro]

>It's ok for this expression, no ambiguities.
no comments [LOL]

Ion Filipski

 

[globos]

IonFilipski
>no comments
I gave the precise definition of operator implies, that can be writtable as is in C. What else can I do more to get rid of the ambiguities you saw?

--
Globos

 

[PerFnurt]

>>#define implies ^1 ? 1 :
>Sorry, I don't understand this macro, can you elaborate a bit more on this?

Hey, just use it - you'll see it works

You know the ? : operator, right?

x ? t : f // "if x then t else f"

You know the ^(xor) operator, right?

I'm using ^1 to negate "a" (ie produce the !a part)
1^1 = 0
0^1 = 1


So...

assert( a implies b)

expands to

assert( a ^1 ?  1 : b )

which emulates

assert( !a ? 1 : b)

which can be read as "if !a then result is 1 else result is b"

Disclaimer:
This code should be regarded as a mental excercise. I would never allow such macros in my own code base


/Per

_{&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;}

 

[Cagliostro]

I've shown already two modes on how may be interpreted your expression. Where are more than one single way to understand or interpret an expression it means the expression is ambigue(as well as not a or else b). To get rid of the ambiguities I saw you should choose one of last two variants I've shown above.

Ion Filipski

 

[PerFnurt]

> want to emphasize that the problem with the second means is that in "a implies b", b is evaluated even if a is false.
>How to work around this?

Right. See my horrendeous macro. a==false results in 1. b is never evaluated.

Regarding the mention of ambiguities - I think someone is a tad bit confused.

/Per

_{&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;}

 

[PerFnurt]

Doh, I seem to have made the macro a bit more complicated than it has to be

Perhaps

#define implies ==false ? true :

is more clear. No funny xor or such.

/Per

_{&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;}

 

[PerFnurt]

Or, to make life really simple

#define implies ==false ||

/Per

_{&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;}

 

[globos]

Big big thanks to PerFnurt, your ``#define implies == false ? true : '' works fine. You are really the C++ killer, although you might think this 'implies' stuff brings nothing for the daily life of a programmer.
I can remove this useless ImpliesHelper class now.

A last word for IonFilipski, I'm sorry, I still don't see where there is the ambiguity in "not a or else b".
It definitely cannot be interpreted as "not ((a) or else (b))", which is clearly not the same expression, but I agree it can be rewritten as "(not (a)) or else (b)" if you like parenthesis above all.

--
Globos

 

[PerFnurt]

>you might think this 'implies' stuff brings nothing for the daily life of a programmer.

On the contrary. I use implies quite a lot when it comes to contracts, IMPLIES(a,b) style

/Per

_{&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;}