Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #3476 > unrolled thread

simple session question

Back to article view | Back to comp.lang.php

Contents

  simple session question cerr <ron.eggler@gmail.com> - 2011-10-21 10:44 -0700
    Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-21 20:19 +0200
      Re: simple session question Jonathan Stein <jstein@image.dk> - 2011-10-21 20:51 +0200
        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-21 22:00 +0200
          Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-21 16:14 -0400
            Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 00:50 +0200
              Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-21 19:05 -0400
                Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 15:40 +0200
                  Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 17:19 -0400
                    Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 22:56 +0100
                      Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 00:35 +0200
                      Re: simple session question Tim Streater <timstreater@greenbee.net> - 2011-10-22 23:43 +0100
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:56 +0200
                      Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 19:29 -0400
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:54 +0200
                    Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 02:12 +0200
                      Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 21:13 -0400
                        Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 08:44 +0100
                          Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 17:31 +0200
                            Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 17:18 +0100
                              Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 19:14 +0200
                                Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 18:16 +0100
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 19:00 +0200
                          Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-23 15:28 -0400
                      Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-22 23:03 -0400
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 19:06 +0200
                          Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-23 14:35 -0400
              Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 00:32 +0100
                Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 12:01 +0200
                  Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 15:27 +0100
                    Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 15:37 +0100
                      Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 17:08 +0200
                        OT: and even in Dart .........Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 17:17 +0200
                          Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 16:54 +0100
                            Re: OT: and even in Dart .........Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 18:47 +0200
                              Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 19:34 +0200
                                Re: OT: and even in Dart .........Re: simple session question Norman Peelman <npeelmandog@cfl.rr.com> - 2011-10-22 16:08 -0400
                                  Re: OT: and even in Dart .........Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-22 16:28 -0400
                                    Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:39 +0200
                                    Re: OT: and even in Dart .........Re: simple session question Norman Peelman <npeelmandog@cfl.rr.com> - 2011-10-22 22:40 -0400
                                      Re: OT: and even in Dart .........Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-22 23:05 -0400
                                  Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 22:52 +0100
                                    Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:25 +0200
                                      Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 08:41 +0100
                                  Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 00:56 +0200
                                    Re: OT: and even in Dart .........Re: simple session question Norman Peelman <npeelmandog@cfl.rr.com> - 2011-10-22 22:52 -0400
                                      Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 17:12 +0200
                                    Re: OT: and even in Dart .........Re: simple session question Tim Streater <timstreater@greenbee.net> - 2011-10-23 09:39 +0100
                                      Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 09:40 +0100
                                        Re: OT: and even in Dart .........Re: simple session question Tim Streater <timstreater@greenbee.net> - 2011-10-23 09:43 +0100
                                  Re: OT: and even in Dart .........Re: simple session question "Peter H. Coffin" <hellsop@ninehells.com> - 2011-11-05 15:04 -0500
                                Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 22:47 +0100
                                  Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:22 +0200
                                    Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 08:40 +0100
                                      Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 17:04 +0200
                            Re: OT: and even in Dart .........Re: simple session question "Peter H. Coffin" <hellsop@ninehells.com> - 2011-11-05 15:00 -0500
                Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 15:39 +0200
      Re: simple session question cerr <ron.eggler@gmail.com> - 2011-10-21 14:43 -0700
        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 00:47 +0200
        Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-21 19:06 -0400
      Re: simple session question cerr <ron.eggler@gmail.com> - 2011-10-21 14:17 -0700
        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 15:50 +0200
      Re: simple session question Denis McMahon <denismfmcmahon@gmail.com> - 2011-10-23 15:47 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#3476 — simple session question

Hi There,

I'm a session newbie and got a (probably) simple question:
I have belowcode and i would expect stp to count up from 1 to 3 then
back to 1 when ever I reload this page but it for some reason always
stays at 0. Why that?

Thank you for assistance!

My code:

if(!isset($_SESSION['stp'])) {
  session_start();
  $_SESSION['stp'] = 0;
  echo "session started<br>\n";
}
switch($_SESSION['stp']) {
  case 0: $_SESSION['stp'] = $_SESSION['stp']++;
		  echo "stp:".$_SESSION['stp'];
		  break;
  case 1: $_SESSION['stp'] = $_SESSION['stp']++;
		  echo "stp:".$_SESSION['stp'];
		  break;
  case 2: $_SESSION['stp'] = $_SESSION['stp']++;
		  echo "stp:".$_SESSION['stp'];
          $_SESSION['stp'] = 0;
		  break;

[toc] | [next] | [standalone]

#3477

cerr schrieb:

> if(!isset($_SESSION['stp'])) {
>   session_start();
>   $_SESSION['stp'] = 0;
>   echo "session started<br>\n";
> }

You need to call session_start() on *every* page request, not just when 
you initialize the session (think of it as 
"session_start_or_continue()"). The $_SESSION superglobal does not exist 
until you have called session_start(), so your code above won't work.

> switch($_SESSION['stp']) {
>   case 0: $_SESSION['stp'] = $_SESSION['stp']++;
> 		  echo "stp:".$_SESSION['stp'];
> 		  break;
>   case 1: $_SESSION['stp'] = $_SESSION['stp']++;
> 		  echo "stp:".$_SESSION['stp'];
> 		  break;
>   case 2: $_SESSION['stp'] = $_SESSION['stp']++;
> 		  echo "stp:".$_SESSION['stp'];
>           $_SESSION['stp'] = 0;
> 		  break;

You're missing a } here. But even with that and the session_start() 
issue fixed, it always prints 0. I'm not quite sure why, but anyway your 
code is unnecessarily complicated. Here's my version:

session_start();
if ( !isset( $_SESSION['stp'] ) )
{
     $_SESSION['stp'] = 0;
     echo "session started<br>\n";
}

echo $_SESSION['stp'];
$_SESSION['stp'] = ( $_SESSION['stp'] + 1 ) % 3;

I use the modulo operator % to achieve the cycling through the values 0, 
1, 2.

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3478

Den 21-10-2011 20:19, Thomas Mlynarczyk skrev:

>> case 0: $_SESSION['stp'] = $_SESSION['stp']++;

With ++ after the variable, it is increased AFTER it has been used for 
the calculation. So this happens:

1) The value of "$_SESSION['stp']++" is calculated. (Result: 0)

2) $_SESSION['stp'] is increased.

3) $_SESSION['stp'] is assigned the previously calculated value (zero).

It should work with ++$_SESSION['stp'], but still it's redundant to 
assign the value of a variable to itself.

- And then the solution presented by Thomas is still far more elegant.

   Regards

     Jonathan

[toc] | [prev] | [next] | [standalone]

#3479

Jonathan Stein schrieb:

> 1) The value of "$_SESSION['stp']++" is calculated. (Result: 0)
> 2) $_SESSION['stp'] is increased.
> 3) $_SESSION['stp'] is assigned the previously calculated value (zero).

Ah, thanks for helping me see through this. In other words:

$foo = 0;
$foo = $foo++;

is basically equivalent to

$foo = 0;
$tmp = $foo;
$foo = $foo + 1;
$foo = $tmp;

although one should probably not rely on that behaviour. This is 
probably a good candidate for an obfuscated code contest.

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3480

On 10/21/2011 4:00 PM, Thomas Mlynarczyk wrote:
> Jonathan Stein schrieb:
>
>> 1) The value of "$_SESSION['stp']++" is calculated. (Result: 0)
>> 2) $_SESSION['stp'] is increased.
>> 3) $_SESSION['stp'] is assigned the previously calculated value (zero).
>
> Ah, thanks for helping me see through this. In other words:
>
> $foo = 0;
> $foo = $foo++;
>
> is basically equivalent to
>
> $foo = 0;
> $tmp = $foo;
> $foo = $foo + 1;
> $foo = $tmp;
>
> although one should probably not rely on that behaviour. This is
> probably a good candidate for an obfuscated code contest.
>
> Greetings,
> Thomas
>
>

