1

My Question is why in processSymbol(const string, enumDataType) does the compiler think I am passing a std::string&. I used processSymbol(const string, enumDataType) earlier in my code and work just as intended, but in this function I am getting this erro

error: call of overloaded 'processSymbol(std::string&, symsErrorCode&)' is ambiguous|
note: candidates are:
note: void processSymbol(std::string, symsErrorCode&)|
note: void processSymbol(std::string, symsErrorCode)|

Here is the function I am wondering about.

void processSearchForSymbols(ifstream & inSyms, BST & symTable){
   symsErrorCode symsError;
   string symbol;
   while(inSyms >> symbol){
       symsError = NO_ERROR;
       processSymbol(symbol, symsError);
   }
}

The function where the processSymbol() compiled how I thought it should is this:

void processInsertSymbolData(ifstream & inFile, BST & symTable){
string symbol, value, rFlag, fourCharSymbol;
symsErrorCode symsError;
while(inFile >> symbol >> value >> rFlag){
    symsError = NO_ERROR;
    processSymbol(symbol, symsError);
    if(symsError == NO_ERROR)
    {
        fourCharSymbol = createFourCharSymbol(symbol);
        processValue(value, symsError);
        if(symsError == NO_ERROR)
        {
            processRFlag(rFlag, symsError);
            if(symsError == NO_ERROR)
            {
                insertIntoSymTable(symsError, fourCharSymbol, value, rFlag, symTable);
            }
        }
    }
    errorOutput( symsError, symbol, fourCharSymbol, value);
}
return;
}

Here is the processSymbol(const string symbol, symsErrorCode symsError) function

void processSymbol(const string symbol, symsErrorCode symsError){
if(symbol.length() > 10)
{
    symsError = LENGTH;
}
else if(!isalpha(symbol[0]))
{
    symsError = START_CHAR;
}
else
{
    for(unsigned int i = 1; i < symbol.length(); i++)
    {
        if( !isalnum(symbol[i]) && symbol[i] != '_' )
        {
            symsError = INVALID_CHAR;
        }
    }
}
return;
}
Michael Alan Muston
  • 11
  • 2
  • 2
    I don't think there is any difference between the two cases. There is something else going on which you have not shown here. Can you show all the overload declarations of `processSymbol(const string, enumDataType)` ? – Mahesh Sep 10 '13 at 01:40
  • Can you also provide the processSymbol function? Also as an off-topic suggestion, I feel you are declaring using std, which is a bad practice. See here http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice – shunyo Sep 10 '13 at 01:45
  • @Mahesh I have added the other overloaded deceleration it could be to the error section. – Michael Alan Muston Sep 10 '13 at 02:11
  • @shunyo I have added the processSymbol function and yes I am declaring using std::cout, std::string, std::endl. – Michael Alan Muston Sep 10 '13 at 02:11
  • 1
    You have another declaration of `processSymbol` somewhere. The compiler thinks you are passing `std::string&` because you are doing exactly this, but it's normal and expected, don't worry about it. Find and kill or fix the other declaration of `processSymbol`. – n. m. could be an AI Sep 10 '13 at 03:01
  • The error shows two versions of processSymbol(). They have nearly identical signatures. Get rid of one of them. – brian beuning Sep 10 '13 at 03:07
  • Thanks to n.m. and Brian beuning, I realized the issue was my prototype was `processSymbol(const string, enumDataType &)` but in my decleration I was missing a &: `processSymbol(const string, enumDataType ). Thanks for your help. – Michael Alan Muston Sep 10 '13 at 03:20

1 Answers1

1

The compiler can't tell the difference between the two declarations of processSymbol that you are trying to call. I would suggest using a pointer (*) instead of & for the enum. That will make it clear to the compiler which version of the function you are intending to call.

processSymbol(const string symbol, symsErrorCode* symsError) ...
Daryl Hanson
  • 448
  • 2
  • 7
  • Instead of adding the possibility of null pointer errors, it might be more prudent to rename one of the functions and keep their signatures intact. Furthermore, there is little point to passing enums (and other small types) by reference, unless you need to edit them in place (which you can't on enums). At best, it's not slower, at worst, it's harder to read and runs slower. – Kajetan Abt Sep 10 '13 at 07:17