Re: How to overcome overloading ambiguity
On 16 juin, 14:22, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in messagenews:93a4aefc-d=
7bc-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 specializ=
ation 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 inste=
ad 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 functi=
ons 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 express=
ion, 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 funct=
ionality?
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 th=
at 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 pr=
ogram.
FlexeLint 9.0b to be exact. (Seewww.gimpel.com.)
If it can be explained that this is a bug in FlexeLint, I could file a bu=
g report.
It is a bug then. I guess the overload resolution is not performed.
The cv-qualifier of the non-static member function should be enough
and the tol=ols says it is not.
I note that =A712.3/2 doesn't specify overload resolution should be
performed: only unambiguous and access control are required. I assume
unambiguous means name lookup and overload resolution.
--
Michael