The behavior is correct, and can be relied upon 100%.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3483

Jerry Stuckle schrieb:

>> $foo = 0;
>> $foo = $foo++;
>>
>> is basically equivalent to
>>
>> $foo = 0;
>> $tmp = $foo;
>> $foo = $foo + 1;
>> $foo = $tmp;
> 
> The behavior is correct, and can be relied upon 100%.

Is that mentioned somewhere in the manual? Anyway, to me, $foo = $foo++ 
looks like asking for trouble.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3484

On 10/21/2011 6:50 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>>> $foo = 0;
>>> $foo = $foo++;
>>>
>>> is basically equivalent to
>>>
>>> $foo = 0;
>>> $tmp = $foo;
>>> $foo = $foo + 1;
>>> $foo = $tmp;
>>
>> The behavior is correct, and can be relied upon 100%.
>
> Is that mentioned somewhere in the manual? Anyway, to me, $foo = $foo++
> looks like asking for trouble.
>
> Greetings,
> Thomas
>

Yes, see how operator precedence works.  It is well defined.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3490

Jerry Stuckle schrieb:
[$foo = $foo++;]
>> Is that mentioned somewhere in the manual?
> Yes, see how operator precedence works.  It is well defined.

It is the internal order of execution that confuses me a bit. First, the 
expression on the right is evaluated, yielding the "not-yet-incremented" 
value. Then, two things must happen: Incrementing $foo and assigning 
$foo the value from the first step. The result depends on the order of 
these two steps. Clearly, the increment should happen before the next 
read access to $foo. But whether or not it happens before the next write 
access (assigning $foo the value from the first step) is neither 
intuitively clear (and optimizers might handle this one way or the 
other) nor explicitly stated in 
<http://de3.php.net/manual/en/language.operators.increment.php>. There 
is only a user comment saying: "The exact moment when post-increment and 
post-decrement happen is _just immediately after the variable is 
evaluated_ (not "after the line is processed" or something like that)". 
If this is meant to be documented behaviour, they should mention it as 
such in the manual.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3508

On 10/22/11 9:40 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
> [$foo = $foo++;]
>>> Is that mentioned somewhere in the manual?
>> Yes, see how operator precedence works. It is well defined.
>
> It is the internal order of execution that confuses me a bit. First, the
> expression on the right is evaluated, yielding the "not-yet-incremented"
> value. Then, two things must happen: Incrementing $foo and assigning
> $foo the value from the first step. The result depends on the order of
> these two steps. Clearly, the increment should happen before the next
> read access to $foo. But whether or not it happens before the next write
> access (assigning $foo the value from the first step) is neither
> intuitively clear (and optimizers might handle this one way or the
> other) nor explicitly stated in
> <http://de3.php.net/manual/en/language.operators.increment.php>. There
> is only a user comment saying: "The exact moment when post-increment and
> post-decrement happen is _just immediately after the variable is
> evaluated_ (not "after the line is processed" or something like that)".
> If this is meant to be documented behaviour, they should mention it as
> such in the manual.
>
> Greetings,
> Thomas
>

I suspect that there is a difference between the execution model of 
C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a 
compiled language with the goal of allowing the compiler to generate as 
efficient of code as possible, while PHP is designed as a interpreted 
language.

in C,  x = x++; is undefined behavior, as the timing of when the = 
operator is executed and the writing back of the value of x++ from the 
++ operator is not specified, depending on when the compiler can most 
efficiently implement it is ok. The code could be converted into the 
equivalent of either.

temp = x; /* save original value of x */
x = x+1   /* perform increment */
x = temp; /* perform the = */

or
x = x; /* perform the = */
x = x+1; /* perform the ++ */

PHP doesn't seem to reserve for itself this ability, and there seems to 
be some comments (which you refer to) asserting that x++ will ALWAY be 
the equivalent of

temp = x;
x = x+1;
... do what ever with temp

Which being an interpreted language makes some sense, why put off doing 
something, and recording somewhere that you need to do it, when you can 
do it now, the possible savings that C might have been able to make, get 
swamped by the other overhead in PHP.

