|
|
 Up |
|
|
  |
Author: bintombintom Date: May 8, 2008 17:16
Why doe the following C++ code behaves as it does?
int i;
i=1; cout << (++i)++; Output: 2
i=1; cout << ++(++i); Output: 3
i=1; cout << (i++)++; Output: Error. LValue required
i=1; cout << ++(i++); Output: Error. LValue required
|
| |
|
| | 11 Comments |
|
|
Author: Ian CollinsIan Collins Date: May 8, 2008 17:17
bintom wrote:
Once is enough!
--
Ian Collins.
|
| |
|
| | no comments |
|
|
Author: Martin YorkMartin York Date: May 9, 2008 10:11
On May 8, 5:16 pm, bintom gmail.com> wrote:> Why doe the following C++ code behaves as it does?
>
> int i;
>
> i=1; cout << (++i)++; Output: 2
> i=1; cout << ++(++i); Output: 3
> i=1; cout << (i++)++; Output: Error. LValue required
> i=1; cout << ++(i++); Output: Error. LValue required
Because code like that is so hard to read you would never actually
write it!
Also remember that it is illegal to modify a variable more than once
within the same expression [undefined behavior I believe](somebody
with a copy of the standard will be able to quote you chapter an verse
and the actual definition rather than my layman's wording).
|
| |
| no comments |
|
|
Author: Victor BazarovVictor Bazarov Date: May 9, 2008 10:21
Martin York wrote:
> On May 8, 5:16 pm, bintom gmail.com> wrote:>> Why doe the following C++ code behaves as it does?
>>
>> int i;
>>
>> i=1; cout << (++i)++; Output: 2
>> i=1; cout << ++(++i); Output: 3
>> i=1; cout << (i++)++; Output: Error. LValue
>> required i=1; cout << ++(i++); Output: Error.
>> LValue required
>
> Because code like that is so hard to read you would never actually
> write it!
>
> Also remember that it is illegal to modify a variable more than once
> within the same expression [undefined behavior I believe](somebody
> with a copy of the standard will be able to quote you chapter an verse
> and the actual definition rather than my layman's wording).
|
| Show full article (1.25Kb) |
| no comments |
|
|
Author: James KanzeJames Kanze Date: May 10, 2008 07:08
On 9 mai, 19:21, "Victor Bazarov" comAcast.net> wrote:> Martin York wrote:
>> On May 8, 5:16 pm, bintom gmail.com> wrote:>>> Why doe the following C++ code behaves as it does?
>>> int i;
>>> i=1; cout << (++i)++; Output: 2
>>> i=1; cout << ++(++i); Output: 3
>>> i=1; cout << (i++)++; Output: Error. LValue
>>> required i=1; cout << ++(i++); Output: Error.
>>> LValue required
>> Because code like that is so hard to read you would never actually
>> write it!
>> Also remember that it is illegal to modify a variable more
>> than once within the same expression [undefined behavior I
>> believe](somebody with a copy of the standard will be able
>> to quote you chapter an verse and the actual definition
>> rather than my layman's wording).
> Only a variable of a built-in type,
No. The rule holds for all types.
|
| Show full article (2.52Kb) |
| no comments |
|
|
Author: Jerry CoffinJerry Coffin Date: May 10, 2008 07:47
> For example, it's not undefined behaviour to do
>
> f(i++) + ++i;
>
> IIRC, but the results are unspecified.
I believe this still gives undefined behavior. There are three sequence
points in this expression: before f is called, when f returns, and at
the end of the expression. The compiler can generate code that evaluates
the pre-increment, then the post-increment, then the function call.
There's no sequence point between the pre- and post-increment, so the
result is undefined behavior.
> And if your class has the
> operators ++() or ++(int) overloaded, the results are even well-
> defined and predictable. For 'int' they aren't...
|
| Show full article (2.10Kb) |
| no comments |
|
|
Author: Jerry CoffinJerry Coffin Date: May 10, 2008 08:01
> On 9 mai, 19:21, "Victor Bazarov" comAcast.net> wrote:
[ ... ]
>> For example, it's not undefined behaviour to do
>
>> f(i++) + ++i;
>
> Yes it is, since there is no sequence point between the two
> incrementations. Sequence points only define a partial
> ordering: there is a sequence point before calling f, but that
> only establishes and ordering between i++ and the call to f; it
> doesn't establish any ordering between the two incrementations.
I believe it establishes _some_ ordering, but not enough[1]. In
particular, I believe the compiler is required to treat evaluation of a
function argument and calling the function as atomic -- i.e. once the
evaluation of any argument takes place, it must proceed to evaluated the
other arguments (if any) and then call the function.
|
| Show full article (1.96Kb) |
| no comments |
|
|
Author: Bo PerssonBo Persson Date: May 11, 2008 01:56
Jerry Coffin wrote:
>> On 9 mai, 19:21, "Victor Bazarov" comAcast.net> wrote:>
> [ ... ]
>
>>> For example, it's not undefined behaviour to do
>>
>>> f(i++) + ++i;
>>
>> Yes it is, since there is no sequence point between the two
>> incrementations. Sequence points only define a partial
>> ordering: there is a sequence point before calling f, but that
>> only establishes and ordering between i++ and the call to f; it
>> doesn't establish any ordering between the two incrementations.
>
> I believe it establishes _some_ ordering, but not enough[1]. In
> particular, I believe the compiler is required to treat evaluation ...
|
| Show full article (2.52Kb) |
| no comments |
|
|
Author: Old WolfOld Wolf Date: May 11, 2008 02:14
On May 11, 3:01 am, Jerry Coffin taeus.com> wrote:>> On 9 mai, 19:21, "Victor Bazarov" comAcast.net> wrote:>>> For example, it's not undefined behaviour to do
>>>> f(i++) + ++i;
>
> I believe the compiler is required to treat evaluation of a
> function argument and calling the function as atomic -- i.e. once the
> evaluation of any argument takes place, it must proceed to evaluated the
> other arguments (if any) and then call the function.
There is no such requirement. In the following code,
for example,:
foo( bar(), baz() ) + qux();
the order of calling functions could be:
baz, qux, bar, foo.
or any other ordering, so long as 'foo' comes after
both 'bar' and 'baz'.
The code of Victor Bazarov causes undefined behaviour
if 'i' is a builtin type, because there might not be
a sequence point between the two modifications of 'i'.
|
| |
| no comments |
|
|
|
|
|
Author: Jerry CoffinJerry Coffin Date: May 11, 2008 08:05
>> 1: Though it's open to some question. $1.9/8 says: "Once the
>> execution of a function begins, no expressions from the calling
>> function are evaluated until execution of the called function has
>> completed."
>>
>> I'm interpreting evaluating the arguments to a function as part of
>> execution of the function. If you choose to interpret it as a
>> completely separate act that happens before the function's
>> execution, then you're right -- no ordering is defined. At least in
>> this case, it doesn't make any real difference though -- the
>> overall result is undefined behavior either way.
>
> I think your second interpretation is the correct one. It means that
> ++i can be evalueated before or after calling f, but not during.
You could _certainly_ be right. As I said, in this case it doesn't
really make much difference, since either one gives undefined results.
|
| Show full article (1.87Kb) |
| no comments |
|
|
|
|
