Comment PHP 'foreach' fonctionne-t-il réellement?

foreach supporte l'itération sur trois différents types de valeurs:

• matrices
• objets normaux
• Traversable objets

dans ce qui suit, je vais essayer d'expliquer précisément comment fonctionne l'itération dans les différents cas. De loin le cas le plus simple sont Traversable des objets, comme pour ces foreach est essentiellement seulement la syntaxe de sucre pour code le long de ces lignes:

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();
    /* ... */
}

pour les classes internes les appels de méthodes réels sont évités en utilisant une API interne qui reflète essentiellement l'interface Iterator au niveau C.

L'itération des tableaux et des objets simples est beaucoup plus compliquée. Tout d'abord, il convient de noter que dans PHP "tableaux" sont réellement commandé dictionnaires et ils seront traversés selon cet ordre (qui correspond à la ordre d'insertion aussi longtemps que vous n'avez pas utilisé quelque chose comme sort ). Ceci est opposé à l'itération par l'ordre naturel des clés (comment les listes dans d'autres langues fonctionnent souvent) ou à l'absence d'ordre défini du tout (comment les dictionnaires dans d'autres langues fonctionnent souvent).

la même chose s'applique aussi aux objets, car les propriétés de l'objet peuvent être vues comme un autre dictionnaire (commandé) mettant en correspondance les noms des propriétés avec leurs valeurs, en plus de quelques manipulations de visibilité. Dans la majorité des cas, la les propriétés des objets ne sont pas stockées de cette manière plutôt inefficace. Cependant si vous commencez à itérer sur un objet, la représentation emballée qui est normalement utilisée sera convertie en un vrai dictionnaire. À ce moment-là, l'itération d'objets simples devient très similaire à l'itération de tableaux (c'est pourquoi je ne parle pas beaucoup de l'itération d'objets simples ici).

pour l'instant, tout va bien. Parcourir un dictionnaire ne peut pas être trop dur, non? Les problèmes commencent quand vous réalisez qu'un tableau/objet peut changer pendant l'itération. Il y a plusieurs façons d'y arriver:

• si vous itérez par référence en utilisant foreach ($arr as &$v) alors $arr est transformé en référence et vous pouvez le changer pendant l'itération.
• en PHP 5 la même chose s'applique même si vous itérez par la valeur, mais le tableau était une référence avant: $ref =& $arr; foreach ($ref as $v)
• objets ont by-handle passing sémantique, qui pour doit pratique signifie qu'ils se comportent comme des références. Ainsi, les objets peuvent toujours être changés pendant l'itération.

le problème avec l'autorisation des modifications pendant l'itération est le cas où l'élément sur lequel vous êtes actuellement est supprimé. Disons que vous utilisez un pointeur pour garder une trace de l'élément de tableau où vous êtes actuellement. Si cet élément est maintenant libéré, il vous reste un pointeur pendulaire (résultant habituellement en une segfault).

il y a différentes façons de résoudre ce problème. PHP 5 et PHP 7 diffèrent de manière significative à cet égard et je vais décrire les deux comportements dans ce qui suit. Le résumé est que L'approche de PHP 5 était plutôt stupide et conduit à toutes sortes de bizarre bord-cas, tandis que L'approche de PHP 7 plus impliqué se traduit par un comportement plus prévisible et cohérent.

en dernier lieu, il est à noter que PHP utilise le comptage de référence et la copie-sur-écriture pour gérer la mémoire. Cela signifie que si vous "copier" une valeur, vous n'avez qu'à réutiliser l'ancienne valeur et incrémenter son compte de référence (refcount). Une fois que vous avez effectué une modification, une copie réelle (appelée "duplication") sera effectuée. Voir on vous ment à pour une introduction plus détaillée sur ce sujet.

PHP 5

Interne pointeur sur le tableau et HashPointer

