Ambiguity error

Ok I'm not seeing how to fix this one.

For homework yes

Code:

template <typename T>
class RubberArray
{
    int indexoffset_;
    /* other variables and member functions that aren't germane to this problem */
  public:
    /* other member functions that aren't germane to this problem */
    void insert ( const T&, int i); // line 28
    inline void insert ( int i, const T& a) { insert( (const T&)(a), i); }

    inline void insert ( const T& v) { insert((const T&)(v), int(indexoffset_) ); } // line 31
};

The non-inline version is defined on line 205.

The error I'm getting is

rubber.h:31: call of overloaded `insert(const int &, int)' is ambiguous
rubber.h:205: candidates are: void RubberArray<int>::insert(const int &, int)
rubber.h:29: void RubberArray<int>::insert(int, const int &)

Now for testing purposes I'm using an RubberArray<int>. I don't see what the problem is with the overloading since it should be able to match the consts up and overload based off of them.

I can not use a default parameter to get around this problem since indexoffset_ is not a set value.

Originally Posted by Thantos

I can not use a default parameter to get around this problem since indexoffset_ is not a set value.

Couldn't you use a default parameter value of -1 and check whether the value equals -1 and if so, change the value to _indexoffset?

Also, why do you have two equivalent insert funtions where the second one just reverses the parameters and call the other?

-1 is a valid value of indexoffset_

Basically we are creating a vector with some twists:
The start point of the indexing can be set by the user (ala Pascal)
Can do insertions anywhere in the array (beginning, middle, or end)
Can do deletions anywhere in the array (beginning, middle, or end)

So indexoffset_ can range from INT_MIN to INT_MAX

Also, why do you have two equivalent insert funtions where the second one just reverses the parameters and call the other?

Because thats what the instructions say to do
Basically one says "insert this value at this location" the other says "at this location insert this value"

Well I found a solution using function pointers. Can't check it against my actual code till this evening but using a test program the following should work:

Code:

void insert ( const T&, int i);
inline void insert ( int i, const T& a)
{ 
  void (*funcptr)(const T&, int)=insert; 
  funcptr( a, i); 
}
inline void insert ( const T& v) 
{ 
  void (*funcptr)(const T&, int)=insert; 
  funcptr(v,indexoffset_); 
}

Though something tells me there has to be a way to do it without function pointers.

>Because thats what the instructions say to do
Clearly the author of your instructions isn't familiar with the C++ standard and didn't consider what would happen when T is int. Put simply, in overloaded name resolution, cv and reference qualifiers are ignored. So both insert functions are of type

Code:

void RubberArray<int>::insert ( int, int );

As far as the compiler is concerned. There's basically no way to get around it cleanly without something hackish like your function pointer solution, or something error prone and reliant on the class internals like this:

Code:

template <typename T, typename I = int>
class RubberArray
{
    I indexoffset_;
  public:
    void insert ( const T&, I i);
    inline void insert ( I i, const T& a) { insert(a, i); }
    inline void insert ( const T& v) { insert(v, indexoffset_ ); }
};

int main()
{
  RubberArray<int> ra0;               // Error, T and I == int is ambiguous
  RubberArray<int, unsigned int> ra1; // Okay, T and I are now different
  RubberArray<double> ra2;            // Okay, T and I are different

  ra0.insert ( 10 );
  ra1.insert ( 10 );
  ra2.insert ( 10.0 );
}

A third alternative is to add a level of abstraction. Define RubberArray to take a templated object rather than any type T (ie. RubberArray is not a template class as you had it). Though this adds a level of complexity that would be prohibitive, so you really don't have any good options thanks to somebody's poor design.

I'll bring up the problem in class and see what he has to say. As far as adding another level of abstraction, lets just say in terms of my grade in the class that would be a BadThing (tm)

>I'll bring up the problem in class and see what he has to say.
Section 13.3.1.5 of the standard if it comes up.

Originally Posted by Prelude

>I'll bring up the problem in class and see what he has to say.
Section 13.3.1.5 of the standard if it comes up.

Standard bought: Done
Section Found: Done
Section Printed out: Done

Well I talked to the professor before class and....

He put it in on purpose to make sure people were actually testing their code

He probably just said that.

Quzah.

Nah, from the tone of voice and mannerisms I'd believe him.