One thing is that we have a "formal spec" for the C language, created 
and distributed by an international standard organization (ISO). is 
there an equivalent of this for PHP, or do we only really have a single 
implementation of PHP (in various versions), with "documentation" for 
its behavior.

[toc] | [prev] | [next] | [standalone]

#3512

Richard Damon wrote:
> On 10/22/11 9:40 AM, Thomas Mlynarczyk wrote:
>> Jerry Stuckle schrieb:
>> [$foo = $foo++;]
>>>> Is that mentioned somewhere in the manual?
>>> Yes, see how operator precedence works. It is well defined.
>>
>> It is the internal order of execution that confuses me a bit. First, the
>> expression on the right is evaluated, yielding the "not-yet-incremented"
>> value. Then, two things must happen: Incrementing $foo and assigning
>> $foo the value from the first step. The result depends on the order of
>> these two steps. Clearly, the increment should happen before the next
>> read access to $foo. But whether or not it happens before the next write
>> access (assigning $foo the value from the first step) is neither
>> intuitively clear (and optimizers might handle this one way or the
>> other) nor explicitly stated in
>> <http://de3.php.net/manual/en/language.operators.increment.php>. There
>> is only a user comment saying: "The exact moment when post-increment and
>> post-decrement happen is _just immediately after the variable is
>> evaluated_ (not "after the line is processed" or something like that)".
>> If this is meant to be documented behaviour, they should mention it as
>> such in the manual.
>>
>> Greetings,
>> Thomas
>>
> 
> I suspect that there is a difference between the execution model of 
> C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a 
> compiled language with the goal of allowing the compiler to generate as 
> efficient of code as possible, while PHP is designed as a interpreted 
> language.
> 
> in C,  x = x++; is undefined behavior, as the timing of when the = 
> operator is executed and the writing back of the value of x++ from the 
> ++ operator is not specified, depending on when the compiler can most 
> efficiently implement it is ok. The code could be converted into the 
> equivalent of either.
> 

I dont think it is. The value of x is assigned before the increment 
operator is applied: that's defined.


> temp = x; /* save original value of x */
> x = x+1   /* perform increment */
> x = temp; /* perform the = */
> 
> or
> x = x; /* perform the = */
> x = x+1; /* perform the ++ */
> 
> PHP doesn't seem to reserve for itself this ability, and there seems to 
> be some comments (which you refer to) asserting that x++ will ALWAY be 
> the equivalent of
> 
> temp = x;
> x = x+1;
> ... do what ever with temp
> 

BUT that doesnt cover the $bar=($foo++);

That should be
INC [foo]
MOV [bar].[foo];

NOT the other way around.

But in php it is.

[toc] | [prev] | [next] | [standalone]

#3513

The Natural Philosopher schrieb:

> BUT that doesnt cover the $bar=($foo++);
> 
> That should be
> INC [foo]
> MOV [bar].[foo];

That would be $bar = ( ++$foo );

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3514

