If you read the rest of the error message (in the output window), it becomes a bit clearer:

1>        could be  const float &v3<T>::operator [](unsigned int) const 
1>        with
1>        [
1>            T=float
1>        ]
1>        or        built-in C++ operator[(const float *, int) 
1>        while trying to match the argument list  (const v3<T>, int) 
1>        with
1>        [
1>            T=float
1>        ]

The compiler can t decide whether to use your overloaded operator[] or the built-in operator[] on the const T* that it can obtain by the following conversion function:

operator const T * () const { return _a; }

Both of the following are potentially valid interpretations of the offending lines:

v.operator float*()[0]
v.operator[](0)

You can remove the ambiguity by explicitly casting the integer indices to be unsigned so that no conversion is needed:

_a[0] = v[static_cast<unsigned int>(0)];

or by changing your overloaded operator[]s to take an int instead of an unsigned int, or by removing the operator T*() const (and probably the non-const version too, for completeness).

In simple terms: the compiler doesn t know whether to convert v to const float* and then use the operator[] for a pointer, or to convert 0 to unsigned int and then use the operator[] for const v3.

Fix is probably to remove the operator[]. I can t think of anything it gives you that the conversion operator to T* doesn t already. If you were planning to put some bounds-checking in operator[], then I d say replace the conversion operators with getPointer functions (since in general you don t want to implicitly convert a safe thing to an unsafe thing), or do what std::vector does, which is that users get a pointer with &v[0].

Another change that lets it compile, is to change operator[] to take an int parameter instead of unsigned int. Then in your code, the compiler unambiguously chooses the interpretation with no conversion. According to my compiler, there is still no ambiguity even when using an unsigned index. Which is nice.

When you the compiler compiles the following

v[0]

it has to consider two possible interpretations

v.operator T*()[0] // built-in []
v.operator[](0)    // overloaded [] 

Neither candidate is better than the other because each one requires a conversion. The first variant requires a user-defined conversion from v3<T> to T*. The second variant requires a standard conversion from int (0 is int) to unsigned int, since your overloaded [] requires an unsigned int argument. This makes these candidates uncomparable (neither is clearly better by C++ rules) and thus makes the call ambuguous.

If you invoke the operator as

v[0U]

the ambiguity will disappear (since 0U is already an unsigned int) and your overloaded [] will be selected. Alternatively, you can declare your overloaded [] with int argument. Or you can remove the conversion operator entirely. Or do something else to remove the ambiguity - you decide.

It is your type conversion operator that is the culprit. v transformed to a float pointer. Now there are two operator []s possible, one is the built in subscript operator for float and the other being the one you defined on v, which one should the language pick, so it is an ambiguity according to ISO.

Remember a class is a friend of itself:

v3(const v3<T> & v)
{
     _a[0] = v._a[0]; 
     _a[1] = v._a[1]; 
     _a[2] = v._a[2];
}

When copy something of the same type you are already exposed to the implementation details. Thus it is not a problem to access the implementation directly if that is appropriate. So from the constructor you can access the object you are copying directly and see its member _a .

If you want to know the original problem:

The literal 1 in the context v[1] is an integer (this is a synonym of signed integer). Thus to use the operator[] the compiler technically is required to insert a conversion from int to unisgned. The other alternative is to use the operator*() to get a pointer to the internal object and then use the [] operator on the pointer. Compiler is not allowed to make this choice and error out:

Compiler options:

 _a[1] = v[1];
 // Options 1:
 _a[1] = v.operator[]((unsigned int)1);
 // Options 2:
 _a[1] = v.operator*()[1];

To make it unabigious you can use an unsigned literal;

 _a[1] = v[1u];

In the long run it may be worth making this easier for the user.
Convert the operator[] to use int rather than unsigned int then you will get exact matches when integer literals (or you can have two sets of operator[]. One that uses int and one that uses unsigned int).

I didn t see it untill James McNellis posted the full error message, but the ambiguity is not between the two v3::operator[]() functions as it appears to be.

Instead, since there is no exact match between argument types, the compiler can t decide whether to:

a) Use v3::operator[](unsigned int) const, thereby converting the int argument to unsigned, or

b) Use the v3::operator const T*() const conversion followed by the built-in array indexing operator.

You can avoid this by making the operator[] arguments int s rather than unsigned ints. But a better solution would be to avoid an implicit conversion to T* and instead provide a Data() function that did that explicitly.

I had this same issue: I resolved it simply making the typecast operator explicit.

The const version doesn t modify anything. The non-const version allows you to assign things using array notation (v[3] = 0.5;).