Operator overloading and Ambiguity

This is a discussion on Operator overloading and Ambiguity within the C++ Programming forums, part of the General Programming Boards category; Hi Everybody, I'm writing a String class for a school assignment. The String class is supposed to include a char* ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    32

    Operator overloading and Ambiguity

    Hi Everybody,
    I'm writing a String class for a school assignment.
    The String class is supposed to include a char* pCh pointer to a character array to store the actual string, this is OK.

    Then the teacher asked us to include an operator overloading for char* so that every time the compiler can treat a String object as a character pointer it would get access to the char* pCh pointer in the object... other than feeling this breaks encapsulation, I believe it's OK... after all he is the teacher.

    This is my implementation of that:
    Code:
    String :: operator char*() const
    {
        return pCh;    
    }
    The problem arises when the teacher asks us to include another operator overload, this time for the [] operator... as to provide direct access to each of the strings characters... again... encapsulation issues, but that's not the problem...

    This is my implementation if THAT:
    Code:
    char& String :: operator[](unsigned int i) const
    {
        if(i >= length)
            abort();
        return pCh[i];
    }
    Everything seems fine so far?

    The problem is that when trying to actually test my program, the compiler doesn't know what to do... should it first use the operator char* overload on the String and then treat the following [i] the same way any pointer can be accessed (e.g. int* p; int a = p[3]; ) or use my operator[](usigned int i) and correctly return a reference to a character???

    Code:
    String a("Ambiguity!");
    char m = a[1]; 
    
    /*
    supposed to make char m contain the actual 'm' character in position 1 in string a
    */
    How do I tell the compiler that I mean the operator[]? Is there a way to set a presedence order telling the compiler that in the case that a string object is followed by [i] use the correct operator overloading function?

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    23,786
    How do I tell the compiler that I mean the operator[]?
    You can write:
    Code:
    char m = a.operator[](1);
    Of course, this defeats the whole point of overloading operator[]. A better idea would be to copy the interface of std::string and provide something like its c_str() member function instead of providing a cast to char* or const char*.

    Incidentally, operator[] usually comes in a pair: a non-const version, and a const version. For your case, it might be something like:
    Code:
    char& String::operator[](unsigned int i)
    // and
    char String::operator[](unsigned int i) const
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    32

    wow

    So basicaly there is no way of doing this in C++

    I wonder what the instructor would say

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    23,786
    So basicaly there is no way of doing this in C++
    It looks like it to me.

    According to Koenig and Moo in Accelerated C++, the first problem with providing a conversion operator to char* is that it breaks encapsulation, allowing the contents of your String to be changed from outside of the interface provided. This problem can be solved by only having a conversion operator to const char*. The second problem is with memory management: such a pointer to a String object could be invalidated if the object should be destroyed. This can be solved by allocating new space for a copy of the contents of the String, but then an implicit conversion could result in having no pointer to destroy, leading to a memory leak.

    The c_str() concept is a solution to this problem, where the string object owns the const char* returned. It is not foolproof as it relies on the user either using the const char* immediately or copying it elsewhere, but then having to call a function is clearer and thus safer than relying on a conversion operator with a possible implicit conversion.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Ambiguity issue
    By George2 in forum C++ Programming
    Replies: 21
    Last Post: 02-10-2008, 11:52 PM
  2. Ambiguity error with double as parameter type
    By tejasvsrinivasa in forum C++ Programming
    Replies: 2
    Last Post: 11-11-2007, 03:17 PM
  3. Inheritence ambiguity
    By bennyandthejets in forum C++ Programming
    Replies: 3
    Last Post: 12-04-2003, 06:02 PM
  4. How to avoid template ambiguity
    By Shadow12345 in forum C++ Programming
    Replies: 2
    Last Post: 11-09-2002, 11:34 AM
  5. Multiple Inheritance Ambiguity
    By FillYourBrain in forum C++ Programming
    Replies: 21
    Last Post: 08-23-2002, 10:31 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21