Ambiguity in overloaded operator

Question

Hi All,
Compiler barfs regards the overloaded operator [] .
#include <iostream>
#include <string>
class String {
  public:
    String() { }
    String(const char* src) : myStr(src) { }
    String(const std::string& src) : myStr(src) { }
    String(const String& src) : myStr(src.myStr) { }
    operator const char*() const         { return myStr.c_str(); }
    char& operator[](size_t index)       { return myStr[index]; }
    char operator[] (size_t index) const { return myStr[index]; }
    size_t length() const { return myStr.length(); }
  private:
    std::string myStr;
int main() {
    String s("abcd");
    char c = s[1];
    std::cout << c << std::endl;
    return 0;
$ CC -m32 -g ambiguous.cc
"ambiguous.cc", line 23: Error: Overloading ambiguity between "String::operator[](unsigned)" and "operator[](const char*, int)".
1 Error(s) detected.1) I cannot modify all the instances like, c = s[1]. There are hundreds of similar things in code.
2) operator const char* is required.
Could someone suggest any work-around, considering the above 2 points.
Thanks,
Sreekar

Answer 1

If you have both an operator char*() and and operator[](), you will have generally have overloading ambiguities. Adding more overloads as you did might cure some of them, but apart from complicating the code and reducing maintainability, can wind up with other ambiguities down the line.
The standard string class does not have an operator char*(), but a named conversion operator c_str() instead, partly for that reason, but mostly to prevent accidental and unintended conversions from string to char*. As designed, the String class in the example suffers from both defects.
The best fix is to re-think the design of the String class. If you are under pressure to get something working and out the door now, you could settle for a workaround such as you found. But make the time later to re-design and re-code. Otherwise the problems with the existing design will continue to cause problems, including code that mysteriously fails at run time, in the future.