FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » simple session question
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: simple session question [message #175737 is a reply to message #175731] Sat, 22 October 2011 23:29 Go to previous messageGo to previous message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma:
Member
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.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: session cookie: client side
Next Topic: by get this format my explode file name like this through php
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Nov 28 12:47:09 GMT 2024

Total time taken to generate the page: 0.04833 seconds