Cannot evaluate function -- may be inlined

[smallB]

While debugging and trying to watch  std::string obj I'm getting the following info:
Cannot evaluate function -- may be inlined;
Is this behavior intentional?

[zabzonk]

Intentional in what way? It's an inevitable result of the way that inlining works - if a function actually is inlined,  there is no named function representation in the compiled code to watch.

[smallB]

Neil, I don't know in what way intentional. I've asked if it is intentional because few times I've pointed out that some of the behavior of cb seems either illogical or not fully baked and I've got response that the behavior is intentional. That's why this time I've asked.
Now to coding, same code different response:

Code: [Select]

#include <string>

int main(int argc, char* argv[])
{
std::string s("Ala ma kota");//this is observable in vs but not in cb - is this intentional?
return 0;
}

[smallB]

Same here:

Code: [Select]

template<class Int_T>
template<class Forward_Iterator>
    std::string Calculator_engine<Int_T>::read_next_token_(Forward_Iterator& beg,Forward_Iterator& end)
    {
        std::string result;
        if (std::isdigit(*beg))//On this line I'll get info from cb: Attempt to take contents of a non-pointer value.
        {//when in fact beg is an iterator to std::string and has pointer semantics and this should be "observable"
            return get_term_(beg,end);
        }
        else if (is_operator_(beg))
        {
            return get_operator_(beg,end);
        }
        else
        {
            throw Incorrect_Expression();//[opportunity to show exact place of error]
        }

    }

[oBFusCATed]

Does it work, when you debug with GDB directly from the command line?
Do you have debugging symbols? Have you disabled the optimizations?

[zabzonk]

@smallB

If you haven't worked it out by now, CB is not a debugger. As a convenience, it provides an interface to the GDB debugger (and possibly to others). If you have questions about GDB features and "intentions", post them on the GDB site. But if you are expecting the CB/GDB combination (particularly on Windows) to be as powerful, full featured and easy to use as Microsoft's debugger, you are going to be very, very disappointed.

However, even the MS debugger cannot watch (as opposed to step through)  functions that actually have been inlined. If the MS environment is allowing you to watch those functions, then they haven't been inlined by the MS compiler.

[scarphin]

Sry to interfere here. Is that applicable only to the inline function definitions in a class or any function defined inline globally.

[oBFusCATed]

scarphin: There is no difference I guess. In the end the methods of a class are compiled as a functions with hidden this parameter.

[smallB]

@Neil, yes I do understand that(cb is not a debugger, yes I know...(in Tomy Saxondale style)) but surely this can change (I mean gdb can become a better debugger than it is now and in feature better debugger than MS). If cb could became better IDE then VS, surely gdb could become better dbg?
As things are for the moment this particular behavior of gdb makes cb unusable for debugging. For me anyway.

[smallB]

@obfuscated I would have no idea how to use debugger from command line. yes I do have debugging symbols, yes, optimizations are disabled.

[oBFusCATed]

Every decent program has a manual or search the internet. It is not that hard.

[zabzonk]

@smallB:

I don't know what you are doing in the debugger, but this code (I had to make changes to get it to compile and link), is debuggable using gdb and CB for me:

Code: [Select]

#include <string>

template <class Forward_Iterator>
bool is_operator_( Forward_Iterator it ) {
return * it == '+';
}

template<class Forward_Iterator>
std::string  get_operator_( Forward_Iterator beg, Forward_Iterator end) {
return "+";
}

template<class Forward_Iterator>
std::string  get_term_( Forward_Iterator beg, Forward_Iterator end) {
return "term";
}

template<class Forward_Iterator>
    std::string read_next_token_(Forward_Iterator beg,Forward_Iterator end)
    {
        std::string result;
        if (std::isdigit(*beg))
        {
            return get_term_(beg,end);
        }
        else if (is_operator_(beg))
        {
            return get_operator_(beg,end);
        }
else {
throw "error";
}
    }


int main(int argc, char* argv[])
{
std::string foo = "1234567avavav";
std::string t = read_next_token_( foo.begin(), foo.end() );
}


[smallB]

@Neil, perhaps I'm doing something wrong.
this code:

Code: [Select]

#include <string>


    int main(int argc, char* argv[])
{
std::string foo = "1234567avavav";
return 0;
}gives following output:
http://imageshack.us/photo/my-images/259/cannotevaluate.png/

[MortenMacFly]

gives following output:

Here, the compiler might simply has optimised out the std::string as it is not being used. Make sure it's being used (i.e. output it on the console) and try again.

Furthermore: This is actually not a C::B issue. To differ between a C::B and a GDB issue, try to debug at the command line. If it shows the same result, then it's basically "your fault" as C::b is just an interface to GDB.

[zabzonk]

@smallB:

See http://imgur.com/Uqajo