foreach
supports iteration over three different kinds of values:
In the following, I will try to explain precisely how iteration works in different cases. By far the simplest case is Traversable
objects, as for these foreach
is essentially only syntax sugar for code along these lines:
foreach ($it as $k => $v) { /* ... */ }
/* translates to: */
if ($it instanceof IteratorAggregate) {
$it = $it->getIterator();
}
for ($it->rewind(); $it->valid(); $it->next()) {
$v = $it->current();
$k = $it->key();
/* ... */
}
For internal classes, actual method calls are avoided by using an internal API that essentially just mirrors the Iterator
interface on the C level.
Iteration of arrays and plain objects is significantly more complicated. First of all, it should be noted that in PHP "arrays" are really ordered dictionaries and they will be traversed according to this order (which matches the insertion order as long as you didn't use something like sort
). This is opposed to iterating by the natural order of the keys (how lists in other languages often work) or having no defined order at all (how dictionaries in other languages often work).
The same also applies to objects, as the object properties can be seen as another (ordered) dictionary mapping property names to their values, plus some visibility handling. In the majority of cases, the object properties are not actually stored in this rather inefficient way. However, if you start iterating over an object, the packed representation that is normally used will be converted to a real dictionary. At that point, iteration of plain objects becomes very similar to iteration of arrays (which is why I'm not discussing plain-object iteration much in here).
So far, so good. Iterating over a dictionary can't be too hard, right? The problems begin when you realize that an array/object can change during iteration. There are multiple ways this can happen:
- If you iterate by reference using
foreach ($arr as &$v)
then $arr
is turned into a reference and you can change it during iteration.
- In PHP 5 the same applies even if you iterate by value, but the array was a reference beforehand:
$ref =& $arr; foreach ($ref as $v)
- Objects have by-handle passing semantics, which for most practical purposes means that they behave like references. So objects can always be changed during iteration.
The problem with allowing modifications during iteration is the case where the element you are currently on is removed. Say you use a pointer to keep track of which array element you are currently at. If this element is now freed, you are left with a dangling pointer (usually resulting in a segfault).
There are different ways of solving this issue. PHP 5 and PHP 7 differ significantly in this regard and I'll describe both behaviors in the following. The summary is that PHP 5's approach was rather dumb and lead to all kinds of weird edge-case issues, while PHP 7's more involved approach results in more predictable and consistent behavior.
As a last preliminary, it should be noted that PHP uses reference counting and copy-on-write to manage memory. This means that if you "copy" a value, you actually just reuse the old value and increment its reference count (refcount). Only once you perform some kind of modification a real copy (called a "duplication") will be done. See You're being lied to for a more extensive introduction on this topic.
PHP 5
Internal array pointer and HashPointer
Arrays in PHP 5 have one dedicated "internal array pointer" (IAP), which properly supports modifications: Whenever an element is removed, there will be a check whether the IAP points to this element. If it does, it is advanced to the next element instead.
While foreach
does make use of the IAP, there is an additional complication: There is only one IAP, but one array can be part of multiple foreach
loops:
// Using by-ref iteration here to make sure that it's really
// the same array in both loops and not a copy
foreach ($arr as &$v1) {
foreach ($arr as &$v) {
// ...
}
}
To support two simultaneous loops with only one internal array pointer, foreach
performs the following shenanigans: Before the loop body is executed, foreach
will back up a pointer to the current element and its hash into a per-foreach HashPointer
. After the loop body runs, the IAP will be set back to this element if it still exists. If however the element has been removed, we'll just use wherever the IAP is currently at. This scheme mostly-kinda-sort of works, but there's a lot of weird behavior you can get out of it, some of which I'll demonstrate below.
Array duplication
The IAP is a visible feature of an array (exposed through the current
family of functions), as such changes to the IAP count as modifications under copy-on-write semantics. This, unfortunately, means that foreach
is in many cases forced to duplicate the array it is iterating over. The precise conditions are:
- The array is not a reference (is_ref=0). If it's a reference, then changes to it are supposed to propagate, so it should not be duplicated.
- The array has refcount>1. If
refcount
is 1, then the array is not shared and we're free to modify it directly.
If the array is not duplicated (is_ref=0, refcount=1), then only its refcount
will be incremented (*). Additionally, if foreach
by reference is used, then the (potentially duplicated) array will be turned into a reference.
Consider this code as an example where duplication occurs:
function iterate($arr) {
foreach ($arr as $v) {}
}
$outerArr = [0, 1, 2, 3, 4];
iterate($outerArr);
Here, $arr
will be duplicated to prevent IAP changes on $arr
from leaking to $outerArr
. In terms of the conditions above, the array is not a reference (is_ref=0) and is used in two places (refcount=2). This requirement is unfortunate and an artifact of the suboptimal implementation (there is no concern of modification during iteration here, so we don't really need to use the IAP in the first place).
(*) Incrementing the refcount
here sounds innocuous, but violates copy-on-write (COW) semantics: This means that we are going to modify the IAP of a refcount=2 array, while COW dictates that modifications can only be performed on refcount=1 values. This violation results in user-visible behavior change (while a COW is normally transparent) because the IAP change on the iterated array will be observable -- but only until the first non-IAP modification on the array. Instead, the three "valid" options would have been a) to always duplicate, b) do not increment the refcount
and thus allowing the iterated array to be arbitrarily modified in the loop or c) don't use the IAP at all (the PHP 7 solution).
Position advancement order
There is one last implementation detail that you have to be aware of to properly understand the code samples below. The "normal" way of looping through some data structure would look something like this in pseudocode:
reset(arr);
while (get_current_data(arr, &data) == SUCCESS) {
code();
move_forward(arr);
}
However foreach
, being a rather special snowflake, chooses to do things slightly differently:
reset(arr);
while (get_current_data(arr, &data) == SUCCESS) {
move_forward(arr);
code();
}
Namely, the array pointer is already moved forward before the loop body runs. This means that while the loop body is working on element $i
, the IAP is already at element $i+1
. This is the reason why code samples showing modification during iteration will always unset
the next element, rather than the current one.
Examples: Your test cases
The three aspects described above should provide you with a mostly complete impression of the idiosyncrasies of the foreach
implementation and we can move on to discuss some examples.
The behavior of your test cases is simple to explain at this point:
In test cases 1 and 2 $array
starts off with refcount=1, so it will not be duplicated by foreach
: Only the refcount
is incremented. When the loop body subsequently modifies the array (which has refcount=2 at that point), the duplication will occur at that point. Foreach will continue working on an unmodified copy of $array
.
In test case 3, once again the array is not duplicated, thus foreach
will be modifying the IAP of the $array
variable. At the end of the iteration, the IAP is NULL (meaning iteration has done), which each
indicates by returning false
.
In test cases 4 and 5 both each
and reset
are by-reference functions. The $array
has a refcount=2
when it is passed to them, so it has to be duplicated. As such foreach
will be working on a separate array again.
Examples: Effects of current
in foreach
A good way to show the various duplication behaviors is to observe the behavior of the current()
function inside a foreach
loop. Consider this example:
foreach ($array as $val) {
var_dump(current($array));
}
/* Output: 2 2 2 2 2 */
Here you should know that current()
is a by-ref function (actually: prefer-ref), even though it does not modify the array. It has to be in order to play nice with all the other functions like next
which are all by-ref. By-reference passing implies that the array has to be separated and thus $array
and the foreach-array
will be different. The reason you get 2
instead of 1
is also mentioned above: foreach
advances the array pointer before running the user code, not after. So even though the code is at the first element, foreach
already advanced the pointer to the second.
Now lets try a small modification:
$ref = &$array;
foreach ($array as $val) {
var_dump(current($array));
}
/* Output: 2 3 4 5 false */
Here we have the is_ref=1 case, so the array is not copied (just like above). But now that it is a reference, the array no longer has to be duplicated when passing to the by-ref current()
function. Thus current()
and foreach
work on the same array. You still see the off-by-one behavior though, due to the way foreach
advances the pointer.
You get the same behavior when doing by-ref iteration:
foreach ($array as &$val) {
var_dump(current($array));
}
/* Output: 2 3 4 5 false */
Here the important part is that foreach will make $array
an is_ref=1 when it is iterated by reference, so basically you have the same situation as above.
Another small variation, this time we'll assign the array to another variable:
$foo = $array;
foreach ($array as $val) {
var_dump(current($array));
}
/* Output: 1 1 1 1 1 */
Here the refcount of the $array
is 2 when the loop is started, so for once we actually have to do the duplication upfront. Thus $array
and the array used by foreach will be completely separate from the outset. That's why you get the position of the IAP wherever it was before the loop (in this case it was at the first position).
Examples: Modification during iteration
Trying to account for modifications during iteration is where all our foreach troubles originated, so it serves to consider some examples for this case.
Consider these nested loops over the same array (where by-ref iteration is used to make sure it really is the same one):
foreach ($array as &$v1) {
foreach ($array as &$v2) {
if ($v1 == 1 && $v2 == 1) {
unset($array[1]);
}
echo "($v1, $v2)\n";
}
}
// Output: (1, 1) (1, 3) (1, 4) (1, 5)
The expected part here is that (1, 2)
is missing from the output because element 1
was removed. What's probably unexpected is that the outer loop stops after the first element. Why is that?
The reason behind this is the nested-loop hack described above: Before the loop body runs, the current IAP position and hash is backed up into a HashPointer
. After the loop body it will be restored, but only if the element still exists, otherwise the current IAP position (whatever it may be) is used instead. In the example above this is exactly the case: The current element of the outer loop has been removed, so it will use the IAP, which has already been marked as finished by the inner loop!
Another consequence of the HashPointer
backup+restore mechanism is that changes to the IAP through reset()
etc. usually do not impact foreach
. For example, the following code executes as if the reset()
were not present at all:
$array = [1, 2, 3, 4, 5];
foreach ($array as &$value) {
var_dump($value);
reset($array);
}
// output: 1, 2, 3, 4, 5
The reason is that, while reset()
temporarily modifies the IAP, it will be restored to the current foreach element after the loop body. To force reset()
to make an effect on the loop, you have to additionally remove the current element, so that the backup/restore mechanism fails:
$array = [1, 2, 3, 4, 5];
$ref =& $array;
foreach ($array as $value) {
var_dump($value);
unset($array[1]);
reset($array);
}
// output: 1, 1, 3, 4, 5
But, those examples are still sane. The real fun starts if you remember that the HashPointer
restore uses a pointer to the element and its hash to determine whether it still exists. But: Hashes have collisions, and pointers can be reused! This means that, with a careful choice of array keys, we can make foreach
believe that an element that has been removed still exists, so it will jump directly to it. An example:
$array = ['EzEz' => 1, 'EzFY' => 2, 'FYEz' => 3];
$ref =& $array;
foreach ($array as $value) {
unset($array['EzFY']);
$array['FYFY'] = 4;
reset($array);
var_dump($value);
}
// output: 1, 4
Here we should normally expect the output 1, 1, 3, 4
according to the previous rules. How what happens is that 'FYFY'
has the same hash as the removed element 'EzFY'
, and the allocator happens to reuse the same memory location to store the element. So foreach ends up directly jumping to the newly inserted element, thus short-cutting the loop.
Substituting the iterated entity during the loop
One last odd case that I'd like to mention, it is that PHP allows you to substitute the iterated entity during the loop. So you can start iterating on one array and then replace it with another array halfway through. Or start iterating on an array and then replace it with an object:
$arr = [1, 2, 3, 4, 5];
$obj = (object) [6, 7, 8, 9, 10];
$ref =& $arr;
foreach ($ref as $val) {
echo "$val\n";
if ($val == 3) {
$ref = $obj;
}
}
/* Output: 1 2 3 6 7 8 9 10 */
As you can see in this case PHP will just start iterating the other entity from the start once the substitution has happened.
PHP 7
Hashtable iterators
If you still remember, the main problem with array iteration was how to handle removal of elements mid-iteration. PHP 5 used a single internal array pointer (IAP) for this purpose, which was somewhat suboptimal, as one array pointer had to be stretched to support multiple simultaneous foreach loops and interaction with reset()
etc. on top of that.
PHP 7 uses a different approach, namely, it supports creating an arbitrary amount of external, safe hashtable iterators. These iterators have to be registered in the array, from which point on they have the same semantics as the IAP: If an array element is removed, all hashtable iterators pointing to that element will be advanced to the next element.
This means that foreach
will no longer use the IAP at all. The foreach
loop will be absolutely no effect on the results of current()
etc. and its own behavior will never be influenced by functions like reset()
etc.
Array duplication
Another important change between PHP 5 and PHP 7 relates to array duplication. Now that the IAP is no longer used, by-value array iteration will only do a refcount
increment (instead of duplication the array) in all cases. If the array is modified during the foreach
loop, at that point a duplication will occur (according to copy-on-write) and foreach
will keep working on the old array.
In most cases, this change is transparent and has no other effect than better performance. However, there is one occasion where it results in different behavior, namely the case where the array was a reference beforehand:
$array = [1, 2, 3, 4, 5];
$ref = &$array;
foreach ($array as $val) {
var_dump($val);
$array[2] = 0;
}
/* Old output: 1, 2, 0, 4, 5 */
/* New output: 1, 2, 3, 4, 5 */
Previously by-value iteration of reference-arrays was special cases. In this case, no duplication occurred, so all modifications of the array during iteration would be reflected by the loop. In PHP 7 this special case is gone: A by-value iteration of an array will always keep working on the original elements, disregarding any modifications during the loop.
This, of course, does not apply to by-reference iteration. If you iterate by-reference all modifications will be reflected by the loop. Interestingly, the same is true for by-value iteration of plain objects:
$obj = new stdClass;
$obj->foo = 1;
$obj->bar = 2;
foreach ($obj as $val) {
var_dump($val);
$obj->bar = 42;
}
/* Old and new output: 1, 42 */
This reflects the by-handle semantics of objects (i.e. they behave reference-like even in by-value contexts).
Examples
Let's consider a few examples, starting with your test cases:
Test cases 1 and 2 retain the same output: By-value array iteration always keep working on the original elements. (In this case, even refcounting
and duplication behavior is exactly the same between PHP 5 and PHP 7).
Test case 3 changes: Foreach
no longer uses the IAP, so each()
is not affected by the loop. It will have the same output before and after.
Test cases 4 and 5 stay the same: each()
and reset()
will duplicate the array before changing the IAP, while foreach
still uses the original array. (Not that the IAP change would have mattered, even if the array was shared.)
The second set of examples was related to the behavior of current()
under different reference/refcounting
configurations. This no longer makes sense, as current()
is completely unaffected by the loop, so its return value always stays the same.
However, we get some interesting changes when considering modifications during iteration. I hope you will find the new behavior saner. The first example:
$array = [1, 2, 3, 4, 5];
foreach ($array as &$v1) {
foreach ($array as &$v2) {
if ($v1 == 1 && $v2 == 1) {
unset($array[1]);
}
echo "($v1, $v2)\n";
}
}
// Old output: (1, 1) (1, 3) (1, 4) (1, 5)
// New output: (1, 1) (1, 3) (1, 4) (1, 5)
// (3, 1) (3, 3) (3, 4) (3, 5)
// (4, 1) (4, 3) (4, 4) (4, 5)
// (5, 1) (5, 3) (5, 4) (5, 5)
As you can see, the outer loop no longer aborts after the first iteration. The reason is that both loops now have entirely separate hashtable iterators, and there is no longer any cross-contamination of both loops through a shared IAP.
Another weird edge case that is fixed now, is the odd effect you get when you remove and add elements that happen to have the same hash:
$array = ['EzEz' => 1, 'EzFY' => 2, 'FYEz' => 3];
foreach ($array as &$value) {
unset($array['EzFY']);
$array['FYFY'] = 4;
var_dump($value);
}
// Old output: 1, 4
// New output: 1, 3, 4
Previously the HashPointer restore mechanism jumped right to the new element because it "looked" like it's the same as the removed element (due to colliding hash and pointer). As we no longer rely on the element hash for anything, this is no longer an issue.
Best Answer
How to create a Virtual Host in WampServer
WAMPServer 3 has made this process much easier!
You can do almost everything from a utility provided as part of WAMPServer.
Create a folder inside to contain your project.site. This can be under the
C:\wamp\www\
directory or in a completely seperate folder likeC:\websites
.Create a folder inside the location you have chosen EG
C:\websites\project1\www
or under thec:\wamp\www\project1\www
Now open localhost
wampmanager->localhost
and click on the linkAdd a Virtual Host
under the TOOLS section on the homepage.You will see a page like this:
Fill in the fields as specified by the instructions above each field
The Virtual Host config will have been created for you.
Now you must restart the DNS Cache. You can do this from the wampmanager menus like this
right click wampmanager->Tools->Restart DNS
. The DNS Cache will be restarted and then Apache will also be stopped and restarted. When the wampmanager icon goes green again all is completed.Now you must create a simple
index.php
file or install your site into the folder you created above.Assuming your VH was called
project.dev
You should see that name under the Your Virtual Hosts Section of the WAMPServer homepage.You can launch the site from this menu, or just use the new Domain Name in the address bar EG
project1.dev
and the site shoudl launch.Old WAMPServer 2.5 mechanism, or if you want to do it all manually
There has been a change of concept in WampServer 2.5 and above and there is a good reason for this change!
In WampServer it is now STRONGLY encouraged to create a Virtual Host for each of your projects, even if you hold them in a
\wamp\www\subfolder
structure.Virtual Hosts Documentation
Virtual Host Examples
The WampServer home page (
\wamp\www\index.php
) now expects you to have created a Virtual Host for all your projects and will therefore work properly only if you do so.History
In order to make life easier for beginners using WampServer to learn PHP Apache and MySQL it was suggested that you create subfolders under the
\wamp\www\
folder.These subfolders would then show as links in the WampServer Homepage under a menu called 'Your Projects' and these links would contain a link to
localhost/subfoldername
.Acceptable only for simple tutorials
This made life easy for the complete beginner, and was perfectly acceptable for example for those following tutorials to learn PHP coding. However it was never intended for use when developing a real web site that you would later want to copy to your live hosted server. In fact if you did use this mechanism it often caused problems as the live sites configuration would not match your development configuration.
The Problem for real website development.
The reason for this is of course that the default DocumentRoot setting for wamp is
DocumentRoot "c:/wamp/www/"
regardless of what your subfolder was called. This ment that often used PHP code that queried the structure or your site received different information when running on your development WampServer to what it would receive when running on a live hosted server, where the DocumentRoot configuration points to the folder at the top of the website file hierarchy. This kind of code exists in many frameworks and CMS's for example WordPress and Joomla etc.
For Example
Lets say we have a project called project1 held in
wamp\www\project1
and run incorrectly aslocalhost/project1/index.php
This is what would be reported by some of the PHP command in question:
Now if we had correctly defined that site using a Virtual Host definition and ran it as
http://project1
the results on the WAMPServer devlopment site will match those received when on a live hosted environment.Now this difference may seem trivial at first but if you were to use a framework like WordPress or one of the CMS's like Joomla for example, this can and does cause problems when you move your site to a live server.
How to create a Virtual Host in WampServer
Actually this should work basically the same for any wndows Apache server, with differences only in where you may find the Apache config files.
There are 3 steps to create your first Virtual Host in Apache, and only 2 if you already have one defined.
Step 1, Create the Virtual Host definition(s)
Edit the file called
httpd-hosts.conf
which for WampServer lives in(Apache version numbers may differ, engage brain before continuing)
If this is the first time you edit this file, remove the default example code, it is of no use.
I am assuming we want to create a definition for a site called project1 that lives in
Very important, first we must make sure that localhost still works so that is the first VHOST definition we will put in this file.
Now we define our project: and this of course you do for each of your projects as you start a new one.
NOTE: That each Virtual Host as its own
DocumentRoot
defined. There are also many other parameters you can add to a Virtual Hosts definition, check the Apache documentation.Small aside
The way virtual hosts work in Apache: The first definition in this file will also be the default site, so should the domain name used in the browser not match any actually defined virtually hosted domain, making localhost the first domain in the file will therefore make it the site that is loaded if a hack attempt just uses your IP Address. So if we ensure that the Apache security for this domain is ALWAYS SET TO
any casual hack from an external address will receive an error and not get into your PC, but should you misspell a domain you will be shown the WampServer homepage, because you are on the same PC as WampServer and therfore
local
.Step 2:
Add your new domain name to the HOSTS file. Now we need to add the domain name that we have used in the Virtual Host definition to the HOSTS file so that windows knows where to find it. This is similiar to creating a DNS A record, but it is only visible in this case on this specific PC.
Edit
C:\windows\system32\drivers\etc\hosts
The file has no extension and should remain that way. Watch out for notepad, as it may try and add a
.txt
extension if you have no better editor. I suggest you download Notepad++, its free and a very good editor.Also this is a protected file so you must edit it with administrator privileges, so launch you editor using the Run as Administrator menu option.
The hosts file should look like this when you have completed these edits
Note that you should have definitions in here for the IPV4 loopback address
127.0.0.1
and also the IPV6 loopback address::1
as Apache is now IPV6 aware and the browser will use either IPV4 or IPV6 or both. I have no idea how it decides which to use, but it can use either if you have the IPV6 stack turned on, and most window OS's do as of XP SP3.Now we must tell windows to refresh its domain name cache, so launch a command window again using the Run as Administrator menu option again, and do the following.
This forces windows to clear its domain name cache and reload it, in reloading it will re-read the HOSTS file so now it knows about the domain
project1
.Step 3: Uncomment the line in httpd.conf that includes the Virtual Hosts definition file.
Edit your httpd.conf, use the wampmanager.exe menus to make sure you edit the correct file.
Find this line in httpd.conf
And just remove the
#
to uncomment that line.To activate this change in you running Apache we must now stop and restart the Apache service.
Now if the WAMP icon in the system tray does not go GREEN again, it means you have probably done something wrong in the
\wamp\bin\apache\apache2.4.9\conf\extra\httpd-hosts.conf
file.If so here is a useful mechanism to find out what is wrong. It uses a feature of the Apache exe (httpd.exe) to check its config files and report errors by filename and line numbers.
Launch a command window.
So fix the errors and retest again until you get the output
Now there is one more thing.
There are actually 2 new menu items on the wampmanager menu system. One called 'My Projects' which is turned on by default. And a second one, called 'My Virtual Hosts', which is not activated by default.
'My Projects' will list any sub directory of the \wamp\www directory and provide a link to launch the site in that sub directory. As I said earlier, it launches 'project1` and not 'localhost/project1' so to make the link work we must create a Virtual Host definition to make this link actually launch that site in your browser, without the Virtual Host definition it's likely to launch a web search for the site name as a keyword or just return a site not found condition.
The 'My Virtual Hosts' menu item is a little different. It searches the file that is used to define Virtual Hosts ( we will get to that in a minute ) and creates menu links for each ServerName parameter it finds and creates a menu item for each one. This may seem a little confusing as once we create a Virtual Host definition for the sub directories of the \wamp\www folder some items will appear on both of the 'My Projects' menu and the 'My Virtual Hosts' menu's.
How do I turn this other 'My Virtual Hosts' menu on?
;WAMPPROJECTSUBMENU
, its in the '[Menu.Left]' section.;WAMPVHOSTSUBMENU
either before or after the;WAMPPROJECTSUBMENU
parameter.Big Note The new menu will only appear if you already have some Virtual Hosts defined! Otherwise you will see no difference until you define a VHOST.
Now if you take this to its logical extension
You can now move your web site code completely outside the
\wamp\
folder structure simply by changing the DocumentRoot parameter in the VHOST definition. So for example you could do this:Create a folder on the wamp disk or any other disk ( beware of network drive, they are a bit more complicated)
You now copy your site code to, or start creating it in the
\websites\example.com\www
folder and define your VHOST like this:Then add this new development domain to the HOSTS file:
NOTE: It is not a good idea to use a ServerName or ServerAlias that is the same as your live domain name, as if we had used example.com as the ServerName it would mean we could no longer get to the real live site from this PC as it would direct example.com to 127.0.0.1 i.e. this PC and not out onto the internet.
ALSO: See that I have allowed this site to be accessed from the internet from within the VHOST definitions, this change will apply to only this site and no other. Very useful for allowing a client to view your changes for an hour or so without having to copy them to the live server. This does mean that we have to edit this file manually to turn this access on and off rather than use the Put Online/Offline menu item on wampmanager.
Also I have added some modifications to the PHP config, again that will only apply to this one site. Very useful when maintaining a site with specific requirement unlike all the other sites you maintain. I guess we can assume from the parameters used that it has a long running page in it somewhere and it is very badly written and will not run with errors being displayed on the browser without making a horrible mess of the page. Believe me sites like this exist and people still want them maintained badly. But this mean we only have to change these parameters for this specific site and not globally to all Virtual sites running on WampServer.