Re: How to overcome overloading ambiguity
"Michael Doubez" <michael.doubez@free.fr> wrote in message =
news:93a4aefc-d7bc-4952-a4ab-d338c18c9717@t16g2000yqi.googlegroups.com...=
On 16 juin, 13:56, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in =
messagenews:8429d814-ba46-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 =
specialization for the bool type
with unwanted implications. For example, I need to pass elements of =
the vector as
reference to bool (bool&) to certain functions which may modify the =
value 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 =
functions 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 =
expression, 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 =
functionality?
I followed your suggestion, because it even allows references to const =
objects.
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.
Well, in fact the program that complains is not a compiler, but a lint =
program.
FlexeLint 9.0b to be exact. (See www.gimpel.com.)
If it can be explained that this is a bug in FlexeLint, I could file a =
bug report.