Author Topic: Cannot evaluate function -- may be inlined  (Read 37537 times)

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Cannot evaluate function -- may be inlined
« on: November 05, 2011, 04:21:22 pm »
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

  • Guest
Re: Cannot evaluate function -- may be inlined
« Reply #1 on: November 05, 2011, 05:14:30 pm »
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.

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: Cannot evaluate function -- may be inlined
« Reply #2 on: November 05, 2011, 06:49:30 pm »
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
#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;
}

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: Cannot evaluate function -- may be inlined
« Reply #3 on: November 05, 2011, 06:57:32 pm »
Same here:
Code
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]
        }

    }
« Last Edit: November 05, 2011, 06:59:15 pm by smallB »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Cannot evaluate function -- may be inlined
« Reply #4 on: November 05, 2011, 07:33:27 pm »
Does it work, when you debug with GDB directly from the command line?
Do you have debugging symbols? Have you disabled the optimizations?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

zabzonk

  • Guest
Re: Cannot evaluate function -- may be inlined
« Reply #5 on: November 05, 2011, 07:44:31 pm »
@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.
« Last Edit: November 05, 2011, 07:57:32 pm by Neil Butterworth »

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Cannot evaluate function -- may be inlined
« Reply #6 on: November 05, 2011, 10:16:36 pm »
Sry to interfere here. Is that applicable only to the inline function definitions in a class or any function defined inline globally.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Cannot evaluate function -- may be inlined
« Reply #7 on: November 05, 2011, 10:34:09 pm »
scarphin: There is no difference I guess. In the end the methods of a class are compiled as a functions with hidden this parameter.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: Cannot evaluate function -- may be inlined
« Reply #8 on: November 06, 2011, 10:47:53 am »
@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.
« Last Edit: November 06, 2011, 10:51:28 am by smallB »

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: Cannot evaluate function -- may be inlined
« Reply #9 on: November 06, 2011, 10:56:27 am »
@obfuscated I would have no idea how to use debugger from command line. yes I do have debugging symbols, yes, optimizations are disabled.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Cannot evaluate function -- may be inlined
« Reply #10 on: November 06, 2011, 11:01:37 am »
Every decent program has a manual or search the internet. It is not that hard.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

zabzonk

  • Guest
Re: Cannot evaluate function -- may be inlined
« Reply #11 on: November 06, 2011, 12:15:23 pm »
@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
#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() );
}

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: Cannot evaluate function -- may be inlined
« Reply #12 on: November 06, 2011, 02:38:23 pm »
@Neil, perhaps I'm doing something wrong.
this code:
Code
#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/
« Last Edit: November 06, 2011, 02:40:23 pm by smallB »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Cannot evaluate function -- may be inlined
« Reply #13 on: November 06, 2011, 02:45:54 pm »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

zabzonk

  • Guest
Re: Cannot evaluate function -- may be inlined
« Reply #14 on: November 06, 2011, 02:52:20 pm »