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
> On Jan 7, 2015, at 11:48 AM, mobi phil <m...@mobiphil.com> wrote:
>
> 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?
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