In article <j7ve6a$svk$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Richard Damon wrote:
> > On 10/22/11 9:40 AM, Thomas Mlynarczyk wrote:
> >> Jerry Stuckle schrieb:
> >> [$foo = $foo++;]
> >>>> Is that mentioned somewhere in the manual?
> >>> Yes, see how operator precedence works. It is well defined.
> >>
> >> It is the internal order of execution that confuses me a bit. First, the
> >> expression on the right is evaluated, yielding the "not-yet-incremented"
> >> value. Then, two things must happen: Incrementing $foo and assigning
> >> $foo the value from the first step. The result depends on the order of
> >> these two steps. Clearly, the increment should happen before the next
> >> read access to $foo. But whether or not it happens before the next write
> >> access (assigning $foo the value from the first step) is neither
> >> intuitively clear (and optimizers might handle this one way or the
> >> other) nor explicitly stated in
> >> <http://de3.php.net/manual/en/language.operators.increment.php>. There
> >> is only a user comment saying: "The exact moment when post-increment and
> >> post-decrement happen is _just immediately after the variable is
> >> evaluated_ (not "after the line is processed" or something like that)".
> >> If this is meant to be documented behaviour, they should mention it as
> >> such in the manual.
> >>
> >> Greetings,
> >> Thomas
> >>
> > 
> > I suspect that there is a difference between the execution model of 
> > C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a 
> > compiled language with the goal of allowing the compiler to generate as 
> > efficient of code as possible, while PHP is designed as a interpreted 
> > language.
> > 
> > in C,  x = x++; is undefined behavior, as the timing of when the = 
> > operator is executed and the writing back of the value of x++ from the 
> > ++ operator is not specified, depending on when the compiler can most 
> > efficiently implement it is ok. The code could be converted into the 
> > equivalent of either.
> > 
> 
> I dont think it is. The value of x is assigned before the increment 
> operator is applied: that's defined.
> 
> 
> > temp = x; /* save original value of x */
> > x = x+1   /* perform increment */
> > x = temp; /* perform the = */
> > 
> > or
> > x = x; /* perform the = */
> > x = x+1; /* perform the ++ */
> > 
> > PHP doesn't seem to reserve for itself this ability, and there seems to 
> > be some comments (which you refer to) asserting that x++ will ALWAY be 
> > the equivalent of
> > 
> > temp = x;
> > x = x+1;
> > ... do what ever with temp
> > 
> 
> BUT that doesnt cover the $bar=($foo++);
> 
> That should be
> INC [foo]
> MOV [bar].[foo];
> 
> NOT the other way around.
> 
> But in php it is.

Mmmm. I'm not sure about that. In JavaScript (also interpreted) I do a 
lot of:

i = 0;
first  = results[i++];
second = results[i++];
etc

and first, second, get the zeroth and oneth elements of results, 
respectively. So the ++ is done *after* the assignment.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#3521

Tim Streater schrieb:

> Mmmm. I'm not sure about that. In JavaScript (also interpreted) I do a 
> lot of:
> 
> i = 0;
> first  = results[i++];
> second = results[i++];
> etc
> 
> and first, second, get the zeroth and oneth elements of results, 
> respectively. So the ++ is done *after* the assignment.

Yes. As long as you have two different operands, there is no problem. 
But what does i = i++ do?

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3518

On 10/22/11 5:56 PM, The Natural Philosopher wrote:
> Richard Damon wrote:
>> On 10/22/11 9:40 AM, Thomas Mlynarczyk wrote:
>>> Jerry Stuckle schrieb:
>>> [$foo = $foo++;]
>>>>> Is that mentioned somewhere in the manual?
>>>> Yes, see how operator precedence works. It is well defined.
>>>
>>> It is the internal order of execution that confuses me a bit. First, the
>>> expression on the right is evaluated, yielding the "not-yet-incremented"
>>> value. Then, two things must happen: Incrementing $foo and assigning
>>> $foo the value from the first step. The result depends on the order of
>>> these two steps. Clearly, the increment should happen before the next
>>> read access to $foo. But whether or not it happens before the next write
>>> access (assigning $foo the value from the first step) is neither
>>> intuitively clear (and optimizers might handle this one way or the
>>> other) nor explicitly stated in
>>> <http://de3.php.net/manual/en/language.operators.increment.php>. There
>>> is only a user comment saying: "The exact moment when post-increment and
>>> post-decrement happen is _just immediately after the variable is
>>> evaluated_ (not "after the line is processed" or something like that)".
>>> If this is meant to be documented behaviour, they should mention it as
>>> such in the manual.
>>>
>>> Greetings,
>>> Thomas
>>>
>>
>> I suspect that there is a difference between the execution model of
>> C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a
>> compiled language with the goal of allowing the compiler to generate
>> as efficient of code as possible, while PHP is designed as a
>> interpreted language.
>>
>> in C, x = x++; is undefined behavior, as the timing of when the =
>> operator is executed and the writing back of the value of x++ from the
>> ++ operator is not specified, depending on when the compiler can most
>> efficiently implement it is ok. The code could be converted into the
>> equivalent of either.
>>
>
> I dont think it is. The value of x is assigned before the increment
> operator is applied: that's defined.
>
>

