Re: Legality of a++ = 1 ?

Discussion in 'C Programming' started by Ian Collins, Mar 8, 2012.

  1. Ian Collins

    Ian Collins Guest

    On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    > Hi,
    > I read ISO/IEC 9899:201x, section 6.5.2.4 Postfix increment and decrement operators.
    >
    > Why couldn't the semantics of this be: "a" is assigned "1", then "a" is incremented?
    >
    > gcc gives error: lvalue required as left operand of assignment



    Because the result of a++ is a value, not a variable.

    --
    Ian Collins
     
    Ian Collins, Mar 8, 2012
    #1
    1. Advertising

  2. Ian Collins <> writes:
    > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    >> I read ISO/IEC 9899:201x, section 6.5.2.4 Postfix increment and decrement operators.
    >>
    >> Why couldn't the semantics of this be: "a" is assigned "1", then "a" is incremented?
    >>
    >> gcc gives error: lvalue required as left operand of assignment

    >
    > Because the result of a++ is a value, not a variable.


    And because it's easy enough to write "a = 1 + 1;" or "a = 2;".

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 8, 2012
    #2
    1. Advertising

  3. On Mar 8, 4:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    wrote:
    > On 08/03/12 18:21, Ian Collins wrote:
    >
    > > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    > >> Hi,
    > >> I read ISO/IEC 9899:201x, section 6.5.2.4 Postfix increment and
    > >> decrement operators.

    >
    > >> Why couldn't the semantics of this be: "a" is assigned "1", then "a"
    > >> is incremented?

    >
    > >> gcc gives error: lvalue required as left operand of assignment

    >
    > > Because the result of a++ is a value, not a variable.

    >
    > Yes, if it's on the RHS. If there's no real legality problem, i might just let
    > that exist as is instead of implementing extra code to disallow it;)


    You can do anything you like when you build your own compiler. Just
    be aware that the standard specifically states that the result of
    modifying a twice wihtout an intervening sequence point is officially
    undefined.

    It is also a constraint violation and a diagnostic is required.
     
    Barry Schwarz, Mar 8, 2012
    #3
  4. [ Legality of a++ = 1 ]
    On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    wrote:
    > On 08/03/12 18:21, Ian Collins wrote:
    > > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    > >> gcc gives error: lvalue required as left operand of assignment

    >
    > > Because the result of a++ is a value, not a variable.

    >
    > Yes, if it's on the RHS. If there's no real legality problem, i might just let
    > that exist as is instead of implementing extra code to disallow it;)


    No, it's always a value. If you can come up with a concrete sane
    proposal for making a++ an lvalue and a description of what the
    semantics should be, preferably without breaking existing valid code,
    I will be very impressed.
     
    Harald van Dijk, Mar 8, 2012
    #4
  5. Ian Collins

    James Kuyper Guest

    On 03/08/2012 01:22 PM, Harald van Dijk wrote:
    > [ Legality of a++ = 1 ]
    > On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    > wrote:
    >> On 08/03/12 18:21, Ian Collins wrote:
    >>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    >>>> gcc gives error: lvalue required as left operand of assignment

    >>
    >>> Because the result of a++ is a value, not a variable.

    >>
    >> Yes, if it's on the RHS. If there's no real legality problem, i might just let
    >> that exist as is instead of implementing extra code to disallow it;)

    >
    > No, it's always a value. If you can come up with a concrete sane
    > proposal for making a++ an lvalue and a description of what the
    > semantics should be, preferably without breaking existing valid code,
    > I will be very impressed.


    Since use of a++ as an lvalue currently is a constraint violation, I
    don't see how defining the meaning of such expressions could break
    existing valid code - if the new meaning is relevant, the code is, by
    definition, currently invalid.

    He proposed the semantics in his first message. In more general terms,
    he wants a++ = b to be equivalent to a = b + 1. Such semantics would
    violate an important (but I think, unwritten) principle in the design of
    the C language: evaluation of an expression consists of first evaluating
    all of its sub-expressions, producing either values or lvalues. Then
    evaluation of the higher level expression is defined in terms what it
    does with those values and lvalues.
    The proposed semantics for a++ = b can't be decomposed that way. This
    isn't completely unprecedented: the semantics of &*p are defined as
    being equivalent to p rather than &(*p). However, it's far easier to
    deal with complete removal of semantics (as in &*p), than with the kind
    of semantics proposed for a++ = b.

    The expression a = b + 1 is allowed by the current standard, and is far
    clearer than a++ = b. I can't see any reason to allow a++ = b, even if
    we were designing a new language from scratch. As a modification to an
    existing language, it doesn't come anywhere close to being sufficiently
    well motivated.
     
    James Kuyper, Mar 8, 2012
    #5
  6. On Mar 8, 8:11 pm, James Kuyper <> wrote:
    > On 03/08/2012 01:22 PM, Harald van Dijk wrote:
    > > [ Legality of a++ = 1 ]
    > > On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    > > wrote:
    > >> On 08/03/12 18:21, Ian Collins wrote:
    > >>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    > >>>> gcc gives error: lvalue required as left operand of assignment

    >
    > >>> Because the result of a++ is a value, not a variable.

    >
    > >> Yes, if it's on the RHS. If there's no real legality problem, i might just let
    > >> that exist as is instead of implementing extra code to disallow it;)

    >
    > > No, it's always a value. If you can come up with a concrete sane
    > > proposal for making a++ an lvalue and a description of what the
    > > semantics should be, preferably without breaking existing valid code,
    > > I will be very impressed.

    >
    > Since use of a++ as an lvalue currently is a constraint violation, I
    > don't see how defining the meaning of such expressions could break
    > existing valid code - if the new meaning is relevant, the code is, by
    > definition, currently invalid.


    I assume that whatever is proposed, it would also make a++ an lvalue
    in certain valid code where it is currently an rvalue. If not, then of
    course you're right.

    > He proposed the semantics in his first message. In more general terms,
    > he wants a++ = b to be equivalent to a = b + 1.


    I'm not asking for the semantics of the specific example a++ = b, I'm
    asking for the semantics of a++ used as an lvalue in general. Even for
    the example of a++ = b, I do not think I agree that he wants it to be
    equivalent to (a = b + 1). I think he wants it to be equivalent to (a
    = b, a++), except possibly unsequenced. The difference is that the
    result of the assignment expression is the value of b, converted to
    the type of a.

    > Such semantics [snip]


    I snipped this because you're assuming a specific exception for a++ =
    b, while I'm assuming a more general rule for a++ that would (for
    example) also allow &(a++). After all, the OP stated in a reply that
    he would simply drop the error message from the compiler and let the
    natural behaviour follow. Creating a specific exception for postfix ++
    in an assignment expression is not the natural behaviour.

    > The expression a = b + 1 is allowed by the current standard, and is far
    > clearer than a++ = b. I can't see any reason to allow a++ = b, even if
    > we were designing a new language from scratch. As a modification to an
    > existing language, it doesn't come anywhere close to being sufficiently
    > well motivated.


    Agreed.
     
    Harald van Dijk, Mar 8, 2012
    #6
  7. On Mar 8, 8:56 pm, Kenneth Brody <> wrote:
    > On 3/8/2012 1:22 PM, Harald van Dijk wrote:
    > > [ Legality of a++ = 1 ]
    > > On Mar 8, 11:53 am, Russell Shaw<rjshawN_o@s_pam.netspace.net.au>
    > > wrote:
    > >> On 08/03/12 18:21, Ian Collins wrote:
    > >>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    > >>>> gcc gives error: lvalue required as left operand of assignment

    >
    > >>> Because the result of a++ is a value, not a variable.

    >
    > >> Yes, if it's on the RHS. If there's no real legality problem, i might just let
    > >> that exist as is instead of implementing extra code to disallow it;)

    >
    > > No, it's always a value. If you can come up with a concrete sane
    > > proposal for making a++ an lvalue and a description of what the
    > > semantics should be, preferably without breaking existing valid code,
    > > I will be very impressed.

    >
    > And, if "a++" becomes an lvalue, what about "(a+=1)"?


    There is little problem in practise making (a+=1) and (++a) lvalues. C+
    + has done so for both, so we know it's possible.

    > This, of course, also ignores the part about modifying something twice
    > between sequence points.  (Does "a++ = 1;" result in "a" being 1 or 2?  And
    > if you're leaving it UB, what's the point in allowing it in the first place?)


    Quoting the original message:

    "Why couldn't the semantics of this be: "a" is assigned "1", then
    "a" is incremented?"

    So it would, as far as I can tell the OP is concerned, result in "a"
    being 2.
     
    Harald van Dijk, Mar 8, 2012
    #7
  8. Harald van Dijk <> writes:
    > [ Legality of a++ = 1 ]
    > On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    > wrote:
    >> On 08/03/12 18:21, Ian Collins wrote:
    >> > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    >> >> gcc gives error: lvalue required as left operand of assignment

    >>
    >> > Because the result of a++ is a value, not a variable.

    >>
    >> Yes, if it's on the RHS. If there's no real legality problem, i might just let
    >> that exist as is instead of implementing extra code to disallow it;)

    >
    > No, it's always a value. If you can come up with a concrete sane
    > proposal for making a++ an lvalue and a description of what the
    > semantics should be, preferably without breaking existing valid code,
    > I will be very impressed.


    For what it's worth, in C++ ++a is an lvalue (but a++ isn't).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 8, 2012
    #8
  9. Ian Collins

    James Kuyper Guest

    On 03/08/2012 02:28 PM, Harald van Dijk wrote:
    > On Mar 8, 8:11 pm, James Kuyper <> wrote:
    >> On 03/08/2012 01:22 PM, Harald van Dijk wrote:
    >>> [ Legality of a++ = 1 ]
    >>> On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    >>> wrote:
    >>>> On 08/03/12 18:21, Ian Collins wrote:
    >>>>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    >>>>>> gcc gives error: lvalue required as left operand of assignment

    >>
    >>>>> Because the result of a++ is a value, not a variable.

    >>
    >>>> Yes, if it's on the RHS. If there's no real legality problem, i might just let
    >>>> that exist as is instead of implementing extra code to disallow it;)

    >>
    >>> No, it's always a value. If you can come up with a concrete sane
    >>> proposal for making a++ an lvalue and a description of what the
    >>> semantics should be, preferably without breaking existing valid code,
    >>> I will be very impressed.

    >>
    >> Since use of a++ as an lvalue currently is a constraint violation, I
    >> don't see how defining the meaning of such expressions could break
    >> existing valid code - if the new meaning is relevant, the code is, by
    >> definition, currently invalid.

    >
    > I assume that whatever is proposed, it would also make a++ an lvalue
    > in certain valid code where it is currently an rvalue. If not, then of
    > course you're right.


    The standard doesn't use the term rvalue; it just uses the word value
    for that purpose. For a++ to be an lvalue, is, in itself, no more of a
    problem than the fact that 'a' itself is an lvalue. That fact doesn't
    prevent you from using 'a' in contexts where a value is required. The
    C++ standard talks about such things in terms of an implicit lvalue to
    rvalue conversion, but the C standard doesn't even bother with that.
    Lvalue expressions act as lvalues when they need to, and otherwise
    simply have ordinary values.

    >> He proposed the semantics in his first message. In more general terms,
    >> he wants a++ = b to be equivalent to a = b + 1.

    >
    > I'm not asking for the semantics of the specific example a++ = b, I'm
    > asking for the semantics of a++ used as an lvalue in general.


    My point was that the proposed semantics for a++ = b cannot be broken up
    into an lvalue returned by a++ that is used as a destination for = to
    write to. We don't need to even think about a++.member, and &a++ would
    presumably be equivalent to (a++, &a). The only other contexts where an
    lvalue is needed are more problematic:

    a++++ = b;
    a++-- = b;
    a--++ = b;
    a---- = b;

    ++a++ = b;
    ++a-- = b;
    --a++ = b;
    --a-- = b;

    ++++a = b;
    ++--a = b;
    --++a = b;
    ----a = b;

    and I have no idea what he wants done with those cases.

    > ... Even for
    > the example of a++ = b, I do not think I agree that he wants it to be
    > equivalent to (a = b + 1). I think he wants it to be equivalent to (a
    > = b, a++), except possibly unsequenced. ..


    His description is consistent only with it being sequenced. If the
    side-effect of a++ occurred before that of a=b, it wouldn't match his
    description.

    >.. The difference is that the
    > result of the assignment expression is the value of b, converted to
    > the type of a.


    He didn't say anything about the type or value of the expression as a
    whole. I suspect he's not given it much thought, and I didn't either.
    The possibilities that are consistent with what he said, which make
    sense to me, include (a = b + 1), (a=b,a++), or (__temp = a, a=b, a++,
    __temp), where __temp is a variable of the same type as 'a'. He might
    have had something else in mind.
     
    James Kuyper, Mar 8, 2012
    #9
  10. On Mar 8, 9:42 pm, James Kuyper <> wrote:
    > On 03/08/2012 02:28 PM, Harald van Dijk wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Mar 8, 8:11 pm, James Kuyper <> wrote:
    > >> On 03/08/2012 01:22 PM, Harald van Dijk wrote:
    > >>> [ Legality of a++ = 1 ]
    > >>> On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
    > >>> wrote:
    > >>>> On 08/03/12 18:21, Ian Collins wrote:
    > >>>>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
    > >>>>>> gcc gives error: lvalue required as left operand of assignment

    >
    > >>>>> Because the result of a++ is a value, not a variable.

    >
    > >>>> Yes, if it's on the RHS. If there's no real legality problem, i might just let
    > >>>> that exist as is instead of implementing extra code to disallow it;)

    >
    > >>> No, it's always a value. If you can come up with a concrete sane
    > >>> proposal for making a++ an lvalue and a description of what the
    > >>> semantics should be, preferably without breaking existing valid code,
    > >>> I will be very impressed.

    >
    > >> Since use of a++ as an lvalue currently is a constraint violation, I
    > >> don't see how defining the meaning of such expressions could break
    > >> existing valid code - if the new meaning is relevant, the code is, by
    > >> definition, currently invalid.

    >
    > > I assume that whatever is proposed, it would also make a++ an lvalue
    > > in certain valid code where it is currently an rvalue. If not, then of
    > > course you're right.

    >
    > The standard doesn't use the term rvalue; it just uses the word value
    > for that purpose. For a++ to be an lvalue, is, in itself, no more of a
    > problem than the fact that 'a' itself is an lvalue. That fact doesn't
    > prevent you from using 'a' in contexts where a value is required.


    Agreed, but the description of the lvalue-postfix-++ would need to be
    phrased in such a way that the lvalue-to-rvalue conversion (sorry, the
    lvalue-to-value conversion) is applied before the side effect of ++
    has taken place, in those cases where currently the result of a++
    would be used directly as a value.

    > The
    > C++ standard talks about such things in terms of an implicit lvalue to
    > rvalue conversion, but the C standard doesn't even bother with that.
    > Lvalue expressions act as lvalues when they need to, and otherwise
    > simply have ordinary values.


    The C standard pretty much calls it an lvalue-to-value conversion in
    6.3.2.1p2: "An lvalue that [...] is converted to the value stored in
    the designated object [...]".

    > >> He proposed the semantics in his first message. In more general terms,
    > >> he wants a++ = b to be equivalent to a = b + 1.

    >
    > > I'm not asking for the semantics of the specific example a++ = b, I'm
    > > asking for the semantics of a++ used as an lvalue in general.

    >
    > My point was that the proposed semantics for a++ = b cannot be broken up
    > into an lvalue returned by a++ that is used as a destination for = to
    > write to.


    The evaluation of a++ could return a as an lvalue, and schedule the
    side effect of (a += 1) at some as of yet unspecified later time.
    Needlessly complicated for code that deserves to be broken, but not
    impossible.

    > We don't need to even think about a++.member,


    ++ cannot be applied to structures or unions in C, but in C++, if a
    class defines a custom postfix ++ operator, a++.member is valid but
    typically retrieves the member from the rvalue structure result.

    > and &a++ would
    > presumably be equivalent to (a++, &a)


    That's not what I would expect. If &a++ is equivalent to (a++, &a),
    then *&a++'s value is different from that of a++.

    >. The only other contexts where an
    > lvalue is needed are more problematic:
    >
    >         a++++ = b;
    >         a++-- = b;
    >         a--++ = b;
    >         a---- = b;
    >
    >         ++a++ = b;
    >         ++a-- = b;
    >         --a++ = b;
    >         --a-- = b;
    >
    >         ++++a = b;
    >         ++--a = b;
    >         --++a = b;
    >         ----a = b;
    >
    > and I have no idea what he wants done with those cases.


    Interestingly, in C++, the prefix ++ and -- operators can be combined
    in exactly the way you describe.

    > > ... Even for
    > > the example of a++ = b, I do not think I agree that he wants it to be
    > > equivalent to (a = b + 1). I think he wants it to be equivalent to (a
    > > = b, a++), except possibly unsequenced. ..

    >
    > His description is consistent only with it being sequenced. If the
    > side-effect of a++ occurred before that of a=b, it wouldn't match his
    > description.


    Good point.

    > >.. The difference is that the
    > > result of the assignment expression is the value of b, converted to
    > > the type of a.

    >
    > He didn't say anything about the type or value of the expression as a
    > whole. I suspect he's not given it much thought, and I didn't either.


    For whatever reason, I did. Or tried to, anyway.

    > The possibilities that are consistent with what he said, which make
    > sense to me, include (a = b + 1), (a=b,a++), or (__temp = a, a=b,a++,
    > __temp), where __temp is a variable of the same type as 'a'. He might
    > have had something else in mind.


    Another possibility: if a++ is an lvalue, why can't a = b, and
    therefore a++ = b be too?
     
    Harald van Dijk, Mar 8, 2012
    #10
  11. Ian Collins

    BartC Guest

    "Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
    news:...
    >>>>> [ Legality of a++ = 1 ]


    > I am writing a C compiler and it can be hard to pinpoint answers in the
    > C99 standard. 6.5.2, 6.5.3, and its footnotes looks like a relevent answer
    > to disallowing a reliable sequence of operations for a++ = b.


    Then it depends on whether A++ can be an lvalue. The 'A' part will be
    (otherwise you wouldn't be able to use ++ on it). But it's lvalue-ness is
    already expended on '++'; Can you re-use this value on the result of the
    whole 'A++' term?

    If you can, then you will also be able to do &(A++), and A++ ++ ++, and all
    sorts of weird stuff. But some of this, including A++=B would be changing a
    variable twice between sequence points (which is a big no-no in C).

    Apart from which, no-one looking at A++=B would have a clue what it's
    supposed to mean. So if mainstream compilers won't accept it, then I would
    just forget about it.

    > Half the effort is in figuring out whether something that is technically
    > doable is politically allowed by the standard.


    It is very tempting when writing compilers to improve on the language,
    especially it is trivial to do so. But any sorts of extensions to C are
    usually frowned upon, unless ratified by a committee. Or you can just
    forget the Standard...

    --
    Bartc
     
    BartC, Mar 9, 2012
    #11
  12. Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:
    <snip>
    > I am writing a C compiler and it can be hard to pinpoint answers in
    > the C99 standard. 6.5.2, 6.5.3, and its footnotes looks like a
    > relevent answer to disallowing a reliable sequence of operations for
    > a++ = b.


    6.5.16.1 (simple assignment) is also important, of course. But C
    disallows very little. The often feared "undefined behaviour" just
    means that the C standard has nothing to say on the matter, so you are
    free to do what you like in undefined situations.

    a++ = b is a constraint violation so a diagnostic is required, but it
    does not even have to relate to that piece of code. Your compiler could
    announce at the start:

    "This compiler accepts extensions to the C language."

    and you will have conformed to the letter of the standard. Of course,
    people like to be told where their code uses extensions, so something
    more specific is helpful, despite not being required.

    In this case, though, I have to wonder what the advantage of allowing
    a++ = b is. It's not expensive to check since lvalue-ness (if I you can
    forgive such an ugly term) is a property of syntactic forms. You can
    flag up things like this with very little extra code at all.

    > Half the effort is in figuring out whether something that is
    > technically doable is politically allowed by the standard.


    --
    Ben.
     
    Ben Bacarisse, Mar 9, 2012
    #12
  13. Ian Collins

    BartC Guest

    "Keith Thompson" <> wrote in message
    news:...
    > Harald van Dijk <> writes:
    >> [ Legality of a++ = 1 ]


    >> No, it's always a value. If you can come up with a concrete sane
    >> proposal for making a++ an lvalue and a description of what the
    >> semantics should be, preferably without breaking existing valid code,
    >> I will be very impressed.

    >
    > For what it's worth, in C++ ++a is an lvalue (but a++ isn't).


    How would the ++a work? Like this:

    int a=1000;

    ++a += 3; // a is now 1004?

    --
    Bartc
     
    BartC, Mar 9, 2012
    #13
  14. "BartC" <> writes:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> Harald van Dijk <> writes:
    >>> [ Legality of a++ = 1 ]

    >
    >>> No, it's always a value. If you can come up with a concrete sane
    >>> proposal for making a++ an lvalue and a description of what the
    >>> semantics should be, preferably without breaking existing valid code,
    >>> I will be very impressed.

    >>
    >> For what it's worth, in C++ ++a is an lvalue (but a++ isn't).

    >
    > How would the ++a work? Like this:
    >
    > int a=1000;
    >
    > ++a += 3; // a is now 1004?


    I get 1004 using the g++ compiler -- but as in C, modifying an object
    twice without an intervening sequence point has undefined behavior.

    I think the usefulness of allowing ++a to be an lvalue shows up when
    "++" is an overloaded operator.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 9, 2012
    #14
  15. On Mar 9, 8:17 pm, Keith Thompson <> wrote:
    > "BartC" <> writes:
    > > "Keith Thompson" <> wrote in message
    > >> For what it's worth, in C++ ++a is an lvalue (but a++ isn't).

    >
    > > How would the ++a work? Like this:

    >
    > > int a=1000;

    >
    > > ++a += 3;    // a is now 1004?


    Yes.

    > I get 1004 using the g++ compiler -- but as in C, modifying an object
    > twice without an intervening sequence point has undefined behavior.


    C++ introduces sequence points after the side effect for prefix ++.
    (Actually, it does so for a += 1, and ++a is defined to be equivalent
    to a += 1.) It has to, or the lvalue-to-rvalue conversion in a = ++b
    would be undefined. The example of a ^= b ^= a ^= b, given in the C
    FAQ as an example of undefined behaviour, is valid in C++.

    > I think the usefulness of allowing ++a to be an lvalue shows up when
    > "++" is an overloaded operator.


    When ++ is an overloaded operator, the overloaded operator determines
    the type and lvalue-ness of the result. That's no reason why the built-
    in types' prefix ++ should return lvalues.
     
    Harald van Dijk, Mar 9, 2012
    #15
    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. Brandon
    Replies:
    1
    Views:
    540
    Jim Lewis
    Aug 4, 2005
  2. Kamilche

    Legality of using Fonts

    Kamilche, Feb 10, 2006, in forum: Python
    Replies:
    10
    Views:
    650
  3. Replies:
    14
    Views:
    618
    Daniel Pitts
    Dec 13, 2006
  4. Legality of pointer arithmetic

    , Aug 2, 2005, in forum: C Programming
    Replies:
    10
    Views:
    583
    Eric Sosman
    Aug 5, 2005
  5. Martin Eisenberg

    legality of forward declaration

    Martin Eisenberg, May 31, 2006, in forum: C Programming
    Replies:
    11
    Views:
    715
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
    Jun 2, 2006
Loading...

Share This Page