tableaux en PHP 5 ont un pointeur de tableau interne dédié" (IAP), qui supporte correctement les modifications: chaque fois qu'un élément est supprimé, il y aura une vérification si L'IAP pointe vers cet élément. S'il le fait, il est avancé à l'élément suivant à la place.

alors que foreach utilise l'IAP, il y a une complication supplémentaire: il n'y a qu'un IAP, mais un tableau peut faire partie de plusieurs boucles foreach:

// 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) {
        // ...
    }
}

pour supporter deux boucles simultanées avec un seul pointeur de réseau interne, foreach exécute les schenanigans suivants: avant que le corps de boucle soit exécuté, foreach sauvegardera un pointeur vers l'élément courant et son hachage dans un per-foreach HashPointer . Après l'exécution du corps de boucle, L'IAP sera ramené à cet élément s'il existe toujours. Toutefois, si l'élément a été supprimé, nous allons simplement utiliser où que le PEI est actuellement. Ce schéma fonctionne en quelque sorte, mais il y a beaucoup de comportements bizarres que vous pouvez en retirer, dont certains que je vais vous montrer ci-dessous.

duplication de tableaux

L'IAP est une caractéristique visible d'un tableau (exposée à travers la famille de fonctions current ), car de telles modifications à L'IAP comptent comme des modifications sous sémantique copie-sur-écriture. Cela signifie malheureusement que foreach est dans de nombreux cas forcé de dupliquer le tableau sur lequel il itère. Les conditions précises sont:

1. Le tableau n'est pas une référence (is_ref=0). Si c'est une référence, puis les changements à elle sont supposé à propager, donc il ne doit pas être dupliqué.
2. le tableau a refcount>1. Si refcount est 1, alors le tableau n'est pas partagé et nous sommes libres de le modifier directement.

si le tableau n'est pas dupliqué (is_ref=0, refcount=1), alors seul son refcount sera incrémenté (*). De plus, si foreach par référence est utilisé, alors le tableau (potentiellement dupliqué) sera tourné dans une référence.

considérez ce code comme un exemple de duplication:

function iterate($arr) {
    foreach ($arr as $v) {}
}

$outerArr = [0, 1, 2, 3, 4];
iterate($outerArr);

ici, $arr sera dupliqué pour éviter que les changements de Pia sur $arr ne fuient vers $outerArr . En termes des conditions ci-dessus, le tableau n'est pas une référence (is_ref=0) et est utilisé à deux endroits (refcount=2). Cette exigence est malheureuse et un artefact de la mise en œuvre sous-optimale (il n'y a aucune préoccupation de modification pendant l'itération ici, donc nous n'avons pas vraiment besoin d'utiliser L'IAP en premier lieu).

( * ) incrémenter le refcount ici semble anodin, mais viole la sémantique de copie-sur-écriture (COW): cela signifie que nous allons modifier L'IAP d'un tableau refcount=2, alors que COW dicte que les modifications ne peuvent être effectuées que sur les valeurs de refcount=1. Cette violation entraîne un changement de comportement visible par l'utilisateur( alors que la vache est normalement transparente), parce que le changement IAP sur le tableau itéré sera observable -- mais seulement jusqu'à la première modification non-IAP sur le tableau. Au lieu de cela, les trois options "valides" auraient été a) de toujours dupliquer, b) de ne pas incrémenter le refcount et donc de permettre au tableau itéré d'être modifié arbitrairement dans la boucle, ou C) de ne pas utiliser l'IAP du tout (la solution PHP 7).

la Position de l'avancement de la commande

il y a un dernier détail de mise en œuvre que vous devez connaître pour bien comprendre les exemples de code ci-dessous. La façon "normale" de passer en boucle à travers une structure de données ressemblerait à quelque chose comme ceci en pseudo-code:

reset(arr);
while (get_current_data(arr, &data) == SUCCESS) {
    code();
    move_forward(arr);
}

cependant foreach , étant un flocon de neige assez spécial, choisit de faire les choses légèrement différemment:

