On Wed, 21 Jun 2006, Zeev Suraski wrote:
> Well, as I said I think it actually makes the code more readable, by hinting
> you what you can ignore if you're running through the 'common case' (i.e.,
> even if this macro was a no-op). Diving into a big block of code is easier if
> you can ignore par
Oliver Block wrote:
> Hello list,
>
> as you are familiar with the source code of php it might be easy to explain
> how the brain of php interprets the following code:
I think that this would be better suited to the startard PHP list. I
would suggest posting any further followups there.
>
> p
print ($life = "hard") -1;
Store "hard" in $life,
Substract 1 from the result of that assignment ("hard")
"hard", when used in a string context is casted to int (0)
0 - 1 == -1
Output result of subtraction (casted to string): "-1"
print "\nlife: {$life}\n";
Concatenate "\nlife: " with contents
Hello list,
as you are familiar with the source code of php it might be easy to explain
how the brain of php interprets the following code:
print ($life = "hard") -1;
print "\nlife: {$life}\n";
Best regards,
Oliver
P.S. Actually, the origin of that code was the output of a string literal
con
Well, as I said I think it actually makes the code more readable, by
hinting you what you can ignore if you're running through the 'common
case' (i.e., even if this macro was a no-op). Diving into a big
block of code is easier if you can ignore parts of it to get the
general understanding of w
Comments bellow:
>-Original Message-
>
>First, let me thank you all that reviewed the patch.
>When I first sent the patch to the list I didn't meant I
>wanted it to be integrated with the main php sources. At least
>before running some benchmarks and double-checking it. That
>patch was
The source code is already hard to maintain. I think the more macros,
uncommon and compiler specific things we have in there, the harder it will
get. That's why I think that if it doesn't give much benefit it actually
hurts to have it in because maintenance keeps on getting harder.
Again, I think i
I think it's a nice idea but I doubt it's very useful at this point. It
doesn't seem to significantly affect performance, which is inline with
some
tests that we have done in the past, where it's really the hardware
management of branch prediction and cache size which affect this. I doubt
that m
I still don't see how it can hurt, and even if it doesn't do anything
performance wise, it adds clarity to the code.
Zeev
At 20:34 19/06/2006, Andi Gutmans wrote:
I think it's a nice idea but I doubt it's very useful at this point. It
doesn't seem to significantly affect performance, which is
> Instead of guessing branch probabilities, why not measure them?
Or, simply tell the compiler what you expect. Sometimes, GCC
predicts incorrectly - if-branches are usually assumed _not_
to be executed.
if (expect_true(x)) {
foo();
}
with..
#ifdef HAVE_BUILTIN_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Rasmus,
do you think you can take another look at the patch and the extension so
maybe it can be included into PHP?
thanks,
- - Markus
Rasmus Lerdorf wrote:
> Rasmus Lerdorf wrote:
>> I had another look at Joshua's upload progress patch:
>>
>> ht
11 matches
Mail list logo
