Re: How to overcome overloading ambiguity
On 16 juin, 13:56, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in messagenews:8429d814-b=
a46-441d-900c-3750a9412310@x3g2000yqa.googlegroups.com...
On 16 juin, 11:36, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
In my software I need a vector of boolean values.
My first attempt was to use vector<bool>, but vector has a specializat=
ion for the bool type
with unwanted implications. For example, I need to pass elements of th=
e vector as
reference to bool (bool&) to certain functions which may modify the va=
lue of such elements.
This is not possible with vector<bool>.
My next idea was to create a class Boolean_t which can be used instead=
of the bool type,
with transparent functionality. So I attempted the following:
class Boolean_t {
private:
bool Flag;
public:
// Normal constructor:
Boolean_t (const bool InitialValue = false) : Flag (InitialValue) {}
// Define conversion to bool and reference to bool.
operator bool () const {
return Flag;
}
Which can be replaced by:
operator const bool& () const {return Flag; }
operator bool & () {
return Flag;
}
};
My problem is with two operator definitions. I need both.
The first one is needed to convert a const object to a bool value,
which cannot be done with the second one.
The second one is needed to pass objects of type Boolean_t to function=
s that need a reference to bool,
which cannot be done with the first one.
However, if an object of type Boolean_t is used in a boolean expressio=
n, the compiler complains
about an ambiguity in the reference to a conversion function.
Can you post an example ?
Indeed, I understand that both
of these conversion functions could be used in this case.
Is there a solution to overcome this ambiguity and to keep the functio=
nality?
I followed your suggestion, because it even allows references to const ob=
jects.
Doesn't make a lot of difference here. const reference bind to lvalue.
It does not make a difference for ambiguity according to the compiler.
However, I now see that another compiler does not complain.
When I then try something like:
Boolean_t Value;
....
if (Value) {
...
}
Then one compiler complains about the expression in the if statement that=
there is an ambiguity
in choosing between the two operators.
Another compiler, however, does not complain.
Which one is right?
Which compilers ?
This seems to compile fine with MSVC9 and g++ and I don't see the
problem.
--
Michael