On Oct 10, 2008, at 1:52 AM, wasti wrote: > > I'm sorry. But I've always learned that rvalues and lvalues are > strictly > opposed. The statement above thus is illogical - rvals cannot be > lvals or > non-lvals. Non-lvals *are* rvals. Values can be lvalues or rvalues. > Anything else is opposed to the terminology the C++ standard (at > least) > uses and can only bring chaotic confusion. In a few months, nobody > will be > able to understand the code in question anymore.
Hi Sebastian, These are very valid points, and I appreciate you taking the time to elucidate them. I will admit that I am not as well-versed as I should with how these terms are used in the C++ standard. The confusion here probably stems from my original interpretation of the term rvalue, which comes more from a PL theory perspective rather than a litigious interpretation of the C++ standard. Zhongxing already lucidly explained in his own email what these terms mean in the static analyzer, so I won't reiterate those points here. I have never really loved using the terms LVal or NonLVal anyway, and if those concepts are more directly adopted into the core parts of Clang then having this naming scheme for these classes will probably add more confusion. > In fact, something I've noticed in the code of Clang is that rvalues > and > lvalues are not seen as strictly distinct, probably because this > distinction is not that important in C. Can you be a little more specific about what you mean by "the code of Clang?" Zhongxing's patch, and the focus of this thread, has to do with code in libAnalysis, which really isn't a "core" library in Clang (i.e., like the Parser or Sema). Do you feel these terms are used incorrectly within the core libraries of the frontend itself? > In C++, with references and (in > C++0x) rvalue vs lvalue references, with complicated rules about which > temporaries can be elided that also partially depend on rvalue vs > lvalue > issues, this distinction feels very important to me. Your point is well taken. > In writing code (and > thinking about code to write) for validation of the C++ cast > operators, I > have felt the lack of a clear distinction as something that made my > code > harder to understand. If you are interested or have time, it would be great if you could help propel a discussion (in a separate thread) about these issues, your experience with implementing features in Clang because of these issues, and so on so that we can potentially propel Clang's design to better represent the distinction between rvalues and lvalues. Cheers, Ted _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
