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

[ Redirected thread ]

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.

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...).

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.

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.

Quote:

---

Originally Posted by laserlight

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.

Quote:

---

Originally Posted by laserlight

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.

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.

Quote:

---

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.