User Contributed Notes 49 notes

Another example of something to watch out for when using references with arrays. It seems that even an usused reference to an array cell modifies the *source* of the reference. Strange behavior for an assignment statement (is this why I've seen it written as an =& operator? - although this doesn't happen with regular variables).<?php $array1 = array(1,2);$x = &$array1[1]; // Unused reference$array2 = $array1; // reference now also applies to $array2 !$array2[1]=22; // (changing [0] will not affect $array1)print_r($array1);?>Produces: Array ( [0] => 1 [1] => 22 // var_dump() will show the & here )

I fixed my bug by rewriting the code without references, but it can also be fixed with the unset() function:<?php $array1 = array(1,2);$x = &$array1[1];$array2 = $array1; unset($x); // Array copy is now unaffected by above reference$array2[1]=22;print_r($array1);?>Produces: Array ( [0] => 1 [1] => 2 )

It should explain some of the odd behavior PHP sometimes seems to exhibit, as well as why you can't create "references to references" (unlike in C++), and why you should never attempt to use references to speed up passing of large strings or arrays (it will make no difference, or it will slow things down).

It was written for PHP 4 but it still applies. The only difference is in how PHP 5 handles objects: passing object variables by value only copies an internal pointer to the object. Objects in PHP 5 are only ever duplicated if you explicitly use the clone keyword.

$a = null; replaces the value at the destination of $a with the null value;

If you chose to use a convention like $NULL = NULL;

THEN, you could say $a =& $NULL to break any previous reference assignment to $a (setting it of course to $NULL), which could still get you into trouble if you forgot and then said $a = '5'. Now $NULL would be '5'.

"Note: Not using the & operator causes a copy of the object to be made. If you use $this in the class it will operate on the current instance of the class. The assignment without & will copy the instance (i.e. the object) and $this will operate on the copy, which is not always what is desired. Usually you want to have a single instance to work with, due to performance and memory consumption issues."

Another example of something to watch out for when using references with arrays. It seems that even an usused reference to an array cell modifies the *source* of the reference. Strange behavior for an assignment statement (is this why I've seen it written as an =& operator? - although this doesn't happen with regular variables).<?php $array1 = array(1,2);$x = &$array1[1]; // Unused reference$array2 = $array1; // reference now also applies to $array2 !$array2[1]=22; // (changing [0] will not affect $array1)print_r($array1);?>Produces: Array ( [0] => 1 [1] => 22 // var_dump() will show the & here )

//above was Noted By Dave at SymmetricDesign dot com////and below is my opinion to this simple problem. //

This is an normal referencing problem.

when you gain an reference to a memory at some variable.this variable, means "memory itself". (in above example, this would be -> $x = &$array1[1]; // Unused reference)

and you've copied original one($array1) to another one($array2).and the copy means "paste everything on itself". including references or pointers, etcs. so, when you copied $array1 to $array2, this $array2 has same referencers that original $array1 has. meaning that $x = &$array1[1] = &$array2[1];and again i said above. this reference means "memory itself".when you choose to inserting some values to $array2[1], $x; reference is affected by $array2[1]'s value. because, in allocated memory, $array2[1] is a copy of $array1[1]. this means that $array2[1] = $array1[1], also means &$array2[1] = &$array1[1] as said above. this causes memory's value reallocation on $array1[1]. at this moment. the problem of this topic is cleared by '$x', the memory itself. and this problem was solved by unsetting the '$x'. unsetting this reference triggers memory reallocation of $array2[1]. this closes the reference link between the copied one($array1, which is the original) and copy($array2). this is where that bug(clearly, it's not a bug. it's just a missunderstanding) has triggered by. closing reference link makes two array object to be separated on memory. and this work was done through the unset() function. this topic was posted 7 years ago, but i just want to clarify that it's not a bug.

It is important to note the difference between what php is doing from the programmer's point of view and what it is doing internally. The note that nathan refers to, about how (for example) $something = $this makes a "copy" of the current object, is talking about making a "copy" from the programmer's perspective. That is, for the programmer, for all practical purposes, $something is a copy, even if internally nothing has been copied yet. For example, changing the data in member $something->somethingVar will not change your current object's data (i.e. it will not change $this->somethingVar).

What it does internally is a totally different story. I've tested "copying" an object which contains a 200,000 element array, it takes almost no time at all until you finally change something in one of the copies, because internally it only makes the copy when it becomes necessary. The original assignment takes less than a millisecond, but when I alter one of the copies, it takes something like a quarter of a second. But this only happens if I alter the 200,000 element array, if I alter a single integer of the object, it takes less than a microsecond again, so the interpretter seems to be smart enough to make copies of some of the objects variables and not others.

The result is that when you change a function to pass by reference, it will only become more efficient if, inside the function, the passed variable is having its data altered, in which case passing by reference causes your code to alter the data of the original copy. If you are passing an object and calling a function in that object, that function may alter the object without you even knowing, which means that you should pass an object by reference as long as it is ok for the original copy to be effected by what you do with the object inside the function.

I think the real moral of the story is this:1) Pass by reference anything that should refer to and affect the original copy.2) Pass not by reference things that will definitely not be altered in the function (for an object, it may be impossible to know whether it alters itself upon calling one of its functions).3) If something needs to be altered inside a function without effecting the original copy, pass it not by reference, and pass the smallest practical part that needs to change, rather than passing, for example, a huge array of which one little integer will be altered.