reset(arr);
while (get_current_data(arr, &data) == SUCCESS) {
    move_forward(arr);
    code();
}

à savoir, le pointeur de tableau est déjà avancé avant le corps de boucle exécute. Cela signifie que pendant que le corps de boucle travaille sur l'élément $i , l'IAP est déjà à l'élément $i+1 . C'est la raison pour laquelle les échantillons de code montrant une modification au cours de l'itération vont toujours désactiver l'élément suivant , plutôt que l'élément actuel.

Exemples: Vos cas de test

les trois aspects décrits ci-dessus devraient vous donner une impression généralement complète des idiosyncrasies de la mise en œuvre de chaque foreach et nous pouvons passer à l'examen de quelques exemples.

Le comportement de vos cas de test est simple à expliquer:

• dans les cas d'essai 1 et 2 $array commence avec refcount=1, Il ne sera donc pas dupliqué par foreach: seul le refcount est incrémenté. Lorsque le corps de boucle modifie par la suite le tableau (qui a refcount=2 à ce point), la duplication se produira à ce point. Foreach continuera à travailler sur une copie non modifiée de $array .

• dans le cas d'essai 3, encore une fois le tableau n'est pas dupliqué, donc foreach modifiera L'IAP de la variable $array . À la fin de l'itération, L'IAP est nul (ce qui signifie itération effectuée), ce qui signifie each indique en retournant false .

• dans les cas d'essai 4 et 5, les deux each et reset sont des fonctions de référence. Le $array a un refcount=2 quand il leur est transmis, il doit donc être dupliqué. En tant que tel foreach fonctionnera à nouveau sur un tableau séparé.

exemples: effets de current in foreach

une bonne façon de montrer les différents comportements de duplication est d'observer le comportement de la fonction current() à l'intérieur d'une boucle foreach. Prenons l'exemple suivant:

foreach ($array as $val) {
    var_dump(current($array));
}
/* Output: 2 2 2 2 2 */

ici, vous devez savoir que current() est un sous-ref fonction (en fait: préférez-ref), même si elle ne modifie pas le tableau. Il faut pour jouer gentil avec toutes les autres fonctions comme le next , qui sont tous par-réf. Le passage de référence implique que le tableau doit être séparé et donc $array et le tableau de foreach sera différent. La raison pour laquelle vous obtenez 2 au lieu de 1 est également mentionnée ci-dessus: foreach avance le pointeur de tableau avant l'exécution du code Utilisateur, pas après. Donc, même si le code est au premier élément, foreach a déjà avancé le pointeur au second.

essayons maintenant une petite modification:

$ref = &$array;
foreach ($array as $val) {
    var_dump(current($array));
}
/* Output: 2 3 4 5 false */

nous avons Ici l'is_ref=1 cas, le tableau n'est pas copié (comme ci-dessus). Mais maintenant qu'il s'agit d'une référence, le tableau ne doit plus être dupliqué en passant à la fonction by-ref current() . Ainsi current() et pour chaque travail sur le même tableau. Vous voir encore le comportement off-by-one cependant, en raison de la façon foreach avance le pointeur.

, Vous obtenez le même comportement quand on fait par-ref itération:

foreach ($array as &$val) {
    var_dump(current($array));
}
/* Output: 2 3 4 5 false */

ici la partie importante est que foreach fera $array un is_ref=1 quand il est itéré par référence, donc fondamentalement vous avez la même situation que ci-dessus.

une autre petite variation, cette fois nous assignerons le tableau à une autre variable:

$foo = $array;
foreach ($array as $val) {
    var_dump(current($array));
}
/* Output: 1 1 1 1 1 */

ici le refcount du $array est 2 Quand la boucle est lancée, donc pour une fois nous devons en fait faire la duplication à l'avance. Ainsi $array et le réseau utilisé par foreach seront complètement séparés dès le début. C'est pourquoi vous obtenez la position de l'IAP, là où il était avant la boucle (dans ce cas, il était à la première position).

