469,600 Members | 2,326 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,600 developers. It's quick & easy.

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

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;
};
Jul 23 '05 #1
15 4080

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


Jul 23 '05 #2
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.


Jul 23 '05 #3
On Fri, 29 Apr 2005 18:45:08 +0200, "Tim Clacy"
<no*******@nospamphaseone.nospamdk> wrote:
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::operator bool() const'.

Kanenas
Jul 23 '05 #4
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();
}

//...
};
Jul 23 '05 #5
Tim

<ab*********@spambob.com> wrote in message
news:11*********************@z14g2000cwz.googlegro 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?
Jul 23 '05 #6
Tim

"ben" <be******@hotmail.com> wrote in message
news:42**********************@news.optusnet.com.au ...
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
Jul 23 '05 #7
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
Jul 23 '05 #8
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)
Jul 23 '05 #9
Ian
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
Jul 23 '05 #10
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
Jul 23 '05 #11
Tim
"Julián Albo" <JU********@terra.es> wrote in message
news:42********@x-privat.org...
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


Julián,

Hi. Are you saying that 'operator bool' would be matched in preference to
'operator int' for an 'if' expression?
Jul 23 '05 #12
Tim wrote:
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.

--
Salu2
Jul 23 '05 #13
Julián Albo wrote:
Tim wrote:
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.


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'?
Jul 23 '05 #14
Tim Clacy wrote:

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

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #15
Karl Heinz Buchegger wrote:
Tim Clacy wrote:

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


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...).
Jul 23 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Gianni Mariani | last post: by
reply views Thread by A. W. Dunstan | last post: by
1 post views Thread by Tony Johansson | last post: by
1 post views Thread by Tony Johansson | last post: by
7 posts views Thread by Jim Langston | last post: by
11 posts views Thread by jakester | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.