When is lvalue-to-rvalue conversion required?

Discussion in 'C++' started by ZMZ, Feb 24, 2011.

  1. ZMZ

    ZMZ Guest

    I've read from a number of sources about the following statements,
    they make sense to me but I can't find similar statement in the
    standard. My question is: are the following statements true? Thanks.

    The addition (multiplication, etc) operator expects both of its two
    operands to be rvalue, and the result of the expression is rvalue. So
    there is definitely an lvalue-to-rvalue conversion if the supplied
    operands are lvalues.

    The left side of assignment operator is expected to be lvalue, and the
    right side of the assignment operator is expected to be rvalue. So if
    the right side is an lvalue, lvalue-to-rvalue conversion will be
    performed too.

    There are also something slightly different statements from the
    Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    that, the addition etc operator operand can be lvalue or rvalue, so
    according to his statement, there's no need to have an lvalue-to-
    rvalue conversion if the supplied operand is lvalue.

    Thanks for reading.
    ZMZ, Feb 24, 2011
    #1
    1. Advertising

  2. ZMZ

    Paul Guest

    "ZMZ" <> wrote in message
    news:...
    > I've read from a number of sources about the following statements,
    > they make sense to me but I can't find similar statement in the
    > standard. My question is: are the following statements true? Thanks.
    >
    > The addition (multiplication, etc) operator expects both of its two
    > operands to be rvalue, and the result of the expression is rvalue. So
    > there is definitely an lvalue-to-rvalue conversion if the supplied
    > operands are lvalues.
    >
    > The left side of assignment operator is expected to be lvalue, and the
    > right side of the assignment operator is expected to be rvalue. So if
    > the right side is an lvalue, lvalue-to-rvalue conversion will be
    > performed too.
    >

    Thats certainly one way to over-complicate a simple arithmetic expression.

    > There are also something slightly different statements from the
    > Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    > that, the addition etc operator operand can be lvalue or rvalue, so
    > according to his statement, there's no need to have an lvalue-to-
    > rvalue conversion if the supplied operand is lvalue.
    >
    > Thanks for reading.
    >

    I guess I could play around with those words and make them mean whatever I
    want them to mean. its such a confusication.

    I think you look to much into , what is a very simple arithmethic
    expression, why are you intereseted in this confusication?
    Paul, Feb 24, 2011
    #2
    1. Advertising

  3. ZMZ

    ZMZ Guest

    On Feb 24, 1:37 pm, "Paul" <> wrote:
    > "ZMZ" <> wrote in message
    >
    > news:...> I've read from a number of sources about the following statements,
    > > they make sense to me but I can't find similar statement in the
    > > standard. My question is: are the following statements true? Thanks.

    >
    > > The addition (multiplication, etc) operator expects both of its two
    > > operands to be rvalue, and the result of the expression is rvalue. So
    > > there is definitely an lvalue-to-rvalue conversion if the supplied
    > > operands are lvalues.

    >
    > > The left side of assignment operator is expected to be lvalue, and the
    > > right side of the assignment operator is expected to be rvalue. So if
    > > the right side is an lvalue, lvalue-to-rvalue conversion will be
    > > performed too.

    >
    > Thats certainly one way to over-complicate a simple arithmetic expression..
    >
    > > There are also something slightly different statements from the
    > > Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    > > that, the addition etc operator operand can be lvalue or rvalue, so
    > > according to his statement, there's no need to have an lvalue-to-
    > > rvalue conversion if the supplied operand is lvalue.

    >
    > > Thanks for reading.

    >
    > I guess I could play around with those words and make them mean whatever I
    > want them to mean. its such a confusication.
    >
    > I think you look to much into , what is a very simple arithmethic
    > expression, why are you intereseted in this confusication?


    Hi Paul, I am interested in it because recently I am confused about
    some statements in Standard N3225 regarding constant expressions.

    As far as what I can understand, const has problem because const data
    are not guaranteed to be a compile time constants, see the following
    example (from standard),

    struct S {
    static const int size;
    };
    const int limit = 2 * S::size; // dynamic initialization
    const int S::size = 256;

    So, constexpr is proposed to solve this problem. The following
    shouldn't work!

    struct S {
    static const int size;
    };
    constexpr int limit = 2 * S::size; // shall be error in my
    understanding
    const int S::size = 256;

    As in 7.1.5/9, we see the constexpr that refers to object,

    A constexpr specifier used in an object declaration declares the
    object as const. ....(unrelated).... Otherwise, every full-expression
    that appears in its initializer shall
    be a constant expression. ....(unrelated)....

    In my understanding, it means that, constexpr int limit = 2 * S::size;
    this is illegal because S::size is not a constant expression because
    it hasn't been initialized yet.

    Now let's look at 5.19 constant expressions,

    A conditional-expression is a constant expression unless it involves
    one of the following as a potentially evaluated
    subexpression:

    Then 5.19 listed many things that are not considered constant
    expression, but to my surprise, it doesn't mention that UNINITIALIZED
    const static is not a constant expression. There is one clause though,
    that says,

    — an lvalue-to-rvalue conversion (4.1) unless it is applied to

    — a glvalue of integral or enumeration type that refers to
    a non-volatile const object with a preceding
    initialization, initialized with a constant expression, or

    Here is the only place I find that the standard put constraint of
    initialization on constant expression: if a glvalue is of integral or
    enumeration that refers to a const object that is initialized, and
    that glvalue is participated into lvalue-to-rvalue conversion, then it
    is considered as constant expression.

    So it comes to my current confusion, is lvalue-to-rvalue conversion
    shall be applied to every +, *, / and = operators? If so, then the
    clause in 5.19 "— an lvalue-to-rvalue conversion (4.1) unless it is
    applied to" will cover many cases and make sense that uninitialized
    right hand side isn't a constant expression.

    If not so, I will say that 5.19 didn't cover all cases? At least I
    can't find any match to say S::size in the above example isn't a
    constant expression.
    ZMZ, Feb 24, 2011
    #3
  4. ZMZ

    Paul Guest

    "ZMZ" <> wrote in message
    news:...
    On Feb 24, 1:37 pm, "Paul" <> wrote:
    > "ZMZ" <> wrote in message
    >
    > news:...>
    > I've read from a number of sources about the following statements,
    > > they make sense to me but I can't find similar statement in the
    > > standard. My question is: are the following statements true? Thanks.

    >
    > > The addition (multiplication, etc) operator expects both of its two
    > > operands to be rvalue, and the result of the expression is rvalue. So
    > > there is definitely an lvalue-to-rvalue conversion if the supplied
    > > operands are lvalues.

    >
    > > The left side of assignment operator is expected to be lvalue, and the
    > > right side of the assignment operator is expected to be rvalue. So if
    > > the right side is an lvalue, lvalue-to-rvalue conversion will be
    > > performed too.

    >
    > Thats certainly one way to over-complicate a simple arithmetic expression.
    >
    > > There are also something slightly different statements from the
    > > Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    > > that, the addition etc operator operand can be lvalue or rvalue, so
    > > according to his statement, there's no need to have an lvalue-to-
    > > rvalue conversion if the supplied operand is lvalue.

    >
    > > Thanks for reading.

    >
    > I guess I could play around with those words and make them mean whatever I
    > want them to mean. its such a confusication.
    >
    > I think you look to much into , what is a very simple arithmethic
    > expression, why are you intereseted in this confusication?


    --Hi Paul, I am interested in it because recently I am confused about
    --some statements in Standard N3225 regarding constant expressions.

    --As far as what I can understand, const has problem because const data
    --are not guaranteed to be a compile time constants, see the following
    --example (from standard),

    --struct S {
    --static const int size;
    --};
    --const int limit = 2 * S::size; // dynamic initialization
    --const int S::size = 256;

    --So, constexpr is proposed to solve this problem. The following
    --shouldn't work!

    --struct S {
    --static const int size;
    --};
    --constexpr int limit = 2 * S::size; // shall be error in my
    --understanding
    --const int S::size = 256;

    --As in 7.1.5/9, we see the constexpr that refers to object,

    --A constexpr specifier used in an object declaration declares the
    --object as const. ....(unrelated).... Otherwise, every full-expression
    --that appears in its initializer shall
    --be a constant expression. ....(unrelated)....

    --In my understanding, it means that, constexpr int limit = 2 * S::size;
    --this is illegal because S::size is not a constant expression because
    --it hasn't been initialized yet.

    Yes this seems unclear, especially since there are two very similar terms
    i.e:
    constexpr
    and
    constant expression
    which seem to be unrelated.


    --Now let's look at 5.19 constant expressions,

    --A conditional-expression is a constant expression unless it involves
    --one of the following as a potentially evaluated
    --subexpression:

    Now this seems to be talking specifically about a conditional expression
    i.e:
    an if statement.

    --Then 5.19 listed many things that are not considered constant
    --expression, but to my surprise, it doesn't mention that UNINITIALIZED
    --const static is not a constant expression. There is one clause though,
    --that says,

    — an lvalue-to-rvalue conversion (4.1) unless it is applied to

    — a glvalue of integral or enumeration type that refers to
    a non-volatile const object with a preceding
    initialization, initialized with a constant expression, or

    --Here is the only place I find that the standard put constraint of
    --initialization on constant expression: if a glvalue is of integral or
    --enumeration that refers to a const object that is initialized, and
    --that glvalue is participated into lvalue-to-rvalue conversion, then it
    --is considered as constant expression.

    --So it comes to my current confusion, is lvalue-to-rvalue conversion
    --shall be applied to every +, *, / and = operators? If so, then the
    --clause in 5.19 "— an lvalue-to-rvalue conversion (4.1) unless it is
    --applied to" will cover many cases and make sense that uninitialized
    --right hand side isn't a constant expression.

    --If not so, I will say that 5.19 didn't cover all cases? At least I
    --can't find any match to say S::size in the above example isn't a
    --constant expression.

    My rules are to initialise contants where there are declared, but in statics
    I guess I woud initialise it immediately after the class definition.
    I don't think the keyword constexpr existed when I learned C++, thankyou for
    exposing me to this.

    I can understand you wanting to understand the rules of the language , but I
    can't help there I'm afraid.
    I have never got so deeply into the rules of constantness.

    GL , I'm sure some expert on the standard, or a compiler developer will be
    able to explain what is going on.

    Paul.
    Paul, Feb 24, 2011
    #4
  5. ZMZ

    James Kanze Guest

    On Feb 24, 5:05 am, ZMZ <> wrote:
    > I've read from a number of sources about the following statements,
    > they make sense to me but I can't find similar statement in the
    > standard. My question is: are the following statements true? Thanks.


    > The addition (multiplication, etc) operator expects both of its two
    > operands to be rvalue, and the result of the expression is rvalue. So
    > there is definitely an lvalue-to-rvalue conversion if the supplied
    > operands are lvalues.


    > The left side of assignment operator is expected to be lvalue, and the
    > right side of the assignment operator is expected to be rvalue. So if
    > the right side is an lvalue, lvalue-to-rvalue conversion will be
    > performed too.


    Both of the above are true.

    > There are also something slightly different statements from the
    > Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    > that, the addition etc operator operand can be lvalue or rvalue, so
    > according to his statement, there's no need to have an lvalue-to-
    > rvalue conversion if the supplied operand is lvalue.


    Loosely speaking, since the lvalue to rvalue conversion is
    always possible, anywhere an rvalue is required, an lvalue can
    be used.

    Historically, IIRC, K&R didn't use the term rvalue. Lvalue was
    something like an attribute that an expression had, or didn't
    have; expressions either required it, or didn't. In the end, it
    comes out to the same thing in most cases, just expressed
    differently. The one case where it might make a difference is
    when the lvalue to rvalue conversion triggers undefined
    behavior; e.g. when accessing an uninitialized variable: you can
    use an uninitialized variable as an lvalue (e.g. on the left
    side of an assignment operator), but not as an rvalue (on the
    right side of an assignment operator, or as an operand to the
    + operator).

    --
    James Kanze
    James Kanze, Feb 24, 2011
    #5
  6. ZMZ

    ZMZ Guest

    On Feb 24, 3:00 pm, "Paul" <> wrote:
    > "ZMZ" <> wrote in message
    >
    > news:...
    > On Feb 24, 1:37 pm, "Paul" <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > "ZMZ" <> wrote in message

    >
    > >news:....>
    > > I've read from a number of sources about the following statements,
    > > > they make sense to me but I can't find similar statement in the
    > > > standard. My question is: are the following statements true? Thanks.

    >
    > > > The addition (multiplication, etc) operator expects both of its two
    > > > operands to be rvalue, and the result of the expression is rvalue. So
    > > > there is definitely an lvalue-to-rvalue conversion if the supplied
    > > > operands are lvalues.

    >
    > > > The left side of assignment operator is expected to be lvalue, and the
    > > > right side of the assignment operator is expected to be rvalue. So if
    > > > the right side is an lvalue, lvalue-to-rvalue conversion will be
    > > > performed too.

    >
    > > Thats certainly one way to over-complicate a simple arithmetic expression.

    >
    > > > There are also something slightly different statements from the
    > > > Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    > > > that, the addition etc operator operand can be lvalue or rvalue, so
    > > > according to his statement, there's no need to have an lvalue-to-
    > > > rvalue conversion if the supplied operand is lvalue.

    >
    > > > Thanks for reading.

    >
    > > I guess I could play around with those words and make them mean whatever I
    > > want them to mean. its such a confusication.

    >
    > > I think you look to much into , what is a very simple arithmethic
    > > expression, why are you intereseted in this confusication?

    >
    > --Hi Paul, I am interested in it because recently I am confused about
    > --some statements in Standard N3225 regarding constant expressions.
    >
    > --As far as what I can understand, const has problem because const data
    > --are not guaranteed to be a compile time constants, see the following
    > --example (from standard),
    >
    > --struct S {
    > --static const int size;
    > --};
    > --const int limit = 2 * S::size; // dynamic initialization
    > --const int S::size = 256;
    >
    > --So, constexpr is proposed to solve this problem. The following
    > --shouldn't work!
    >
    > --struct S {
    > --static const int size;
    > --};
    > --constexpr int limit = 2 * S::size; // shall be error in my
    > --understanding
    > --const int S::size = 256;
    >
    > --As in 7.1.5/9, we see the constexpr that refers to object,
    >
    > --A constexpr specifier used in an object declaration declares the
    > --object as const.  ....(unrelated).... Otherwise, every full-expression
    > --that appears in its initializer shall
    > --be a constant expression. ....(unrelated)....
    >
    > --In my understanding, it means that, constexpr int limit = 2 * S::size;
    > --this is illegal because S::size is not a constant expression because
    > --it hasn't been initialized yet.
    >
    > Yes this seems unclear, especially since there are two very similar terms
    > i.e:
    > constexpr
    > and
    > constant expression
    > which seem to be unrelated.
    >
    > --Now let's look at 5.19 constant expressions,
    >
    > --A conditional-expression is a constant expression unless it involves
    > --one of the following as a potentially evaluated
    > --subexpression:
    >
    > Now this seems to be talking specifically about a conditional expression
    > i.e:
    > an if statement.
    >
    > --Then 5.19 listed many things that are not considered constant
    > --expression, but to my surprise, it doesn't mention that UNINITIALIZED
    > --const static is not a constant expression. There is one clause though,
    > --that says,
    >
    > � an lvalue-to-rvalue conversion (4.1) unless it is applied to
    >
    >     � a glvalue of integral or enumeration type that refers to
    >         a non-volatile const object with a preceding
    >         initialization, initialized with a constant expression, or
    >
    > --Here is the only place I find that the standard put constraint of
    > --initialization on constant expression: if a glvalue is of integral or
    > --enumeration that refers to a const object that is initialized, and
    > --that glvalue is participated into lvalue-to-rvalue conversion, then it
    > --is considered as constant expression.
    >
    > --So it comes to my current confusion, is lvalue-to-rvalue conversion
    > --shall be applied to every +, *, / and = operators? If so, then the
    > --clause in 5.19 "� an lvalue-to-rvalue conversion (4.1) unless it is
    > --applied to" will cover many cases and make sense that uninitialized
    > --right hand side isn't a constant expression.
    >
    > --If not so, I will say that 5.19 didn't cover all cases? At least I
    > --can't find any match to say S::size in the above example isn't a
    > --constant expression.
    >
    > My rules are to initialise contants where there are declared, but in statics
    > I guess I woud  initialise it immediately after the class definition.
    > I don't think the keyword constexpr existed when I learned C++, thankyou for
    > exposing me to this.
    >
    > I can understand you wanting to understand the rules of the language , but I
    > can't help there I'm afraid.
    > I have never got so deeply into the rules of constantness.
    >
    > GL , I'm sure some expert on the standard, or a compiler developer will be
    > able to explain what is going on.
    >
    > Paul.


    Thanks. I think I might be over focusing on the details.
    ZMZ, Feb 24, 2011
    #6
  7. ZMZ

    ZMZ Guest

    On Feb 24, 4:35 pm, James Kanze <> wrote:
    > On Feb 24, 5:05 am, ZMZ <> wrote:
    >
    > > I've read from a number of sources about the following statements,
    > > they make sense to me but I can't find similar statement in the
    > > standard. My question is: are the following statements true? Thanks.
    > > The addition (multiplication, etc) operator expects both of its two
    > > operands to be rvalue, and the result of the expression is rvalue. So
    > > there is definitely an lvalue-to-rvalue conversion if the supplied
    > > operands are lvalues.
    > > The left side of assignment operator is expected to be lvalue, and the
    > > right side of the assignment operator is expected to be rvalue. So if
    > > the right side is an lvalue, lvalue-to-rvalue conversion will be
    > > performed too.

    >
    > Both of the above are true.
    >
    > > There are also something slightly different statements from the
    > > Internet, e.g., somebody in his tutorial on lvalue and rvalue thinks
    > > that, the addition etc operator operand can be lvalue or rvalue, so
    > > according to his statement, there's no need to have an lvalue-to-
    > > rvalue conversion if the supplied operand is lvalue.

    >
    > Loosely speaking, since the lvalue to rvalue conversion is
    > always possible, anywhere an rvalue is required, an lvalue can
    > be used.
    >
    > Historically, IIRC, K&R didn't use the term rvalue.  Lvalue was
    > something like an attribute that an expression had, or didn't
    > have; expressions either required it, or didn't.  In the end, it
    > comes out to the same thing in most cases, just expressed
    > differently.  The one case where it might make a difference is
    > when the lvalue to rvalue conversion triggers undefined
    > behavior; e.g. when accessing an uninitialized variable: you can
    > use an uninitialized variable as an lvalue (e.g. on the left
    > side of an assignment operator), but not as an rvalue (on the
    > right side of an assignment operator, or as an operand to the
    > + operator).
    >
    > --
    > James Kanze


    Thanks. This is what I wanted to know.
    ZMZ, Feb 24, 2011
    #7
  8. ZMZ

    ZMZ Guest

    I just learnt from my StackOverflow on the same question, and Arelius
    told me that, in the standard 3.10 (only in C++98 and 2003 standard,
    not present in N3225),

    [ Note: some built-in operators expect lvalue operands. [ Example:
    built-in assignment operators all expect their left-hand operands to
    be lvalues. — end example ] Other built-in operators yield rvalues,
    and some expect them. [ Example: the unary and binary + operators
    expect rvalue arguments and yield rvalue results. — end example ] The
    discussion of each built-in operator in clause 5 indicates whether it
    expects lvalue operands and whether it yields an lvalue. — end note ]
    ZMZ, Feb 25, 2011
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Mantoulidis

    ++x returns lvalue but x++ return rvalue

    Chris Mantoulidis, Dec 28, 2003, in forum: C++
    Replies:
    4
    Views:
    494
    Chris Mantoulidis
    Dec 29, 2003
  2. Gonzalo Aguirre

    rvalue / lvalue operator[]

    Gonzalo Aguirre, Jan 2, 2004, in forum: C++
    Replies:
    4
    Views:
    444
    Ron Natalie
    Jan 2, 2004
  3. Denis Remezov

    lvalue rvalue

    Denis Remezov, Jul 16, 2004, in forum: C++
    Replies:
    12
    Views:
    852
  4. Kavya
    Replies:
    9
    Views:
    508
    Dik T. Winter
    Oct 28, 2006
  5. Juha Nieminen
    Replies:
    13
    Views:
    613
    Edek Pienkowski
    Aug 29, 2012
Loading...

Share This Page