«

Please illuminate; what operator of class 'Event' will get matched for these
two cases [see Event outline later]:

Event ev1;
Event ev2;

// Case 1
//
if (ev1)
;

// Case 2
//
if (ev1 || ev2)
;

I would have thought 'operator int ()' is the only obvious match, but my
compiler generates errors:

"ambiguous 3-way choice of conversion from 'struct Event' in Boolean
context

All I'm trying to do is wrap an OS event in a class that can be treated like
a Boolean; can anyone explain what the ambiguity is and how it can be
resolved (preferable without casts)?

Best regards


Tim





typedef struct tagHandle { }* Handle;

bool eventIsSignalled(Handle hEvent);

struct Event
{
:
bool IsSignalled() const { return eventIsSignalled(*this); }

operator int () const { return IsSignalled(); }
operator Handle () const { return handle; }

private:
Handle handle;
};

Tim Clacy wrote:
> typedef struct tagHandle { }* Handle;
>
> bool eventIsSignalled(Handle hEvent);
>
> struct Event
> {
> :
> bool IsSignalled() const { return eventIsSignalled(*this); }
>
> operator int () const { return IsSignalled(); }
> operator Handle () const { return handle; }



ints *and* pointers are convertible to boolean (with the same
priority). So it is ambigious.



>
> private:
> Handle handle;
> };

Shezan Baig wrote:
> Tim Clacy wrote:
> > typedef struct tagHandle { }* Handle;

try instead:
struct Handle { SomeType* realHandle; };

> > bool eventIsSignalled(Handle hEvent);
> >
> > struct Event
> > {
> > :
> > bool IsSignalled() const { return eventIsSignalled(*this); }
> >
> > operator int () const { return IsSignalled(); }
> > operator Handle () const { return handle; }
>
> ints *and* pointers are convertible to boolean (with the same
> priority). So it is ambigious.

> All I'm trying to do is wrap an OS event in a class that can be treated
like
> a Boolean; can anyone explain what the ambiguity is and how it can be
> resolved (preferable without casts)?
> ...
> typedef struct tagHandle { }* Handle;
>
> bool eventIsSignalled(Handle hEvent);
>
> struct Event
> {
> :
> bool IsSignalled() const { return eventIsSignalled(*this); }
>
> operator int () const { return IsSignalled(); }
> operator Handle () const { return handle; }
>
> private:
> Handle handle;
> };
>

If Event::IsSignalled does fine, why use operator int?
Event itself is not a handle, why provide Handle operator?

To simplify:

struct Event
{
private:
Handle handle;

public:
Handle GetHandle() const
{
return handle;
}

operator int() const
{
return eventIsSignalled();
}

//...
};

<> wrote in message
news: ups.com...
> Shezan Baig wrote:
> > Tim Clacy wrote:
> > > typedef struct tagHandle { }* Handle;
>
> try instead:
> struct Handle { SomeType* realHandle; };

Shezen,

Hi. I can't try right now but how would that help?

> ints *and* pointers are convertible to boolean (with the same
> priority). So it is ambigious.

Hmm, that means that no C++ class can be used in an 'if' statement if it has
more than one operator that returns a POD type... doesn't it?

"ben" <> wrote in message
news:42733154$0$4656$ ...
>
> > All I'm trying to do is wrap an OS event in a class that can be treated
> like
> > a Boolean; can anyone explain what the ambiguity is and how it can be
> > resolved (preferable without casts)?
> > ...
> > typedef struct tagHandle { }* Handle;
> >
> > bool eventIsSignalled(Handle hEvent);
> >
> > struct Event
> > {
> > :
> > bool IsSignalled() const { return eventIsSignalled(*this); }
> >
> > operator int () const { return IsSignalled(); }
> > operator Handle () const { return handle; }
> >
> > private:
> > Handle handle;
> > };
> >
>
> If Event::IsSignalled does fine, why use operator int?
> Event itself is not a handle, why provide Handle operator?
>
> To simplify:
>
> struct Event
> {
> private:
> Handle handle;
>
> public:
> Handle GetHandle() const
> {
> return handle;
> }
>
> operator int() const
> {
> return eventIsSignalled();
> }
>
> //...
> };

Ben,

Hi. It looks like I'll have to run with your suggestion. 'operator int'; is
convenient in 'if' and || expressions for exactly the same reason that you
would prefer this:

if (a || b || c)
;

to this:

if ((a != false) || (b != false) || (c != false))
;

I'm a little disappointed that 'operator in' isn't a better match that
'operator void*' in an 'if' expression. This is surely a case of 'C'
crippling the power of C++ operator overloading isn't it?

Regards


Tim

Tim wrote:

>> ints *and* pointers are convertible to boolean (with the same
>> priority). So it is ambigious.
> Hmm, that means that no C++ class can be used in an 'if' statement if it
> has more than one operator that returns a POD type... doesn't it?

Just define a conversion to bool for that class.

--
Salu2

Tim wrote:
>
> Hmm, that means that no C++ class can be used in an 'if' statement if it has
> more than one operator that returns a POD type... doesn't it?
>

No. POD types aren't inherently convertible to bool. Some of them (in
particular, builtin types) are.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Julián Albo wrote:
> Tim wrote:
>
>
>>>ints *and* pointers are convertible to boolean (with the same
>>>priority). So it is ambigious.
>>
>>Hmm, that means that no C++ class can be used in an 'if' statement if it
>>has more than one operator that returns a POD type... doesn't it?
>
>
> Just define a conversion to bool for that class.
>
And then live with all the bizarre run time errors such an operator will
give you!

Use a bool member like isOK(), the extra typing is worth it.

Ian

Ian wrote:

> Julián Albo wrote:
>> Tim wrote:
>>
>>
>>>>ints *and* pointers are convertible to boolean (with the same
>>>>priority). So it is ambigious.
>>>
>>>Hmm, that means that no C++ class can be used in an 'if' statement if it
>>>has more than one operator that returns a POD type... doesn't it?
>> Just define a conversion to bool for that class.
> And then live with all the bizarre run time errors such an operator will
> give you!
> Use a bool member like isOK(), the extra typing is worth it.

I do. But the question was if that can be done.

--
Salu2