[cfe-commits] [PATCH] Expressions have lvalues and rvalues

[Ted Kremenek]

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