invalid use of 'this' outside of a non-static member function

Hi,

The compiler accepted it, so IMHO LLDB should not complain about it.

I can rename this “this” inside a C function, but it is very likely that other people would name a variable “this” inside C code.

All expressions are compiled in C++ mode and thus the restriction.

There are a few solutions:
1 - make expressions match the current language of the current frame. So if your function was a C function, you will be restricted from using C++ in your expression
2 - rename your "this" and benefit from the C++ abilities of the expression parser

I personally really like the ability to use "auto" and all of the C++11 constructs in any expression:

(lldb) expr for (auto x = 0; x < my_renamed_this; ++x) { ... }

So I see the problem with C expressions, but I would rather not limit you from being able to access your C++ code from a C function by limiting the language based on where you are stopped.

Greg

The canonical Windows command line debugger solves this by having two different evaluation modes. One for C and one for C++. I believe C++ is always the default, but C evaluation mode can be forced by enclosing an expression in special delimiters. You can toggle the evaluation mode multiple times inside the same expression as well. So you can have a single expression where different pieces of it are evaluated differently.

Not a language lawyer, but it seems like other stuff would be broken besides just variables named ‘this’. Are there any other known causes of incorrect evaluation in C frames due to using a C++ evaluation mode?

Other way around actually now that I looked it up, C++ is not the default mode but can be specified when desired. Obviously their expression evaluator is much more limited for other reasons such as not having a full blown compiler backing it up, but still, something like this is a 3rd option (choosing a reasonable default and allowing escaping to force evaluation of certain pieces in another mode)

All expressions are compiled in C++ mode and thus the restriction.

There are a few solutions:
1 - make expressions match the current language of the current frame. So
if your function was a C function, you will be restricted from using C++ in
your expression
2 - rename your "this" and benefit from the C++ abilities of the
expression parser

I personally really like the ability to use "auto" and all of the C++11
constructs in any expression:

(lldb) expr for (auto x = 0; x < my_renamed_this; ++x) { ... }

So I see the problem with C expressions, but I would rather not limit you
from being able to access your C++ code from a C function by limiting the
language based on where you are stopped.

Thanks, but was not ware how do you switch the current language of the
current frame
that is fine, though at the point where the keyword this is tested, a
simple ( and frame.language != "C" ) could be implemented, or?

The expression parser uses C++ features (specifically references) to implement capturing values from expressions. It rewrites the expressions before compiling them to do this. So for now we need to compile our expressions in C++ mode in order for them to work at all...

It is certainly possible to rework how the expression parser does this bit of business so we can support a straight C parsing mode, either by having a modified C mode in clang that allows references or by some other tricks in the parser itself. But this hasn't caused enough problems to warrant digging into this up to now.

Jim