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)<br><br><div class="gmail_quote">On Wed Jan 07 2015 at 10:57:30 AM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br><div><br></div><div>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?</div><br><div class="gmail_quote">On Wed Jan 07 2015 at 10:51:43 AM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All expressions are compiled in C++ mode and thus the restriction.<br>
<br>
There are a few solutions:<br>
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<br>
2 - rename your "this" and benefit from the C++ abilities of the expression parser<br>
<br>
I personally really like the ability to use "auto" and all of the C++11 constructs in any expression:<br>
<br>
(lldb) expr for (auto x = 0; x < my_renamed_this; ++x) { ... }<br>
<br>
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.<br>
<br>
Greg<br>
<br>
> On Jan 7, 2015, at 7:16 AM, mobi phil <<a href="mailto:mobi@mobiphil.com" target="_blank">mobi@mobiphil.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> The compiler accepted it, so IMHO LLDB should not complain about it.<br>
><br>
> 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.<br>
><br>
><br>
> rgrds,<br>
> mobi phil<br>
><br>
><br>
> ______________________________<u></u><u></u>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/lldb-dev</a><br>
<br>
<br>
______________________________<u></u><u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/lldb-dev</a><br>
</blockquote></div></blockquote></div>