T::operator int () const ambiguous with T::operator Handle () const?

T

Tim Clacy

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;
};
 
S

Shezan Baig

Tim said:
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.
 
B

ben

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();
}

//...
};
 
T

Tim

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?
 
T

Tim

ben said:
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
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

Tim said:
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.
 
P

Pete Becker

Tim said:
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.
 
I

Ian

Julián Albo said:
Tim wrote:




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
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

Ian said:
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.
 
T

Tim

Julián Albo said:
Just define a conversion to bool for that class.

Julián,

Hi. Are you saying that 'operator bool' would be matched in preference to
'operator int' for an 'if' expression?
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

Tim said:
Hi. Are you saying that 'operator bool' would be matched in preference to
'operator int' for an 'if' expression?

Don't checked the standard but gcc accepts it:


// boolconv.cpp

#include <iostream>

class Convertible {
public:
operator int () { return 0; }
operator long () { return 0; }
operator unsigned int () { return 0; }
operator unsigned long () { return 0; }
operator bool () { return true; }
};

int main ()
{
Convertible c;
if (c)
std::cout << "Hello, world" << std::endl;
}

$ g++ -Wall -pedantic -std=c++98 -o boolconv boolconv.cpp
$ ./boolconv
Hello, world


But as Ian remarked, it's better to avoid that.
 
T

Tim Clacy

Julián Albo said:
Don't checked the standard but gcc accepts it:


// boolconv.cpp

#include <iostream>

class Convertible {
public:
operator int () { return 0; }
operator long () { return 0; }
operator unsigned int () { return 0; }
operator unsigned long () { return 0; }
operator bool () { return true; }
};

int main ()
{
Convertible c;
if (c)
std::cout << "Hello, world" << std::endl;
}

$ g++ -Wall -pedantic -std=c++98 -o boolconv boolconv.cpp
$ ./boolconv
Hello, world


But as Ian remarked, it's better to avoid that.

Julián,

Cheers. Adding the 'operator bool' has fixed the issue; an 'Event' can used
as Boolean and a Handle now. Why is it better to avoid 'operator bool'?
 
K

Karl Heinz Buchegger

Tim said:
Cheers. Adding the 'operator bool' has fixed the issue; an 'Event' can used
as Boolean and a Handle now. Why is it better to avoid 'operator bool'?

The problem with all those conversion operators is that it enables
the compiler to use them even in situations where you don't want them
-> The compiler will use those operators to synthesize expressions which
logically make no sense just to find a way to compile your code at all.

Eg. if a class has an operator bool()

class Test
{
operator bool() { ... }
};

then

Test t;
int i = t + 5;

becomes a valid expression (because false -> 0, true -> 1)

That is exactly why eg. the standard stream classes don't have an operator bool()
 
T

Tim Clacy

Karl said:
The problem with all those conversion operators is that it enables
the compiler to use them even in situations where you don't want them
-> The compiler will use those operators to synthesize expressions
which logically make no sense just to find a way to compile your code
at all.

Eg. if a class has an operator bool()

class Test
{
operator bool() { ... }
};

then

Test t;
int i = t + 5;

becomes a valid expression (because false -> 0, true -> 1)

That is exactly why eg. the standard stream classes don't have an
operator bool()

Hmm, that's pretty disgusting... but couldn't you prevent this kind of
anarchy by defining private operators (e.g. operator + (Event const &, int),
operator + (Event const&, unsigned), etc.). In fact, couldn't you do all the
dirty work in a template?

template<typename T>
class DisableStupidImplicitConversions
{
int operator + (int rhs);
:
};

class Event : DisableStupidImplicitConversions<T>
{
:
};

Are there any other reasons for not defining an 'operator bool'? It seems
like one of the most useful operators for bi-stable objects (like Event,
Interrupt, Timer...).
 
K

Kanenas

Please illuminate; what operator of class 'Event' will get matched for these
two cases [see Event outline later]:
[...]
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)?
Shezan Baig summed up the ambiguity. As for what to do, I'd define
'Event::eek:perator bool() const'.

Kanenas
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top