On Wed, 2009-10-07 at 13:24 -0700, Tommy Pham wrote:
>
>
>
> From: tedd
> To: php-general@lists.php.net; a...@ashleysheridan.co.uk; Daevid Vincent
>
> Sent: Wed, October 7, 2009 12:42:41 PM
> Subject: RE: [PHP] Whacky increment/assignm
From: tedd
To: php-general@lists.php.net; a...@ashleysheridan.co.uk; Daevid Vincent
Sent: Wed, October 7, 2009 12:42:41 PM
Subject: RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
At 1:59 PM +0100 10/7/09, Ashley Sheridan wrote:
>>
On Wed, Oct 7, 2009 at 3:58 PM, Andrew Ballard wrote:
> On Wed, Oct 7, 2009 at 3:42 PM, tedd wrote:
>
>> However, what I find wacky about all of this is:
>>
>> for($i=1; $i<=10; $i++)
>>{
>>echo($i);
>>}
>>
>> and
>>
>> for($i=1; $i<=10; ++$i)
>>{
>>echo($i);
>>}
>>
>>
On Wed, Oct 7, 2009 at 3:42 PM, tedd wrote:
> However, what I find wacky about all of this is:
>
> for($i=1; $i<=10; $i++)
>{
>echo($i);
>}
>
> and
>
> for($i=1; $i<=10; ++$i)
>{
>echo($i);
>}
>
> Do exactly the same thing. I would have expected the first to print 1-10,
At 1:59 PM +0100 10/7/09, Ashley Sheridan wrote:
On Wed, 2009-10-07 at 08:54 -0400, tedd wrote:
At 6:15 PM -0700 10/6/09, Daevid Vincent wrote:
Except that:
$a = 123;
$b = $a++;
echo $b; //gives 123, not 124
as you logically expect it to and common sense would dictate, regardless of
what K&R
> Easy there hoss, no need to get worked up.
In my opinion, being blamed for natural optimizations is the most ridiculous,
hilarious, anti professional behavior I have ever seen ... but you are right,
no need to get worked up, so have fun here.
Regards
[snip]
...flame...
[/snip]
Easy there hoss, no need to get worked up.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> This is a great talk / slideshow and definitely is a better way to
> drive home the point that PHP execution speed is relatively
> meaningless in terms of user experience. Well, at least up to a
> point...
if it takes 0.1 per response, with 10 users will be 1 second to wait ... if it
takes
On Wed, Oct 7, 2009 at 11:36 AM, Tom Worster wrote:
> just yesterday i was reading through this wonderful and very funny
> presentation:
>
> http://talks.php.net/show/froscon08/0
>
> for me it really drove home the message (among others) that it makes sense
> to find out where the real gains ca
is bad, which is not
gonna happen since optimizations for you are a waste of time, I'll code like
that.
Have fun, I have wasted already too much time to taqlk about this silly stuff
...
Best Regards
> Date: Wed, 7 Oct 2009 11:36:27 -0400
> Subject: Re: [PHP] Whacky increme
just yesterday i was reading through this wonderful and very funny
presentation:
http://talks.php.net/show/froscon08/0
for me it really drove home the message (among others) that it makes sense
to find out where the real gains can be made before investing your efforts
in optimization.
--
>
> I can write a test[1] that comes out with these results:
> String concat time: 0.18807196617126
> String interpolation time: 0.14288902282715
> Where using " is faster than ' ! Common wisdom be damned!
where is the test? ... and, is that kind of test where you put 12345678
variables ins
On Tue, Oct 6, 2009 at 6:59 PM, Andrea Giammarchi wrote:
>
>
>> So while we can debate computing considerations of today, tomorrow
>> those will be less important. That was the point I was making. Why
>> not focus on things that make significant difference and let the
>> insignificant fade into hi
Speaking of.
[snip]
-Original Message-
From: Daevid Vincent [mailto:dae...@daevid.com]
Sent: Tuesday, October 06, 2009 8:21 PM
To: Jay Blanchard; 'Tommy Pham'; php-general@lists.php.net
Subject: RE: [PHP] Whacky increment/assignment logic with $foo++ vs
++$foo
HEY! Do
On Wed, 2009-10-07 at 08:54 -0400, tedd wrote:
> At 6:15 PM -0700 10/6/09, Daevid Vincent wrote:
> >Except that:
> >
> >$a = 123;
> >$b = $a++;
> >echo $b; //gives 123, not 124
> >
> >as you logically expect it to and common sense would dictate, regardless of
> >what K&R or anyone else says.
>
>
At 6:15 PM -0700 10/6/09, Daevid Vincent wrote:
Except that:
$a = 123;
$b = $a++;
echo $b; //gives 123, not 124
as you logically expect it to and common sense would dictate, regardless of
what K&R or anyone else says.
That's not the way I look at it.
$b = $a++;
means to me "take the val
On Tue, 6 Oct 2009 12:15:54 -0400, tedd.sperl...@gmail.com (tedd) wrote:
>At 3:56 PM +0200 10/6/09, Andrea Giammarchi wrote:
>> > Does these behaves exactly?
>>> for($i=0; $i<10; ++$i)
>>> for($i=0; $i<10; $i++)
>>
>>different benchmarks showed ++$i is usually faster than $i++
>
>"Faster" is a
> So while we can debate computing considerations of today, tomorrow
> those will be less important. That was the point I was making. Why
> not focus on things that make significant difference and let the
> insignificant fade into history.
I tendentiously focus on all things able to make, all
Andrea Giammarchi wrote:
if used properly, could avoid recursion, and speed up operations ... there is
nothing wrong with goto, everything we write on lowest level is a jump in the
memory (as goto is a jump in the code flow)
++goto ... and not goto++
I forgot, I have always used goto in B
HP] Whacky increment/assignment logic with
> $foo++ vs ++$foo
>
> [snip]
> I find it interesting for a discussion to go on this long for
> something
> as
> $a = $a++;
> [/snip]
>
> You think that is interesting? Start a conversation about these
>
> {}
>
> -Original Message-
> From: Paul M Foster [mailto:pa...@quillandmouse.com]
> Sent: Tuesday, October 06, 2009 6:28 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] Whacky increment/assignment logic with
> $foo++ vs ++$foo
>
> On Tue, Oct 06, 2009
At 10:20 AM +1100 10/7/09, clanc...@cybec.com.au wrote:
On Tue, 6 Oct 2009 14:08:14 -0400, tedd.sperl...@gmail.com (tedd) wrote:
At 10:48 AM -0300 10/6/09, Martin Scotta wrote:
No matter how silly it can looks like (a = a++) it is still completely valid
code and it SHOULD run without problems.
At 1:09 AM +0200 10/7/09, Andrea Giammarchi wrote:
> Eddie:
And thanks for supporting my point.
so you think as well that 3 characters, written like this i++, in a
careless way, or like this ++i, make the difference about time spent
to develop ... interesting
No, just the opposite. It d
On Tue, 6 Oct 2009 14:08:14 -0400, tedd.sperl...@gmail.com (tedd) wrote:
>At 10:48 AM -0300 10/6/09, Martin Scotta wrote:
>>No matter how silly it can looks like (a = a++) it is still completely valid
>>code and it SHOULD run without problems.
>
>Yeah, it's a valid as:
>
>$a = $a;
>
>and does
> if used properly, could avoid recursion, and speed up operations ... there is
> nothing wrong with goto, everything we write on lowest level is a jump in the
> memory (as goto is a jump in the code flow)
>
> ++goto ... and not goto++
I forgot, I have always used goto in Batch script, which
> Speaking of starting a conversation, what do you think about the "goto"
> construct introduced just recently?
if used properly, could avoid recursion, and speed up operations ... there is
nothing wrong with goto, everything we write on lowest level is a jump in the
memory (as goto is a jump
> Eddie:
>
> And thanks for supporting my point.
so you think as well that 3 characters, written like this i++, in a careless
way, or like this ++i, make the difference about time spent to develop ...
interesting
Regards
ah ah ah that's for sure, I've never said that is correct, I said that is
illogical ;-)
> Subject: RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
> Date: Tue, 6 Oct 2009 12:46:36 -0500
> From: jblanch...@pocket.com
> To: an_...@hotmail.com; tedd.s
> Furthermore, the amount
> of time micro-optimization takes up (going through old code, I mean)
> could be better spent doing something that actually does increase your
> performance, like implementing a search engine or memcached. Going
> forward, if you're aware that ++i and i++ are the same
On Tue, Oct 6, 2009 at 14:46, Israel Ekpo wrote:
>
> Speaking of starting a conversation, what do you think about the "goto"
> construct introduced just recently?
Better yet: what do you all think of folks hijacking threads?
--
daniel.br...@parasane.net || danbr...@php.net
http://www.paras
On Tue, Oct 6, 2009 at 2:34 PM, Jay Blanchard wrote:
> [snip]
> I find it interesting for a discussion to go on this long for something
> as
> $a = $a++;
> [/snip]
>
> You think that is interesting? Start a conversation about these
>
> {}
>
> --
> PHP General Mailing List (http://www.php.net/)
>
On Tue, 2009-10-06 at 13:34 -0500, Jay Blanchard wrote:
> [snip]
> I find it interesting for a discussion to go on this long for something
> as
> $a = $a++;
> [/snip]
>
> You think that is interesting? Start a conversation about these
>
> {}
>
Now they actually make sense! I've used those as
[snip]
I find it interesting for a discussion to go on this long for something
as
$a = $a++;
[/snip]
You think that is interesting? Start a conversation about these
{}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
At 11:11 AM -0700 10/6/09, Tommy Pham wrote:
I find it interesting for a discussion to go on this long for something as
$a = $a++;
which should have never happened in the first place ;)
Regards,
Tommy
Hey, we're programmers. We waste time for a living.
Cheers,
tedd
--
---
http://sperli
- Original Message
> From: tedd
> To: Martin Scotta ; Paul M Foster
>
> Cc: php-general@lists.php.net
> Sent: Tue, October 6, 2009 11:08:14 AM
> Subject: Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
>
> At 10:48 AM -0300 10/6/09, Martin Sco
At 10:48 AM -0300 10/6/09, Martin Scotta wrote:
No matter how silly it can looks like (a = a++) it is still completely valid
code and it SHOULD run without problems.
Yeah, it's a valid as:
$a = $a;
and does the same thing, which is nothing.
If you want a statement that does something, the
At 12:46 PM -0500 10/6/09, Jay Blanchard wrote:
[snip]
...micro optimizations...
[/snip]
And in the land of micro optimization you would likely never see the
following;
$a = $a++;
I must live in the land of micro optimization.
Cheers,
tedd
--
---
http://sperling.com http://ancientstone
The problem with PHP micro-optimizations like that or ' vs. " is that
PHP rarely bottlenecks a PHP/MySQL application (actually if you run a
dedicated box, see how often your CPU hits 100%, it won't be very
often for the vast majority of PHP/MySQL sites which are more likely
to be disk i/o bound t
[snip]
...micro optimizations...
[/snip]
And in the land of micro optimization you would likely never see the
following;
$a = $a++;
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
At 6:25 PM +0200 10/6/09, Andrea Giammarchi wrote:
er ... tedd, whatever, usually ++i is faster in almost every
language, and even C developers could use these kind of micro
optimizations.
Speed, even in this SuperCPU era, is still relevant, we would not
need benchmark to compare programming
> never had speed problems, but maybe I am just lucky.
>
> Regards
>
>> Date: Tue, 6 Oct 2009 12:15:54 -0400
>> To: php-general@lists.php.net
>> From: tedd.sperl...@gmail.com
>> Subject: RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
>>
>> At 3:
.net
> From: tedd.sperl...@gmail.com
> Subject: RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
>
> At 3:56 PM +0200 10/6/09, Andrea Giammarchi wrote:
> > > Does these behaves exactly?
> >> for($i=0; $i<10; ++$i)
> >> for($i=0; $i<10; $i++)
&
At 3:56 PM +0200 10/6/09, Andrea Giammarchi wrote:
> Does these behaves exactly?
for($i=0; $i<10; ++$i)
for($i=0; $i<10; $i++)
different benchmarks showed ++$i is usually faster than $i++
"Faster" is a relative term that is becoming more meaningless each year.
Considering that "speed" is
> Does these behaves exactly?
> for($i=0; $i<10; ++$i)
> for($i=0; $i<10; $i++)
different benchmarks showed ++$i is usually faster than $i++
In that loop case, yes, what's happen internally is exactly the same, $i will
be from 0 to 9, in the other case obviously is not the same.
but pre increm
On Tue, Oct 6, 2009 at 10:28 AM, Paul M Foster wrote:
> On Tue, Oct 06, 2009 at 08:51:17AM -0400, Bob McConnell wrote:
>
> > From: Joost [mailto:joost.t.h...@planet.nl]
> > > "Daevid Vincent" wrote:
> > >>> From: Ben Dunlap [mailto:bdun...@agentintellect.com]
> >
> > > $a = $a++;
> >
> > I jus
On Tue, Oct 06, 2009 at 08:51:17AM -0400, Bob McConnell wrote:
> From: Joost [mailto:joost.t.h...@planet.nl]
> > "Daevid Vincent" wrote:
> >>> From: Ben Dunlap [mailto:bdun...@agentintellect.com]
>
> > $a = $a++;
>
> I just think this is an ambiguous line of code that wasn't thought
> throu
> It will be an accident
> if you get the results you are expecting.
I agree that the operation is illogical, I must disagree about accidents.
In PHP that operation will mean assign to the new $a variable the value
returned from the other $a variable before the increment.
There is no mystery
From: Joost [mailto:joost.t.h...@planet.nl]
> "Daevid Vincent" wrote:
>>> From: Ben Dunlap [mailto:bdun...@agentintellect.com]
> $a = $a++;
I just think this is an ambiguous line of code that wasn't thought
through. The presence of the postfix operator makes the result
undefined, no matter
Ben Dunlap wrote:
... and, in fact, that /is/ how C behaves. The following code:
No, that's implementation's behaviour. AFAIK, the normative document
give to compiler the behaviour implementation. So, it can do
optimization, that gives strange behaviour for a people how think
increment ope
> ... and, in fact, that /is/ how C behaves. The following code:
>
> int a = 2;
> a = a++;
> printf("a = [%d]\n", a);
>
> Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
>
> So I retract my initial terse reply and apologize for misunderstanding
> your question.
>
> Ben
It's not t
On Sat, Oct 3, 2009 at 10:49, tedd wrote:
>
> That's absolutely true.
>
> The problem here is in the statement of:
>
> $num = $num++;
Yeah, I understood Daevid's email a bit better *after* I sent
mine. Then I was hoping no one noticed.
--
daniel.br...@parasane.net || danbr...@php.net
http
At 5:42 PM -0400 10/2/09, Daniel Brown wrote:
>
If you were to use $num++, it would echo out the current number,
THEN increment the value. In this example, it increments the value,
THEN echoes it out. The placement of the signs (plus or minus) is the
giveaway: if it's before the variable,
At 2:53 PM -0700 10/2/09, Ben Dunlap wrote:
$a = 2;
$a = $a++;
echo $a;
Honestly I think the only reason anyone would write an expression like
that is either to fake out the compiler or because they don't properly
understand the use of a unary operator. Or rather, of the
increment/dec
At 2:28 PM -0700 10/2/09, Daevid Vincent wrote:
My problem isn't with $foo++ vs ++$foo per say. I use pre/post all the time.
My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN
INCREMENT.
I see your point exactly.
The problem is with the statement of:
$num = $num++;
That st
At 5:12 PM -0400 10/2/09, Robert Cummings wrote:
Daevid Vincent wrote:
So then I read the manual because I think I'm loosing my mind and perhaps
it's backwards day and nobody told me:
http://us3.php.net/manual/en/language.operators.increment.php
I'm baffled as to the reasoning behind:
"$a++
At 2:01 PM -0700 10/2/09, Daevid Vincent wrote:
Why would you EVER want $num = $num++; to give you back the value you
already had? Even if we did $foo = $bar++; I would still logically (and
common sensely) expect $foo to be the increment of $bar!
You are right -- one should never structure a st
Ben,
might be intersting to consider that in ur c axample u r working with a pure
memory position, while php works with references. thry it with pointers it
I'm pretty shure u get the same result as in PHP.
I'm not shure, because I don't work in perl, but doesn't per work on
references as well ?
"Daevid Vincent" wrote:
>
>
>> -Original Message-
>> From: Ben Dunlap [mailto:bdun...@agentintellect.com]
>> Sent: Friday, October 02, 2009 2:58 PM
>> To: php-general@lists.php.net; Daevid Vincent
>> Subject: Re: [PHP] Whacky incre
> int a = 2;
> b = a++;
> printf("b = [%d]\n", b);
>
> "b" would be 2 when printed. However, after the second line (b = a++;)
> finished executing, "a" would then be 3.
Sure, but that code is perfectly clear. It's the odd special case
where you assign the variable to itself,
On Oct 2, 2009, at 15:22, Daevid Vincent wrote:
-Original Message-
From: Ben Dunlap [mailto:bdun...@agentintellect.com]
Sent: Friday, October 02, 2009 2:58 PM
To: php-general@lists.php.net; Daevid Vincent
Subject: Re: [PHP] Whacky increment/assignment logic with
$foo++ vs ++$foo
> -Original Message-
> From: Ben Dunlap [mailto:bdun...@agentintellect.com]
> Sent: Friday, October 02, 2009 2:58 PM
> To: php-general@lists.php.net; Daevid Vincent
> Subject: Re: [PHP] Whacky increment/assignment logic with
> $foo++ vs ++$foo
>
> > mind
>> Seems like any way you slice it the output should be 3. I guess what's
>
> ... and, in fact, that /is/ how C behaves. The following code:
Whereas Perl (v5.10.0) handles the construct the same way that PHP
does. Curiouser and curiouser.
Ben
--
PHP General Mailing List (http://www.php.net/)
To
> mind-blowing. What the heck /is/ supposed to happen when you do this:
>
> $a = 2;
> $a = $a++;
> echo $a;
>
> Seems like any way you slice it the output should be 3. I guess what's
... and, in fact, that /is/ how C behaves. The following code:
int a = 2;
a = a++;
On Fri, Oct 2, 2009 at 2:37 PM, Ben Dunlap wrote:
>> My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN
>> INCREMENT.
>>
>> That's just counter intuitive. In the case of $foo = $num++, everything to
>> the right of the = should be computed FIRST and THEN handed off to the left
>>
On Fri, Oct 2, 2009 at 17:42, Daniel Brown wrote:
>
> but rather by something just slightly more advanced:
>
> $num = file_get_contents('visitcount.txt');
> if(isset($_GET['countme'])) {
> echo "You are visitor #".++$num."\n";
> file_put_contents($num);
> }
> ?>
Converse exampl
On Fri, Oct 2, 2009 at 17:28, Daevid Vincent wrote:
>
> Personally I've never (in almost 20 years) done an assignment like "$foo =
> $foo++" as I always use just "$foo++" or "$foo += 1" or something, hence the
> reason today is the day a co-worker stumbled upon this and was as confused
> as I was
> My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN
> INCREMENT.
>
> That's just counter intuitive. In the case of $foo = $num++, everything to
> the right of the = should be computed FIRST and THEN handed off to the left
> side. This particular expression (and I'm unaware of any
> -Original Message-
> From: Robert Cummings [mailto:rob...@interjinn.com]
> Sent: Friday, October 02, 2009 2:12 PM
> To: Daevid Vincent
> Cc: php-general@lists.php.net
> Subject: Re: [PHP] Whacky increment/assignment logic with
> $foo++ vs ++$foo
>
- Original Message
> From: Ben Dunlap
> To: Daevid Vincent
> Cc: php-general@lists.php.net
> Sent: Fri, October 2, 2009 2:06:47 PM
> Subject: Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
>
> > Can someone PLEASE explain why the deve
Daevid Vincent wrote:
So then I read the manual because I think I'm loosing my mind and perhaps
it's backwards day and nobody told me:
http://us3.php.net/manual/en/language.operators.increment.php
I'm baffled as to the reasoning behind:
"$a++ :: Post-increment :: Returns $a, then increments $
> Can someone PLEASE explain why the developers of PHP chose this seemingly
> whacky logic?
It mimicks C.
Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
So then I read the manual because I think I'm loosing my mind and perhaps
it's backwards day and nobody told me:
http://us3.php.net/manual/en/language.operators.increment.php
I'm baffled as to the reasoning behind:
"$a++ :: Post-increment :: Returns $a, then increments $a by one."
Why would yo
72 matches
Mail list logo