Re: Ambiguity by making overloaded operator function-const - why?
On Jun 1, 10:38 pm, abendst...@gmail.com wrote:
I have the following code and trouble with ambiguity due to
operator overloading..
The code is also athttp://paste.nn-d.de/441
snip>>
#include <iostream>
#include <string>
#include <map>
using namespace std;
class ConfigItem;
typedef map<wstring, ConfigItem> ConfigMap;
class ConfigItem {
public:
ConfigItem() { type=NONE; s[0]=0; }
ConfigItem(const wchar_t *str) {
type=STRING;
wcscpy(s, str);
}
operator const wchar_t*() const {
return s;
}
wchar_t operator[](int pos) const {
return (operator const wchar_t*())[pos];
}
ConfigItem& operator[](const wchar_t *option) {
return operator[](wstring(option));
}
ConfigItem& operator[](const wstring &option) {
switch (type) {
case MAP: return (*cm)[option];
default: return *this;
}
}
private:
enum {
NONE,
INT,
STRING,
MAP,
} type;
wchar_t s[512];
ConfigMap *cm;
};
int main() {
if (wchar_t(ConfigItem()[0]) == L'\0')
cout << "works as expected";
return 0;
}
<<snap
If I compile it using g++ 4.1.2, I get:
test.cpp: In function 'int main()':
test.cpp:53: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion
for the second:
test.cpp:24: note: candidate 1: wchar_t ConfigItem::operator[](int)
const
test.cpp:32: note: candidate 2: ConfigItem& ConfigItem::operator[]
(const std::wstring&)
test.cpp:53: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion
for the second:
test.cpp:24: note: candidate 1: wchar_t ConfigItem::operator[](int)
const
test.cpp:29: note: candidate 2: ConfigItem& ConfigItem::operator[]
(const wchar_t*)
On which path does ISO C++/the compiler deduct the second
candidates??
For the operator[], the compiler considers two arguments, the
object on which it is going to be called (the argument which
becomes the this pointer), and the index argument. In your
expression, ConfigItem()[0], you have a (non-const) ConfigItem,
and a constant integral expression evaluating to 0. Both
operator[]( int ) const and operator[]( wchar_t* ) can be
called. For the first argument, the second is the better match,
because the first requires a qualifier conversion. For the
second argument, the first is a better match, because it is an
exact match. The result is that the call is ambiguous.
Now for the really (to me) weird part:
If I remove the function const from wchar_t operator[](int
pos) const so it reads
wchar_t operator[](int pos) {
above code works as expected and no ambiguity error is shown,
Yes. Because now, you have a better match for the second
argument, and the first two are equal (both exact matches).
the following does also work
const wchar_t operator[](const int pos) {
This is the same as the above.
It is just the function const that provokes the ambiguity - why?
Because it means that calling the function on a non-const object
requires a qualifier conversion.
Many thx for an insightful reply, I spent hours on this and
don't really have a clue, why making an overloaded operator
function-const opens paths to the ambiguity shown.
It *is* sometimes surprising. But frankly, I'd wonder about so
many overloads. What does [] mean on an object of your class?
Off hand, I'd say that if you have [] whose return type differs
in more than just const, then you have operator overload abuse:
if there's a natural meaning for [], then that will exclusively
determine the return type, and if there's not, then you
shouldn't use [].
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34