Same old story - VS vs GCC 4.6.1

Question

The code below compiles fine with VS2010 but fails to compile with gcc 4.6.1:

The error from gcc:

*C:...\Calculator_engine_impl.h|20|error: no match for call to '(std::string {aka std::basic_string}) (__gnu_cxx::__normal_iterator >&, __gnu_cxx::__normal_iterator >&)'|*

#include "stdafx.h"


#include <iostream>
#include "Calculator_engine.h"

int main(int argc, char** argv)
{
    QString expression("1+2-3");
    auto beg = expression.begin();
    auto end = expression.end();
    while (beg != end)
    {
    qDebut() <<
     Calculator_engine<>::read_next_token_(beg,end);
    }
}

#ifndef CALCULATOR_ENGINE_H
#define CALCULATOR_ENGINE_H
#include <string>
#include <cctype>
using namespace std;
//#include "Incorrect_Expression.h"
template<class Int_T = long long>
class Calculator_engine
{
private:
    Calculator_engine();
    static Int_T expression(QString exp);
    template<class Forward_Iterator>
    static Int_T term_(Forward_Iterator& beg,Forward_Iterator& end);
public:

    template<class Forward_Iterator>
    static QString read_next_token_(Forward_Iterator& beg,Forward_Iterator& end);

public:

    static QString calculate(QString exp);
};

#include "Calculator_engine_impl.h"

#endif // CALCULATOR_ENGINE_H
#ifndef CALCULATOR_ENGINE_IMPL_H_INCLUDED
#define CALCULATOR_ENGINE_IMPL_H_INCLUDED
template<class Int_T>
class Calculator_engine;//[Forward decl]

template<class Int_T>
 template<class Forward_Iterator>
Int_T Calculator_engine<Int_T>::term_(Forward_Iterator& beg,Forward_Iterator& end)
{
    QChar token;
    Int_T result;
    switch(token)
    {
    case '*':
        break;
    case '/':
        break;
    }
}
template<class Int_T>
QString Calculator_engine<Int_T>::calculate(QString exp)
{
    Int_T result;
    auto beg = exp.begin();
    auto end = exp.end();
    while (beg != end)
    {
        QString term_ = read_next_token_(beg,end);
        QChar token = read_next_token_(beg,end);
    switch(token)
    {
    case '-':
        result -= term_(beg,end);
        break;
    case '+':
        result += term_(beg,end);
        break;
    }


    }

}

template<class Int_T>
Int_T Calculator_engine<Int_T>::expression(QString exp)
{

}


template<class Int_T>
template<class Forward_Iterator>
    QString Calculator_engine<Int_T>::read_next_token_(Forward_Iterator& beg,Forward_Iterator& end)
    {
        QString result;
        while(std::isdigit(*beg))
        {

        }
        return result;
    }

#endif // CALCULATOR_ENGINE_IMPL_H_INCLUDED

I don't see any reference to `QString` or `QChar` in your source code. Are you sure you posted the right bits? — Fred Foo, Nov 05 '11 at 14:58
@BlackBear line which causes the error: result -= term_(beg,end); this is from calculate fnc. — smallB, Nov 05 '11 at 15:03
@Iarsmans yes, that's true, the references are to char and string - that's the VS version. In code::blocks I use version with QString and QChar. — smallB, Nov 05 '11 at 15:04
So you didn't post the code that gives you the error? I'm confused... — Mat, Nov 05 '11 at 15:05
Why on earth are you naming both a local variable and a function `term_`? — Mat, Nov 05 '11 at 15:12
@Mat bingo, nice catch. Thanks. I was standing there and looking at this code like A LUNATIC! (in Catherine Tate style;) — smallB, Nov 05 '11 at 15:15
@smallB When I saw term_(beg,end) I thought that QString has an operator() but I don't see it in http://doc.qt.nokia.com/latest/qstring.html. What are you trying to do there if not to call operator() or your QString instance (named term_)? — selalerer, Nov 05 '11 at 15:17

score 2 · Accepted Answer · answered Nov 05 '11 at 15:14

You have both a function named term_ and a local variable:

Int_T Calculator_engine<Int_T>::term_(Forward_Iterator& beg,Forward_Iterator& end)
//   ....

QString term_ = read_next_token_(beg,end);
//  ...  
result -= term_(beg,end);

GCC uses the innermost definition - in this case, your local QString. It then tries to find an operator()(QChar*&, QChar*&) to satisfy this call, but fails. Apparently visual studio does something different. I'm not entirely sure which is conforming to the spec - but I'd suspect GCC is getting it right here.

The solution, of course, is to not use the same name for a local variable and a function.

thanks, and yes, gcc is most probably right. Since I've started using gcc I'm overwhelmed on the number of errors VS was compiling and gcc is refusing them. Good thing. — smallB, Nov 05 '11 at 15:23

Same old story - VS vs GCC 4.6.1

1 Answers1