Where do you see the definition of assignment first? In fact, from the 
earlier examples, it is clear that at least those version of PHP did the 
increment first.

The wording of the $a++ postfix operator is that it "Returns $a, then 
increments $a by one." which if you want to be a stickler, requires the 
interpreter to fork, as after the execution "returns" it can't continue 
to do something. I think what they meant (as shown by the tests 
upthread) that $a++ increments $a, but returns the value of saved value 
of $a prior to the increment. To get an assignment comes first you would 
need something like: returns the current value of $a and then at [what 
here?] increments the value of $a. For [what here] you would need to add 
something like Cs sequence points, for example in

$b = f($a++);

would $a be incremented before calling f, or after the assignment to $b?

>> temp = x; /* save original value of x */
>> x = x+1 /* perform increment */
>> x = temp; /* perform the = */
>>
>> or
>> x = x; /* perform the = */
>> x = x+1; /* perform the ++ */
>>
>> PHP doesn't seem to reserve for itself this ability, and there seems
>> to be some comments (which you refer to) asserting that x++ will ALWAY
>> be the equivalent of
>>
>> temp = x;
>> x = x+1;
>> ... do what ever with temp
>>
>
> BUT that doesnt cover the $bar=($foo++);
>
> That should be
> INC [foo]
> MOV [bar].[foo];
>
> NOT the other way around.
>
> But in php it is.

Putting $foo++ inside parens SHOULD change its meaning to ++$foo !!! The 
value of the $foo++ operator is *always* the value of $foo before the 
increment.