Or a shorter version: Only pass things by reference when you need to refer to the original copy! (And don't pass huge arrays or long strings when you need to change just a small part of them!)

After some searching, I found that it was a known bug which would be too costly to fix (see http://bugs.php.net/bug.php?id=20993). There was supposed to be some documentation on this behaviour on this page:

"Due to peculiarities of the internal workings of PHP, if a reference is made to a single element of an array and then the array is copied, whether by assignment or when passed by value in a function call, the reference is copied as part of the array. This means that changes to any such elements in either array will be duplicated in the other array (and in the other references), even if the arrays have different scopes (e.g. one is an argument inside a function and the other is global)! Elements that did not have references at the time of the copy, as well as references assigned to those other elements after the copy of the array, will behave normally (i.e. independent of the other array)."

However, this paragraph appears to have been removed from this page at some point, presumably because it was a bit obscure. The comments section seem to be a proper place for this, though.

I must say that it has been rather confusing following all of the explanations of PHP references, especially since I've worked a lot with C pointers. As far as I can tell PHP references are the same as C pointers for all practical purposes. I think a lot of the confusion comes from examples like the one shown below where people expect that a C pointer version of this would change what $bar references.

<?phpfunction foo(&$var){$var =& $GLOBALS["baz"];}foo($bar); ?>

This is not the case. In fact, a C pointer version of this example (shown below) would behave exactly the same way (it would not modify what bar references) as the PHP reference version.

int baz = 5;int* bar;void foo(int* var){ var = &baz;}foo(bar);

In this case, just as in the case of PHP references, the call foo(bar) doesn't change what bar references. If you wanted to change what bar references, then you would need to work with a double pointer like so:

debug_zval_dump() is a confusing function, as explained in its documentation, as among other things, it adds a reference count when being called as there is a reference within the function. refcount() takes account of these extra references by subtracting them for the return value.

It's also even more confusing when dealing with variables that have been assigned by reference (=&), either on the right or left side of the assignment, so for that reason, the above function doesn't really work for those sorts of variables. I'd use it more on object instances.

However, even taking into account that passing a variable to a function adds one to the reference count; which should mean that calling refcount() adds one, and then calling debug_zval_dump() adds another, refcount() seems to have aquired another reference from somewhere; hence subtracting 3 instead of 2 in the return line. Not quite sure where that comes from.

I've only tested this on 5.3; due to the nature of debug_zval_dump(), the results may be completely different on other versions.

In addition to the note made by "Francis dot a at gmx dot net" you should not normally be using a function such as sizeof() or count() in a control structure such as FOR because the same value is being calculated repeatedly for each iteration. This can slow things down immensely, regardless of whether you pass by value or reference.

It is generally much better to calculate the static values before the defining the looping control structure.

I don't know if this is a bug (I'm using PHP 5.01) but you should be careful when using references on arrays.I had a for-loop that was incredibly slow and it took me some time to find out that most of the time was wasted with the function sizeof() at every loop, and even more time I spent finding out that this problem it must be somehow related to the fact, that I used a reference of the array. Take a look at the following example:

You can make references like pointers. Example:<?php $a=6;$b=array(&$a); // $b is a pointer to $a$c=array(&$b); // $c is a pointer to $b$d=7;$c[0][0]=9; // $a is 9$c[0]=array(&$d); // $b is a pointer to $d$c[0][0]=4; // $d is 4$b=array(&$a); // $b is a pointer to $a againecho $a.$b[0].$c[0][0].$d; // outputs 9994?>These kind of pointers may even be passed to functions or returned from functions, copied and stored in multiple arrays/variables/objects, etc.

(v5.1.4)One cool thing about var_dump is it shows which variables are references (when dumping arrays), symbolized by '∫' for int/null, and by '&' for boolean/double/string/array/object. I don't know why the difference in symmmmbolism.After playing around I found a better way to implement detaching (twas by accident). var_dump can show what's going on.

$A['x'] = $A['x'];$A['y']=&detach();var_dump($A,$z);/* x returned to normal, y is on its own, z is still "hi"array(2) { ["x"]=> int(123) ["y"]=> NULL}*/?>

For detach to work you need to use '&' in the function declaration, and every time you call it.

Use this when you know a variable is a reference, and you want to assign a new value without effecting other vars referencing that piece of memory. You can initialize it with a new constant value, or variable, or new reference all in once step.

You should have in mind that php4 keep assigned variables "automagically" referenced until they are overwritten. So the variable copy is not executed on assignment, but on modification. Say you have this:

$var1 = 5;$var2 = $var1; // In this point these two variables share the same memory location$var1 = 3; // Here $var1 and $var2 have they own memory locations with values 3 and 5 respectively

Don't use references in function parameters to speed up aplications, because this is automatically done. I think that this should be in the manual, because it can lead to confusion.

Responding to Slava Kudinov. The only reason why your script takes longer when you pass by reference is that you do not at all modify the array that your passing to your functions. If you do that the diffrences in execution time will be a lot smaller. In fact passing by reference will be faster if just by a little bit.

There is no built in method (yet) to check if two variables are references to the same piece of data, but you can do a "reference sniff" test. This is rarely needed, but can be very useful. The function bellow is a slightly modified version of this technique I saw in a forum regarding this comparison limitation.

I found a subtle feature of references that caused a bug in one of my PHP applications. In short, if an object passes one of its members to an external function that takes a reference as an argument, the external function can turn that member into a reference to an anonymous point in memory.

Why is this a problem? Later, when you copy the object with $a = $b, the copy and the original share memory.

Solution: If you want to have a function that uses references to modify a member of your object, your object should never pass the member to the function directly. It should first make a copy of the member. Then give that copy to the function. Then copy the new value of that copy in to your original object member.

Below is some code that can reporoduce the this feature and demonstrate the workaround.

Assuming we post 10MB of data to this PHP file, what will PHP do with the memory?

PHP uses a table of sorts that maps variable names to the data that variable refers to in memory. The $_POST superglobal will actually be the first instance of that data in the execution, so it will be the first variable referenced to that data in the memory. It will consume 10MB. Each $data var will simply point to the same data in memory. Until you change that data PHP will NOT duplicate it.

Passing a variable by value does just what I did with each $data var. There is no significant overhead to assigning a new name to the same data. It is only when you modify the data passed to the function that it must allocate memory for the data. Passing a variable by reference will do essentially the same thing when you pass the data to the function, only modifying it will modify the data that is in the memory already versus copying it to a new location in memory.

If for learning purposes you choose to disregard the obvious pointlessness in benchmarking the difference between these two methods of passing arguments, you will need to modify the data when it is passed to the function in order to obtain more accurate results.

After some headaches, here is a function to check if, between 2 variables $a,$b check if one is a reference to the other.It means they "point" to the same value.Tested on :PHP 7.2.2 (cli) (built: Jan 31 2018 19:31:17) ( ZTS MSVC15 (Visual C++ 2017) x64 )Hope that helps...<?php

// create the B object and pass the A_obj we created above$B_obj = new B_class($A_obj);// print the info property through the B object to make sure it has the same value 'eeee'echo 'B_obj info: ' . $B_obj->A_obj->info . '<br/>';

// chage the info property$B_obj->change('xxxxx');// print the info property through the B object to make sure it changed the value to 'xxxxxx'echo 'B_obj info after change: ' . $B_obj->A_obj->info . '<br/>';// print the info property from the A_obj to see if the change through B_obj has affected itecho 'A_obj info: ' . $A_obj->info . '<br/>';

Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xxxxx. If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer

I tried to create an array with n depth using a recursive function passing array references around. So far I haven't had much luck and I couldn't find anything on the web. So I ended up using eval() and it seems to work well:<?phpforeach(array_keys($this->quantity_array) AS $key){ if($this->quantity_array[$key] > 0){$combinations = explode('-', $key);$eval_string = '$eval_array'; foreach(array_keys($combinations) AS $key2){$option_key_value = explode('_', $combinations[$key2]);$eval_string .= '['.$option_key_value[0].']['.$option_key_value[1].']'; }$eval_string .= ' = '.$this->quantity_array[$key].';'; eval($eval_string); } }?>

This produces an n dimensional array that will be available in the $eval_array variable. Hope it helps somebody!

when you refernce $temp to $object all it does is make $temp an alias to the same memory as $object, so doing $temp->getNext(); and $object->getNext(); are calling the same function on the same object. Try it out if you don't believe me.

To ffmandu13 at hotmail dot com, that's not correct. If you do a little research, you'll see that the Zend Engine employs "copy-on-write" logic, meaning that variables will be referenced instead of copied until it's actually written to. There's really no need to circumvent Zend's internal optimizations, since they're probably much more advanced than you think. Here's a good link to read over:

In reply to pike at kw dot nl, '&' is only apply to PHP 4.PHP 5 changed the behavior and the object is defaultly passed by references and if you turn on E_STRICT, you will get a notice:Strict Standards: Assigning the return value of new by reference is deprecated in xxxxIf you want to *copy* object in PHP 5, use object clone.

if your object seems to "forget" assignments you make after instantiation, realize that in

$foo = new Bar()

the variable on the left hand is a *copy* of the variable on the right hand. As a result, & references made during instantiation may point to the righthandside version of Bar() and not to $foo. you'd better use

Note that in PHP5 you generally don't need the reference operator -- at all -- when dealing with class objects, because PHP5 implements objects using Instances (which are more like C pointers than PHP's references system).

Can be shortened even further by using the often overlooked 'decrement until zero' concept. I don't much like decrementing to get a job done, but it can make a lot of sense when the evaluation-of-doneness is time-costly:

<?phpfor($i = sizeof($arrData); $i-- > 0 ; ) {// Do stuff }?>

One less variable to toss on the heap. NOTE that rather inconveniently, the $i goes to and hits zero only in the case where it starts out positive. When it is zero to begin with, it will become -1. Bug or feature? I've used it as a feature as a quick test of whether the $arrData array was empty to begin with. If you don't plan on using $i after the loop for anything, it makes no difference.

If you need to be doing something ascending-sequential though, then the temporary variable suggestions that others have made makes the most sense.

Finally (and important) ... if the $arrData array is somehow being dynamically modified in size due to the //Do-Stuff routine underneath, then you may have little-to-no recourse except to use the sizeof() method/function in the loop. Or, keep up the temporary variable in the loop as you push and pop things into and off the array.

(sigh... this is the notable failing of deeply linked internal data structures: to figure out the size of any linked list of arbitrarily composed elements, the entire array needs to be "walked" every time the sizeof() or count() method is used. But compared to the flexibility of associative arrays, the cost is mitigated by careful use.)