CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 10 of 10

Thread: Operator Ambiguity

  1. #1
    Join Date
    Dec 2008
    Posts
    1

    Operator Ambiguity

    Hello!

    Forgive me, for I am fairly new to C++, but I am having some trouble regarding operator ambiguity. I think it is compiler-specific, for the code compiled on my desktop. However, it fails to compile on my laptop. I think I know what's going wrong, but I don't see an elegant way around it. Please let me know if I am making an obvious mistake. Anyhow, here's what I'm trying to do:

    I have made my own vector class called Vector4 which looks something like this:

    Code:
    class Vector4
    {
    	private:
    		GLfloat vector[4];
    	...
    }
    Then I have these operators, which are causing the problem:

    Code:
    operator GLfloat* () { return vector; }
    		
    operator const GLfloat* () const { return vector; }
    
    GLfloat& operator [] (const size_t i) { return vector[i]; }
    
    const GLfloat& operator [] (const size_t i) const { return vector[i]; }
    I have the conversion operator so that I can pass an instance of my Vector4 class to glVertex3fv, and I have subscripting for obvious reasons. However, calls that involve subscripting the Vector4 become ambiguous to the compiler:

    Code:
    enum {x, y, z, w}
    Vector4 v(1.0, 2.0, 3.0, 4.0);
    
    glTranslatef(v[x], v[y], v[z]);
    Here are the candidates:

    candidate 1: const GLfloat& Vector4:: operator[](size_t) const
    candidate 2: operator[](const GLfloat*, int) <built-in>

    Why would it try to convert my Vector4 to a GLfloat* first when the subscript operator is already defined on Vector4? Is there a simple way around this? Am I making a silly mistake? Thanks for any help in advance.

    Scott

  2. #2
    Join Date
    Feb 2003
    Location
    Iasi - Romania
    Posts
    8,207

    Re: Operator Ambiguity

    [ Redirected thread ]

  3. #3
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,768

    Re: Operator Ambiguity

    Quote Originally Posted by scottman
    I have the conversion operator so that I can pass an instance of my Vector4 class to glVertex3fv, and I have subscripting for obvious reasons. However, calls that involve subscripting the Vector4 become ambiguous to the compiler:
    With only the given information I am not entirely sure what is the problem, but if your observation that "calls that involve subscripting the Vector4 become ambiguous to the compiler" due to the implicit conversions is correct, then a possible solution is to use a named conversion function instead.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  4. #4
    Join Date
    Apr 1999
    Location
    Altrincham, England
    Posts
    4,470

    Re: Operator Ambiguity

    I suspect laserlight has hit the nail on the head, there. Implicit conversion operators initially sound like a good thing, but you soon find that they're more trouble than they're worth. It's much better to go the route of an explicit conversion function (and explicit constructors), where you have to spell out your intention, rather than let the compiler try to be "helpful" and end up with exactly the sorts of problems that you're finding. And your conversion operator's wrong, anyway...
    Code:
    GLfloat* as_glfloat() { return &vector[0]; }
    const GLfloat* as_glfloat() const { return &vector[0]; }
    Also, I would suggest that you find a different name for your member array, since vector is used by the standard library (admittedly in a different namespace, but...).
    Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
    --
    Sutter and Alexandrescu, C++ Coding Standards

    Programs must be written for people to read, and only incidentally for machines to execute.

    --
    Harold Abelson and Gerald Jay Sussman

    The cheapest, fastest and most reliable components of a computer system are those that aren't there.
    -- Gordon Bell


  5. #5
    Join Date
    Dec 2008
    Location
    Xi'an China
    Posts
    27

    Re: Operator Ambiguity

    You better not use vector as variable name. It's a wellknow keyword in STL. If you use STL, a ambiguity problem will occur when compile.
    Life is similar to ....., if you cannot resist it, you should relax and enjoy it.

  6. #6
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,768

    Re: Operator Ambiguity

    Quote Originally Posted by Graham
    Also, I would suggest that you find a different name for your member array, since vector is used by the standard library (admittedly in a different namespace, but...).
    Quote Originally Posted by Fireseed
    You better not use vector as variable name. It's a wellknow keyword in STL. If you use STL, a ambiguity problem will occur when compile.
    I can understand such advice for the names that are inherited from the C standard library, but not for std::vector. Such a problem only has a chance of happening if a using directive of the std namespace or a using declaration of std::vector is used, in which case full qualification of names would be needed to disambiguate. If one only uses using directives and using declarations in restricted scopes in source files, the problem is virtually a non-issue.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  7. #7
    Join Date
    Dec 2008
    Location
    Xi'an China
    Posts
    27

    Re: Operator Ambiguity

    Quote Originally Posted by laserlight View Post
    I can understand such advice for the names that are inherited from the C standard library, but not for std::vector. Such a problem only has a chance of happening if a using directive of the std namespace or a using declaration of std::vector is used, in which case full qualification of names would be needed to disambiguate. If one only uses using directives and using declarations in restricted scopes in source files, the problem is virtually a non-issue.
    yep, it's not a error generally but it's a non-standard code obviously.
    Last edited by Fireseed; December 23rd, 2008 at 08:46 PM.
    Life is similar to ....., if you cannot resist it, you should relax and enjoy it.

  8. #8
    Join Date
    Apr 1999
    Location
    Altrincham, England
    Posts
    4,470

    Re: Operator Ambiguity

    Quote Originally Posted by laserlight View Post
    I can understand such advice for the names that are inherited from the C standard library, but not for std::vector. Such a problem only has a chance of happening if a using directive of the std namespace or a using declaration of std::vector is used, in which case full qualification of names would be needed to disambiguate. If one only uses using directives and using declarations in restricted scopes in source files, the problem is virtually a non-issue.
    I did note the namespace issue...

    But there is the possibility of confusion by using the same name, and it only takes one pillock to put "using namespace std" in a header file...

    Personally, I'd try to avoid using any name that's defined in the standard: it's usually possible to come up with an alternative.
    Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
    --
    Sutter and Alexandrescu, C++ Coding Standards

    Programs must be written for people to read, and only incidentally for machines to execute.

    --
    Harold Abelson and Gerald Jay Sussman

    The cheapest, fastest and most reliable components of a computer system are those that aren't there.
    -- Gordon Bell


  9. #9
    Join Date
    Mar 2002
    Location
    St. Petersburg, Florida, USA
    Posts
    12,116

    Re: Operator Ambiguity

    100% agreement with Graham.

    There is a certain "presumption" with various conventions. Using "Well Known" item names for custom implementation is likely to cause confusion at least once during the development cycle, and quite possibly introduce subtle bugs.

    So even though it may "work"; it fails the requirements of: Readability, Understandability, and Maintainability.
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009,2010
    In theory, there is no difference between theory and practice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

  10. #10
    Join Date
    Apr 2007
    Location
    Mars NASA Station
    Posts
    1,436

    Smile Re: Operator Ambiguity

    So even though it may "work"; it fails the requirements of: Readability, Understandability, and Maintainability.
    This is the difference a experience programmer to newbie.

    Newbie often think their code can be run and the task is finished and their never think about the three issues above.

    A programmer writer code that computer understand.
    A good programmer writer code that computer and human understand and their solution is appropriate(Direct) the problem and never over complicated the code.
    Last edited by Peter_APIIT; December 24th, 2008 at 01:22 AM.
    Thanks for your help.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)