Parens force operators inside them to bind to operands before an 
operator outside can bind to them. Let us say that * bound tighter than 
++ (thankfully it doesn't, not much does)

then $a*$b++ would ordinarily be parsed the same as ($a*$b)++, (which 
generates an error) but $a*($b++) generates what we normally want.


in the same way, fa()*(fb()+fc()), the () mean that we add the value of 
fb() to fc() before we multiply by fa(). but does NOT imply that fa() 
itself will be evaluated afterwards. To my knowledge, PHP does not 
define the order that operands are evaluated in an expression, only the 
precedence of the operators for which one binds tighter to the operand, 
except for the logical operators which will always evaluate the left 
operand first, and only if it then needs the value of the right operand, 
evaluate that.

[toc] | [prev] | [next] | [standalone]

#3520

Richard Damon schrieb:

> [...] To my knowledge, PHP does not 
> define the order that operands are evaluated in an expression [...]

Okay, but it wouldn't make any difference for $foo = $foo++. Let's 
rewrite this in pseudo-code:

$foo = 0;
assign( $foo, postincrement( $foo ) );

If we evaluate the operands of assign() in the specified order, we get 0 
and 0. If we evaluate them in reverse order, we get 1 and 0. Since the 
assignment simply overwrites the first operand's value, we end up with 0 
in both cases.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3522

Richard Damon schrieb:

> I suspect that there is a difference between the execution model of 
> C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a 
> compiled language with the goal of allowing the compiler to generate as 
> efficient of code as possible, while PHP is designed as a interpreted 
> language.

Hm. But PHP is written in C, so I would assume it to just follow C here.

> x = x; /* perform the = */
> x = x+1; /* perform the ++ */

That could be further optimized by dropping the x = x. But here the 
assignment seems to have a higher precedence than the increment.

> temp = x;
> x = x+1;
> ... do what ever with temp
> 
> Which being an interpreted language makes some sense, why put off doing 
> something, and recording somewhere that you need to do it, when you can 
> do it now, the possible savings that C might have been able to make, get 
> swamped by the other overhead in PHP.

Now I wonder why x = x++ is undefined in C. If it was defined to be a no 
op as it behaves in PHP, then it could be optimized away completely.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3523

On 10/22/11 8:12 PM, Thomas Mlynarczyk wrote:
> Richard Damon schrieb:
>
>> I suspect that there is a difference between the execution model of
>> C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a
>> compiled language with the goal of allowing the compiler to generate
>> as efficient of code as possible, while PHP is designed as a
>> interpreted language.
>
> Hm. But PHP is written in C, so I would assume it to just follow C here.
>
>> x = x; /* perform the = */
>> x = x+1; /* perform the ++ */
>
> That could be further optimized by dropping the x = x. But here the
> assignment seems to have a higher precedence than the increment.
>
>> temp = x;
>> x = x+1;
>> ... do what ever with temp
>>
>> Which being an interpreted language makes some sense, why put off
>> doing something, and recording somewhere that you need to do it, when
>> you can do it now, the possible savings that C might have been able to
>> make, get swamped by the other overhead in PHP.
>
> Now I wonder why x = x++ is undefined in C. If it was defined to be a no
> op as it behaves in PHP, then it could be optimized away completely.
>
> Greetings,
> Thomas
>

The issue is C is that there is a general rule (to allow optimizations) 
that defines the behavior to be undefined if an expression causes a 
variable to be written to twice, or have a read from and write to (where 
the read from is not needed to determine the value to write to) without 
an intervening sequence point, like the end of an expression.

The statement x = x++; has two different writes to x, so we meet the 
requirement for undefined behavior. Not also that C does not limit when 
the ++ part happens, only that this side effect will finish by the next 
sequence point.

Part of the problem with this example is that it is a bit to simple, and 
that simplicity hides some of the issues. Let us make the expression 
just slightly more complicated to make it cleared. Let us use x = 5*x++;

This expression has two different value paths:

x = 5 * x; (the main expression) and
x = x + 1; (the side effect of x++)

The only ordering that C puts on these two expressions is that the read 
for x in the first, must happen before the write of x in the second (due 
to the definition of x++).

Thus in C the net expression is likely to be one of:

x = x+1;  (if the first expression finishes first, and then the second, 
using the original value of x)
x = 5*x; (if the second expression finishes first, and then the first, 
using the original value of x)
x = 5*x+1; (if the first expression finishes first, and then the second, 
using the new value of x)

It is even possible on some machines that the program will trap, as C 
doesn't limit the possible effect on undefined behavior. This might 
happen on a machine which is pipelined, and there is a restriction on 
either writing a value and reading it back to quickly, or doing two 
writes to closely.

This example may seem simple enough that the compiler should catch it, 
but what if the statement was:

*y = x++;

and y just happened to point to x.

PHP, not trying to allow the compiler to generate as efficient code, 
doesn't need to allow for the ambiguity in when the increment occurs, 
and it makes sense to do it right away. Knowing C, I don't see them 
making that explicit promise, but the way it is worded, if you didn't 
know C, it seems to be what would be expected.

[toc] | [prev] | [next] | [standalone]

#3530

Richard Damon wrote:
> On 10/22/11 8:12 PM, Thomas Mlynarczyk wrote:
>> Richard Damon schrieb:
>>
>>> I suspect that there is a difference between the execution model of
>>> C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a
>>> compiled language with the goal of allowing the compiler to generate
>>> as efficient of code as possible, while PHP is designed as a
>>> interpreted language.
>>
>> Hm. But PHP is written in C, so I would assume it to just follow C here.
>>
>>> x = x; /* perform the = */
>>> x = x+1; /* perform the ++ */
>>
>> That could be further optimized by dropping the x = x. But here the
>> assignment seems to have a higher precedence than the increment.
>>
>>> temp = x;
>>> x = x+1;
>>> ... do what ever with temp
>>>
>>> Which being an interpreted language makes some sense, why put off
>>> doing something, and recording somewhere that you need to do it, when
>>> you can do it now, the possible savings that C might have been able to
>>> make, get swamped by the other overhead in PHP.
>>
>> Now I wonder why x = x++ is undefined in C. If it was defined to be a no
>> op as it behaves in PHP, then it could be optimized away completely.
>>
>> Greetings,
>> Thomas
>>
> 
> The issue is C is that there is a general rule (to allow optimizations) 
> that defines the behavior to be undefined if an expression causes a 
> variable to be written to twice, or have a read from and write to (where 
> the read from is not needed to determine the value to write to) without 
> an intervening sequence point, like the end of an expression.
> 
> The statement x = x++; has two different writes to x, so we meet the 
> requirement for undefined behavior. Not also that C does not limit when 
> the ++ part happens, only that this side effect will finish by the next 
> sequence point.
> 
> Part of the problem with this example is that it is a bit to simple, and 
> that simplicity hides some of the issues. Let us make the expression 
> just slightly more complicated to make it cleared. Let us use x = 5*x++;
> 
> This expression has two different value paths:
> 
> x = 5 * x; (the main expression) and
> x = x + 1; (the side effect of x++)
> 
> The only ordering that C puts on these two expressions is that the read 
> for x in the first, must happen before the write of x in the second (due 
> to the definition of x++).
> 
> Thus in C the net expression is likely to be one of:
> 
> x = x+1;  (if the first expression finishes first, and then the second, 
> using the original value of x)
> x = 5*x; (if the second expression finishes first, and then the first, 
> using the original value of x)
> x = 5*x+1; (if the first expression finishes first, and then the second, 
> using the new value of x)
> 
> It is even possible on some machines that the program will trap, as C 
> doesn't limit the possible effect on undefined behavior. This might 
> happen on a machine which is pipelined, and there is a restriction on 
> either writing a value and reading it back to quickly, or doing two 
> writes to closely.
> 
> This example may seem simple enough that the compiler should catch it, 
> but what if the statement was:
> 
> *y = x++;
> 
> and y just happened to point to x.
> 
> PHP, not trying to allow the compiler to generate as efficient code, 
> doesn't need to allow for the ambiguity in when the increment occurs, 
> and it makes sense to do it right away. Knowing C, I don't see them 
> making that explicit promise, but the way it is worded, if you didn't 
> know C, it seems to be what would be expected.


Forget the foo=foo++ and consider the cases

bar=foo++;
and
bar=(foo++).


In C they give different results. in PHP they do not.

[toc] | [prev] | [next] | [standalone]

#3539

The Natural Philosopher schrieb:
> Forget the foo=foo++ and consider the cases
> 
> bar=foo++;
> and
> bar=(foo++).
> 
> In C they give different results.

Interesting. If I remember correctly, ++ has higher precedence than = in 
C as well. Therefore, I would assume that both statements above are the 
same. Assuming foo = 0, bar should equal 0 in both cases and foo = 1.

But you seem to imply that bar = (foo++) is identical to bar = ++foo? In 
that case I would find it very confusing.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3542

Thomas Mlynarczyk wrote:
> The Natural Philosopher schrieb:
>> Forget the foo=foo++ and consider the cases
>>
>> bar=foo++;
>> and
>> bar=(foo++).
>>
>> In C they give different results.
> 
> Interesting. If I remember correctly, ++ has higher precedence than = in 
> C as well. Therefore, I would assume that both statements above are the 
> same. Assuming foo = 0, bar should equal 0 in both cases and foo = 1.
> 
> But you seem to imply that bar = (foo++) is identical to bar = ++foo? In 
> that case I would find it very confusing.
> 

Odd. It doesn't do it for bar, but it does if foo=(foo++);

cat test.c
#include <stdio.h>
main()
{
int foo,bar;
foo=0;
bar=(foo++);
printf("%d\n",bar);
}
$ make test
cc     test.c   -o test
$./test
0

--------------------

$ cat test.c
#include <stdio.h>
main()
{
int foo,bar;
foo=0;
foo=(foo++);
printf("%d\n",foo);
}
$ make test
cc     test.c   -o test
$ ./test
1

Looks like its stepping off into 'indeterminate behaviour'

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web