>>>$a[$i] = array();
>>>
>>>Is the above declaration legitimate?
>>
>>as long as $a is defined as an array, yes.
>>
>
>
$array = array();
>
for ($k = 0; $k < 10000; $k++)
$array[$k] = array();
>
for ($j = 0; $j < 10000; $j++)
for ($k = 0; $k < 3; $k++)
$array[$j][$k] = 0;
>
How to initialize?
>
$array[$i][1] = $array[$i][1] . $line;
PHP Notice: Undefined offset: 2700 in array.php on line 24
>
>
Well, in this case you're trying to initialize 10,000 * 10,000 arrays,
each with an integer. On a 32 bit system that's something like
400,000,000 bytes (close to 400 mb) of storage plus the overhead of the
arrays themselves. Probably a bit more than you have available - the
default is around 8M.
Why would you ever try to initialize this much memory (in either PHP or
C/C++) anyway?
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attgl obal.net
=============== ===
Well, in this case you're trying to initialize 10,000 * 10,000 arrays,
each with an integer. On a 32 bit system that's something like
400,000,000 bytes (close to 400 mb) of storage plus the overhead of the
arrays themselves. Probably a bit more than you have available - the
default is around 8M.
>
Why would you ever try to initialize this much memory (in either PHP or
C/C++) anyway?
>
Indeed, i just hope to make an array of a[10000][3] and then can be used
later. i'd be glad if you could tell me how to initialize such an array.
Thanks.
>>Well, in this case you're trying to initialize 10,000 * 10,000 arrays,
>>each with an integer. On a 32 bit system that's something like
>>400,000,000 bytes (close to 400 mb) of storage plus the overhead of the
>>arrays themselves. Probably a bit more than you have available - the
>>default is around 8M.
>>
>>Why would you ever try to initialize this much memory (in either PHP or
>>C/C++) anyway?
>>
>
>
Indeed, i just hope to make an array of a[10000][3] and then can be used
later. i'd be glad if you could tell me how to initialize such an array.
Thanks.
>
>
Hi vito, you can think of php arrays as being dynamic -- you don't have
to declare it's size ahead of time like in C or Java. I'm pretty sure
they dynamically resize themselves to fit their contents.
So you would just:
for (...) {
$newArray = array(1,2,3)
$myarray[] = $newArray;
}
But 10,000 can be very big; you should think about your problem
solution.
vito wrote:
how to achieve that? it seems php doesn't support it well for a C
programmer?
>
i hope to use something like:
>
a[$i][0];
>
a[$i][1];
>
a[$i][2];
>Indeed, i just hope to make an array of a[10000][3] and then can be used
>later. i'd be glad if you could tell me how to initialize such an array.
>Thanks.
vito,
Your code should do the trick, that is making an array of 10000 elements,
each containing an array of 3 elements, each set to integer value zero, if
that is the intention. Can't say why you get the notice. 2700 shouldn't be
an undefined offset.
Notice that Jerry keep using the word *define*. Should probably be
emphasized since you're a C-programmer. There is no explicit declaration of
a variable like you would do in C, as it is just a generic storage-place
for a value, which content can be defined or not.
Even if not defined, a legal expression of an lvalue can be assigned a
value. PHP will happily create/extend arrays or objects if needed. Used as
a rvalue (like in your case) you will get a notice of this, but it can
safely be ignored (or suppressed with @) if the use is intended.
PHP will also quite happily coerce pretty much anything into something else.
E.g. you give all $array[$j][$k] the integer value 0, but later concatenate
$array[$i][1] with something else as if a string. Sometimes such automatic
typecasting makes sense, sometimes not.
The really good thing about it, is that it lets you write rather silly
things that actually works. Really takes the r out of boring.
Just for the point:
$array= array('is what we need').'_';
$indeed=$array. = @${', Hong Kong, we got an array to'}.'fill';
$array= $indeed("of","1 0000 rows. Each an",$array('wit h',3,@${'cats'} ));
>
However, I still fail to see why you need to define 30K elements.
That's an awful lot for a PHP routine. But you know more about what
you're doing.
Well, yeah, sometimes one just find the urge to try something and see how it
goes. Perhaps that is vito's deal.
I once tried using php to traverse 3 Mill. records from a db. Nothing fancy
I thought, just one at the time, do a "little" fiddling and occasionally
throw a chunk someplace else. Needless to say perhaps, I ended up doing it
in C instead.
>>>Indeed, i just hope to make an array of a[10000][3] and then can be used
>>>later. i'd be glad if you could tell me how to initialize such an array.
>>>Thanks.
>
>
vito,
Your code should do the trick, that is making an array of 10000 elements,
each containing an array of 3 elements, each set to integer value zero, if
that is the intention. Can't say why you get the notice. 2700 shouldn't be
an undefined offset.
>
Notice that Jerry keep using the word *define*. Should probably be
emphasized since you're a C-programmer. There is no explicit declaration of
a variable like you would do in C, as it is just a generic storage-place
for a value, which content can be defined or not.
Even if not defined, a legal expression of an lvalue can be assigned a
value. PHP will happily create/extend arrays or objects if needed. Used as
a rvalue (like in your case) you will get a notice of this, but it can
safely be ignored (or suppressed with @) if the use is intended.
>
True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it. And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.
However, most C programmers aren't aware of the terms lvalue and rvalue,
either, or if they are, have only a hazy idea of what they mean.
PHP will also quite happily coerce pretty much anything into something else.
E.g. you give all $array[$j][$k] the integer value 0, but later concatenate
$array[$i][1] with something else as if a string. Sometimes such automatic
typecasting makes sense, sometimes not.
The really good thing about it, is that it lets you write rather silly
things that actually works. Really takes the r out of boring.
Just for the point:
$array= array('is what we need').'_';
$indeed=$array. = @${', Hong Kong, we got an array to'}.'fill';
$array= $indeed("of","1 0000 rows. Each an",$array('wit h',3,@${'cats'} ));
>
...which really just is:
>
$array = array_fill(0, 10000, array_fill(0, 3, null));
>
>
>>OK, here's a good place to start with arrays:
>>
>>http://us3.php.net/manual/en/language.types.array.php
>>
>>However, I still fail to see why you need to define 30K elements.
>>That's an awful lot for a PHP routine. But you know more about what
>>you're doing.
>
>
Well, yeah, sometimes one just find the urge to try something and see how it
goes. Perhaps that is vito's deal.
I once tried using php to traverse 3 Mill. records from a db. Nothing fancy
I thought, just one at the time, do a "little" fiddling and occasionally
throw a chunk someplace else. Needless to say perhaps, I ended up doing it
in C instead.
>
That's true - I've gone through some awfully large files and databases
myself. But I've never had to create an array of 30K items in PHP, either.
Now in C/C++ I have done this. But these programs are typically much
more complex than PHP programs. For instance - I haven't seen too many
500K LOC PHP programs. But I have worked on several over the years in
C/C++.
My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attgl obal.net
=============== ===
True, I'm not using it in the C sense. But I'm not using "define" in
the Cobol sense, either :-). In PHP, assigning a value to a variable
defines it.
That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:
unset($a);
$b = null;
"isset" returns false for both $a and $b, even though key of 'b' is present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.
I don't understand the point in that.
And it can't be used anyplace other then the left side of
an assignment operator (rvalue in C terms) until it is defined.
Not sure I follow. I think it would depend on what the intention and
situation. In vito's case, there shouldn't be a problem using it
($array[$i][1]) as an rvalue when undefined if just used to concatenate
strings, as it will initially just appear as an empty string. Just
suppressing the notice should work fine.
I.e.: $array[$i][1] = @$array[$i][1] . $line;
In other cases it, then sure it would be an error.
However, most C programmers aren't aware of the terms lvalue and rvalue,
either, or if they are, have only a hazy idea of what they mean.
Would they not know? I believe the compiler will use the terms if one screws
up, allthough perhaps one should be drunk to cause it.
[snip]
Now in C/C++ I have done this. But these programs are typically much
more complex than PHP programs. For instance - I haven't seen too many
500K LOC PHP programs. But I have worked on several over the years in
C/C++.
Bit of a memory-hog and pretty useless though, but it exceeds 500K.
My point being - PHP is a different language - and one should be
approaching PHP development differently than C/C++ development.
For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.
"Bent Stigsen" <ngap@thevoid.d kwrote in message
news:4596685.lT RPzWk8YV@thevoi d.dk...
Jerry Stuckle wrote:
>Bent Stigsen wrote:
[snip]
>True, I'm not using it in the C sense. But I'm not using "define" in
>the Cobol sense, either :-). In PHP, assigning a value to a variable
>defines it.
>
That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:
>
unset($a);
$b = null;
>
"isset" returns false for both $a and $b, even though key of 'b' is
present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.
>
I don't understand the point in that.
You can put a value into a variable without having to define the variable
beforehand. If you attempt to read from a variable that does not yet exist
then a ntice is generated. What's so difficult about that?
>
>And it can't be used anyplace other then the left side of
>an assignment operator (rvalue in C terms) until it is defined.
>
Not sure I follow.
If it's on the left you are putting a value in, if it's on the right you are
trying to get a value out.
I think it would depend on what the intention and
situation. In vito's case, there shouldn't be a problem using it
($array[$i][1]) as an rvalue when undefined if just used to concatenate
strings, as it will initially just appear as an empty string. Just
suppressing the notice should work fine.
I.e.: $array[$i][1] = @$array[$i][1] . $line;
>
In other cases it, then sure it would be an error.
>
>
>However, most C programmers aren't aware of the terms lvalue and rvalue,
>either, or if they are, have only a hazy idea of what they mean.
>
Would they not know? I believe the compiler will use the terms if one
screws
up, allthough perhaps one should be drunk to cause it.
>
>
[snip]
>Now in C/C++ I have done this. But these programs are typically much
>more complex than PHP programs. For instance - I haven't seen too many
>500K LOC PHP programs. But I have worked on several over the years in
>C/C++.
>
Can be generated in seconds, no biggie :)
>
awk 'BEGIN{print"<? php";for(i=0;i< ARGV[1];i++){printf"ec ho\"";
n=int(35*(1+sin (i/10)));for(j=0;j <int(n/8);j++)printf"\ t";
for(j=0;j<n%8;j ++)printf"\040" ;printf("%d\\n\ ";\n",i)}
print"?>";}' 500001 bigbadacode.php
>
Bit of a memory-hog and pretty useless though, but it exceeds 500K.
>
>
>My point being - PHP is a different language - and one should be
>approaching PHP development differently than C/C++ development.
>
For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.
This tells me that you are either using he language incorrectly, or you are
a pretty poor programmer.
This is Tony Marston's web site, containing personal information plus pages devoted to the Uniface 4GL development language, XML and XSL, PHP and MySQL, and a bit of COBOL
>>True, I'm not using it in the C sense. But I'm not using "define" in
>>the Cobol sense, either :-). In PHP, assigning a value to a variable
>>defines it.
>
>
That sortof went over my head. Never done Cobol. :)
I didn't really consider the subtler differences. Not sure I understand
PHP's way anyway. For instance:
>
unset($a);
$b = null;
>
"isset" returns false for both $a and $b, even though key of 'b' is present
in the $GLOBALS array.
Use of $a will generate a notice, but not when using $b.
>
I don't understand the point in that.
>
unset() allows the garbage collector to completely clear all references
to $a, while $b is still defined. So the former would release some
memory, while the latter just indicates the variable has no value.
Now - I agree with you that there may not be a lot of point to the
difference. Normally I don't use unset() for individual variables, but
I will use it for large arrays.
>
>
>>And it can't be used anyplace other then the left side of
>>an assignment operator (rvalue in C terms) until it is defined.
>
>
Not sure I follow. I think it would depend on what the intention and
situation. In vito's case, there shouldn't be a problem using it
($array[$i][1]) as an rvalue when undefined if just used to concatenate
strings, as it will initially just appear as an empty string. Just
suppressing the notice should work fine.
I.e.: $array[$i][1] = @$array[$i][1] . $line;
>
In other cases it, then sure it would be an error.
>
By default an undefined variable can never be an rvalue. It will not
appear as an empty string - it will generate an error.
Using the @ just hides the error message. It doesn't stop the error
from occurring, and is, IMHO, VERY BAD practice.
Now - if the variable were defined as it should have been, there would
be no error.
>
>
>>However, most C programmers aren't aware of the terms lvalue and rvalue,
>>either, or if they are, have only a hazy idea of what they mean.
>
>
Would they not know? I believe the compiler will use the terms if one screws
up, allthough perhaps one should be drunk to cause it.
>
Depending on the error they get, yes. Very few errors mention lvalue or
rvalue, and those are not common errors. And even if the error message
indicates "lvalue" or "rvalue", the programmers don't necessarily know
what the terms mean.
>
[snip]
>
>>Now in C/C++ I have done this. But these programs are typically much
>>more complex than PHP programs. For instance - I haven't seen too many
>>500K LOC PHP programs. But I have worked on several over the years in
>>C/C++.
>
>
Can be generated in seconds, no biggie :)
>
I'm not talking about programs generated by an inefficient code
generator. I'm talking about 500K+ LOC projects generated by hand by
dozens of experienced programmers over a period of a year or more.
Code that actually works and does something useful.
awk 'BEGIN{print"<? php";for(i=0;i< ARGV[1];i++){printf"ec ho\"";
n=int(35*(1+sin (i/10)));for(j=0;j <int(n/8);j++)printf"\ t";
for(j=0;j<n%8;j ++)printf"\040" ;printf("%d\\n\ ";\n",i)}
print"?>";}' 500001 bigbadacode.php
>
Bit of a memory-hog and pretty useless though, but it exceeds 500K.
>
>
>
>>My point being - PHP is a different language - and one should be
>>approaching PHP development differently than C/C++ development.
>
>
For sure. My oppinion of PHP varies a lot. One day I would consider it a
rotting stinking goat carcass which only dogs would take a roll in
(figuratively speaking, no offense to dogs), find myself rolling in it the
very next day, and cant stand the smell on the third day.
>
I think it's a decent language for what it's designed. Not great, not
bad. But highly useful and improving.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attgl obal.net
=============== ===
"Bent Stigsen" <ngap@thevoid.d kwrote in message
news:4596685.lT RPzWk8YV@thevoi d.dk...
>Jerry Stuckle wrote:
>>Bent Stigsen wrote:
>[snip]
>>True, I'm not using it in the C sense. But I'm not using "define" in
>>the Cobol sense, either :-). In PHP, assigning a value to a variable
>>defines it.
>That sortof went over my head. Never done Cobol. :)
>I didn't really consider the subtler differences. Not sure I understand
>PHP's way anyway. For instance:
>>
>unset($a);
>$b = null;
>>
>"isset" returns false for both $a and $b, even though key of 'b' is
>present
>in the $GLOBALS array.
>Use of $a will generate a notice, but not when using $b.
>>
>I don't understand the point in that.
>
You can put a value into a variable without having to define the variable
beforehand. If you attempt to read from a variable that does not yet exist
then a ntice is generated. What's so difficult about that?
It's quite clearly stated in the manual, no problem there. I just
don't understand the choice of behavior.
It is the concept of "isset", which I like to take literally.
When I set the variable to null, causing the variable to appear in
$GLOBALS, why should "isset" return false?
I understand the behavior, not the choice.
>>And it can't be used anyplace other then the left side of
>>an assignment operator (rvalue in C terms) until it is defined.
>Not sure I follow.
>
If it's on the left you are putting a value in, if it's on the right you are
trying to get a value out.
I gathered that was a typo. Pretty hard to mix up left and right of
Lvalues and Rvalues.
[snip]
>>My point being - PHP is a different language - and one should be
>>approaching PHP development differently than C/C++ development.
>For sure. My oppinion of PHP varies a lot. One day I would consider it a
>rotting stinking goat carcass which only dogs would take a roll in
>(figurativel y speaking, no offense to dogs), find myself rolling in it the
>very next day, and cant stand the smell on the third day.
>
This tells me that you are either using he language incorrectly, or you are
a pretty poor programmer.
Silly, how would you know how pretty or poor I am?
I don't know if I is incorrect use that flavours my opinion. Hardly a
way to solve the lack of speed. It just isn't for number crunching.
Scope-rules usually annoys me. Behavior of isset bugs me.
This bugs me:
$a = array(1,2,3);
foreach($a as &$val) $val = $val * 2;
foreach($a as $key=>$val) echo "$key = $val\n";
Returns:
0 = 2
1 = 4
2 = 4
Behavior by design, no problem, but I hate when I have to read the
fine print in the manual, if I on top of that find it illogical, then
it is a stinking pile of cow dung.
Comment