exemples: Modification pendant l'itération

essayer pour tenir compte des modifications pendant l'itération est où tous nos problèmes foreach origine, donc il sert à considérer quelques exemples pour ce cas.

considérez ces boucles imbriquées sur le même tableau (où l'itération de by-ref est utilisée pour s'assurer qu'elle est vraiment la même):

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)

la partie attendue ici est que (1, 2) est absent de la sortie, parce que l'élément 1 a été supprimé. Ce qui est probablement inattendu, c'est que l' boucle externe s'arrête après le premier élément. Pourquoi est-ce?

la raison derrière ceci est le hack de boucle imbriquée décrit ci-dessus: avant que le corps de boucle s'exécute, la position IAP actuelle et le hachage est sauvegardé dans un HashPointer . Après le corps de boucle il sera restauré, mais seulement si l'élément existe encore, sinon la position IAP actuelle (quelle qu'elle soit) est utilisée à la place. Dans l'exemple ci-dessus, c'est exactement le cas: L'élément courant de la boucle externe a été supprimer, il utilisera donc L'IAP, qui a déjà été marqué comme terminé par la boucle intérieure!

une autre conséquence du mécanisme HashPointer backup+restore est que les modifications à L'IAP bien que reset() etc. habituellement n'ont pas d'impact foreach. Par exemple, le code suivant s'exécute comme si le reset() n'était pas présent du tout:

$array = [1, 2, 3, 4, 5];
foreach ($array as &$value) {
    var_dump($value);
    reset($array);
}
// output: 1, 2, 3, 4, 5

la raison en est que, tandis que reset() modifie temporairement le PEI, il sera restauré à l'élément courant avant chaque élément après le corps de boucle. Pour forcer reset() à faire un effet sur la boucle, vous devez en outre supprimer l'élément courant, de sorte que le mécanisme de sauvegarde/restauration échoue:

$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

mais, ces exemples sont toujours sains. Le vrai plaisir commence si vous vous souvenez que la restauration HashPointer utilise un pointeur sur l'élément et son hachage pour déterminer s'il existe toujours. Mais: Hashes ont des collisions, et des pointeurs peuvent être réutilisés! Cela signifie que, avec un choix prudent de touches de tableau, nous pouvons faire foreach croire qu'un élément qui a été supprimé existe toujours, de sorte qu'il va sauter directement à elle. Un exemple:

$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

ici, nous devrions normalement attendre la sortie 1, 1, 3, 4 selon les règles précédentes. Comment se fait-il que 'FYFY' possède le même hachage que l'élément supprimé 'EzFY' , et que l'allocateur réutilise le même emplacement mémoire pour stocker l'élément. Donc foreach finit par sauter directement à l'élément nouvellement inséré, ce qui raccourcit la boucle.

remplaçant l'entité itérée pendant la boucle

un dernier cas étrange que je voudrais mentionner, est que PHP vous permet de remplacer l'entité itérée pendant la boucle. Vous pouvez donc commencer à itérer sur un tableau et le remplacer par un autre tableau à mi-parcours. Ou commencer à itérer sur un tableau puis le remplacer par un objet:

$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 */

comme vous pouvez le voir dans ce cas, PHP va juste commencer à itérer l'autre entité dès le début une fois que la substitution a eu lieu.

PHP 7

table de hachage des itérateurs

si vous vous souvenez encore, le principal problème avec l'itération du tableau était comment gérer la suppression des éléments au milieu de l'itération. PHP 5 a utilisé un seul pointeur de tableau interne (IAP) à cette fin, ce qui était quelque peu sous-optimal, comme un tableau pointeur a dû être étiré pour soutenir plusieurs boucles simultanées foreach et interaction avec reset() etc. sur le dessus de cela.

PHP 7 utilise une approche différente, à savoir qu'il supporte la création d'une quantité arbitraire d'itérateurs externes et sûrs. Ces itérateurs doivent être enregistrés dans le tableau, à partir de quel point ils ont la même sémantique que L'IAP: si un élément de tableau est supprimé, tous les itérateurs hashtable pointant vers celui élément sera avancé à l'élément suivant.

cela signifie que foreach n'utilisera plus le IAP du tout . La boucle foreach aura absolument aucun effet sur les résultats de current() etc. et son propre comportement ne sera jamais influencé par des fonctions comme reset() etc.

duplication de tableaux

un autre changement important entre PHP 5 et PHP 7 concerne la duplication de tableaux. Maintenant que L'IAP n'est plus utilisé, l'itération du tableau des valeurs partielles ne fera qu'un incrément de refcount (au lieu de dupliquer le tableau) dans tous les cas. Si le tableau est modifié pendant la boucle foreach, à ce point une duplication se produira (selon copie-sur-écriture) et foreach continuera à travailler sur le vieux tableau.

Dans la plupart des cas, ce changement est transparent et n'a pas d'autre effet que de meilleures performances. Cependant, il est une occasion où il en résulte un comportement différent, à savoir le cas où le tableau était une référence auparavant:

$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 */

auparavant, l'itération de valeurs partielles des tableaux de référence était des cas spéciaux. Dans ce cas, aucune duplication ne s'est produite, de sorte que toutes les modifications du tableau au cours de l'itération seraient reflétées par la boucle. En PHP 7, ce cas particulier est passé: une itération de by-value d'un tableau va toujours continuer à travailler sur les éléments originaux, sans tenir compte des modifications pendant la boucle.

cela, bien sûr, ne s'applique pas à l'itération par référence. Si vous itérez par référence toutes les modifications seront répercutées par la boucle. Il est intéressant de noter qu'il en va de même pour l'itération en fonction de la valeur des objets simples:

$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 */

cela reflète la sémantique de la poignée des objets (c'est-à-dire qu'ils se comportent comme des références, même dans des contextes de valeurs partielles).

exemples

voyons quelques exemples, en commençant par votre test jurisprudence:

• les cas D'essai 1 et 2 conservent le même résultat: l'itération du tableau des valeurs partielles continue toujours de travailler sur les éléments originaux. (Dans ce cas, même le refcounting et le comportement de duplication sont exactement les mêmes entre PHP 5 et PHP 7).

• test case 3 Change: Foreach n'utilise plus L'IAP, de sorte que each() n'est pas affecté par la boucle. Il aura la même sortie avant et après.

• les cas D'essai 4 et 5 restent les mêmes: each() et reset() dupliqueront le tableau avant de changer L'IAP, tandis que foreach utilise toujours le tableau original. (Non pas que le PEI changement aurait de l'importance, même si le tableau est partagé.)

la deuxième série d'exemples était liée au comportement de current() sous différentes configurations de référence/recomptage. Cela n'a plus de sens, comme current() n'est absolument pas affecté par la boucle, de sorte que sa valeur de retour reste toujours la même.

Cependant, nous obtenons quelques changements intéressants lorsque nous considérons des modifications au cours de l'itération. J'espère que vous trouverez le nouveau comportement plus sain d'esprit. Le premier exemple:

$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) 

comme vous pouvez le voir, la boucle extérieure n'est plus interrompue après la première itération. La raison est que les deux boucles ont maintenant des itérateurs hashtable entièrement séparés, et il n'y a pas plus longue toute contamination croisée des deux boucles par un IAP partagé.

un autre cas de bord bizarre qui est fixé maintenant, est l'effet étrange que vous obtenez lorsque vous supprimez et ajoutez des éléments qui se produisent d'avoir le même hachage:

$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

auparavant, le mécanisme de restauration HashPointer sautait directement au nouvel élément, parce qu'il "ressemblait" à l'élément remove (dû à la collision de hachage et pointeur). Comme nous ne dépendons plus sur le hachage d'élément pour rien, ce n'est plus un problème.