Jak działa PHP 'foreach'?

foreach obsługuje iterację trzech różnych typów wartości:

• Tablice
• Obiekty normalne
• Traversable obiekty

W dalszej części postaram się dokładnie wyjaśnić, jak iteracja działa w różnych przypadkach. Zdecydowanie najprostszym przypadkiem są Traversable obiekty, ponieważ dla tych foreach jest w zasadzie tylko cukrem składniowym dla kodu w tych liniach:

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

Dla klas wewnętrznych, rzeczywiste wywołania metod są unikane przez użycie wewnętrzne API, które zasadniczo odzwierciedla interfejs Iterator na poziomie C.

Iteracja tablic i zwykłych obiektów jest znacznie bardziej skomplikowana. Przede wszystkim należy zauważyć, że w PHP "tablice" są tak naprawdę uporządkowanymi słownikami i będą przesuwane zgodnie z tą kolejnością(która pasuje do kolejności wstawiania, o ile nie użyłeś czegoś takiego jak sort). Jest to sprzeczne z iteracją przez naturalną kolejność kluczy (jak często działają listy w innych językach) lub nie mając w ogóle określonej kolejności (jak często działają słowniki w innych językach).

To samo odnosi się również do obiektów, ponieważ właściwości obiektu mogą być postrzegane jako inny (uporządkowany) słownik mapujący nazwy właściwości do ich wartości, plus Obsługa widoczności. W większości przypadków właściwości obiektu nie są faktycznie przechowywane w ten raczej nieefektywny sposób. Jeśli jednak rozpoczniesz iterację nad obiektem, zwykle używana reprezentacja spakowana zostanie przekonwertowana na prawdziwy słownik. W tym momencie iteracja zwykłych obiektów staje się bardzo podobna do iteracji tablic (dlatego nie dyskutuję tu zbyt często o iteracji zwykłych obiektów).

• jeśli iterujesz przez odniesienie używając foreach ($arr as &$v) wtedy {[25] } zostanie zamienione w odniesienie I ty może go zmienić podczas iteracji.
• w PHP 5 to samo dotyczy nawet jeśli iterujesz według wartości, ale tablica była wcześniej referencją: $ref =& $arr; foreach ($ref as $v)
• obiekty mają semantykę przekazującą by-handle, co dla większości praktycznych celów oznacza, że zachowują się jak odniesienia. Tak więc obiekty mogą być zawsze zmieniane podczas iteracji.

Problem z zezwoleniem na modyfikacje podczas iteracji polega na tym, że element, na którym aktualnie się znajdujesz, jest usuwany. Powiedz, że używasz wskaźnika aby śledzić, w którym elemencie tablicy aktualnie się znajdujesz. Jeśli ten element jest teraz zwolniony, zostanie Ci zwisający wskaźnik (Zwykle skutkujący segfault).

Istnieją różne sposoby rozwiązania tego problemu. PHP 5 i PHP 7 różnią się znacząco pod tym względem i opiszę oba zachowania w następujący sposób. Podsumowanie jest takie, że podejście PHP 5 było raczej głupie i prowadzi do wszelkiego rodzaju dziwnych problemów z krawędzią, podczas gdy bardziej zaangażowane podejście PHP 7 skutkuje bardziej przewidywalnym i konsekwentne zachowanie.

Jako ostatni wstęp, należy zauważyć, że PHP używa zliczania referencji i kopiowania przy zapisie do zarządzania pamięcią. Oznacza to, że jeśli "skopiujesz" wartość, po prostu ponownie użyjesz starej wartości i zwiększysz jej liczbę referencji (refcount). Dopiero po wykonaniu jakiejś modyfikacji zostanie wykonana prawdziwa Kopia (zwana "duplikacją"). Zobacz jesteś okłamywany aby uzyskać bardziej obszerne wprowadzenie na ten temat.

PHP 5

Wewnętrzny wskaźnik tablicy i HashPointer

Tablice w PHP 5 mają jeden dedykowany "wskaźnik tablicy wewnętrznej" (IAP), który poprawnie obsługuje modyfikacje: za każdym razem, gdy element zostanie usunięty, będzie sprawdzane, czy IAP wskazuje na ten element. Jeśli tak się stanie, zostanie on przeniesiony do następnego elementu.

Podczas gdy foreach używa IAP, istnieje dodatkowa komplikacja: istnieje tylko jeden IAP, ale jedna tablica może być częścią wielu foreach pętle:

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

Aby obsługiwać dwie pętle jednocześnie z tylko jednym wewnętrznym wskaźnikiem tablicy, foreach wykonuje następujące manewry: zanim ciało pętli zostanie wykonane, foreach utworzy kopię zapasową wskaźnika do bieżącego elementu i jego hash do per-foreach HashPointer. Po uruchomieniu ciała pętli, IAP zostanie ustawiony z powrotem do tego elementu, jeśli nadal istnieje. Jeśli jednak element został usunięty, użyjemy go wszędzie tam, gdzie jest aktualnie IAP. Ten schemat przeważnie-niby-działa, ale jest wiele dziwnych zachowań, które możesz z tego wyciągnąć, niektóre z nich zademonstruję poniżej.

Duplikacja tablicy

IAP jest widoczną cechą tablicy (eksponowaną przez rodzinę funkcji current), ponieważ takie zmiany w IAP liczą się jako modyfikacje w semantyce kopiowania przy zapisie. To, niestety, oznacza, że foreach jest w wielu przypadkach zmuszona do powielania tablicy, nad którą się iteruje. Dokładne warunki to:

1. tablica nie jest reference (is_ref=0). Jeśli jest to odniesienie, to zmiany w nim są przypuszczalnie propagować, więc nie powinno być powielane.
2. tablica ma refcount>1. Jeśli refcount jest 1, to tablica nie jest współdzielona i możemy ją modyfikować bezpośrednio.

Jeśli tablica nie jest duplikowana (is_ref=0, refcount=1), to tylko jej refcount zostanie zwiększona (*). Dodatkowo, jeśli używana jest foreach przez odniesienie, to (potencjalnie zduplikowana) tablica zostanie zamieniona w Referencja.

Rozważ ten kod jako przykład, w którym następuje duplikacja:

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

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

Tutaj, $arr zostaną zduplikowane, aby zapobiec zmianom IAP na $arr przed wyciekiem do $outerArr. W powyższych warunkach tablica nie jest referencją (is_ref=0) i jest używana w dwóch miejscach (refcount=2). Ten wymóg jest niefortunny i artefakt nieoptymalnej implementacji (nie ma tu obaw o modyfikację podczas iteracji, więc tak naprawdę nie musimy używać IAP w miejsce).

(*) zwiększanie refcount tutaj brzmi nieszkodliwie, ale narusza semantykę copy-on-write (COW): oznacza to, że zmodyfikujemy IAP tablicy refcount=2, podczas gdy COW nakazuje, że modyfikacje mogą być wykonywane tylko na wartościach refcount=1. To naruszenie skutkuje widoczną przez użytkownika zmianą zachowania (podczas gdy krowa jest normalnie przezroczysta), ponieważ zmiana IAP na iterowanej tablicy będzie obserwowalna -- ale tylko do pierwszej modyfikacji Nie-IAP na tablicy. Zamiast tego, trzy" poprawne " opcje to: a) zawsze duplikować, b) nie zwiększać refcount i tym samym pozwalając na arbitralną modyfikację iterowanej tablicy w pętli lub c) w ogóle nie używać IAP (rozwiązanie PHP 7).

Kolejność awansowania pozycji

Jest jeszcze jeden szczegół implementacji, o którym należy pamiętać, aby poprawnie zrozumieć poniższe przykłady kodu. "Normalny" sposób zapętlania przez jakąś strukturę danych wyglądałby mniej więcej tak w pseudocode:

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

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

Mianowicie, wskaźnik tablicy jest już przesunięty do przodu zanim ciało pętli zostanie uruchomione. Oznacza to, że podczas gdy ciało pętli działa na elemencie $i, IAP jest już na elemencie $i+1. Jest to powód, dla którego próbki kodu pokazujące modyfikację podczas iteracji zawsze będą unset następny element, a nie bieżący jeden.

Przykłady: Twoje przypadki testowe

Trzy opisane powyżej aspekty powinny dostarczyć w większości pełnego wrażenia idiosynkrazji implementacji foreach i możemy przejść do omówienia niektórych przykładów.

Zachowanie Twoich przypadków testowych jest proste do wyjaśnienia w tym momencie:

• W testowych przypadkach 1 i 2 $array zaczyna się od refcount=1, więc nie będzie duplikowany przez foreach: tylko refcount jest zwiększany. Kiedy ciało pętli następnie modyfikuje tablicę (która ma refcount=2 w tym punkcie), duplikacja nastąpi w tym punkcie. Foreach będzie kontynuował pracę nad niezmodyfikowaną kopią $array.

• W przypadku testowym 3, tablica po raz kolejny nie jest duplikowana, więc foreach będzie modyfikować IAP zmiennej $array. Na końcu iteracji, IAP jest NULL (co oznacza, że iteracja została wykonana), co each wskazuje zwracając false.

• W przypadkach testowych 4 i 5 zarówno each, jak i reset są funkcjami by-reference. $array ma refcount=2 kiedy jest przekazywana do nich, więc musi być duplikowana. W związku z tym foreach będzie ponownie pracować nad oddzielną tablicą.

Przykłady: efekty current w foreach

Dobrym sposobem na pokazanie różnych zachowań powielania jest obserwowanie zachowania funkcji current() wewnątrz pętli foreach. Rozważmy ten przykład:

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

Tutaj powinieneś wiedzieć, że current() jest funkcją by-ref (właściwie: preferuj-ref), mimo że nie modyfikuje tablicy. Musi być tak, aby grać ładnie ze wszystkimi innymi funkcjami, takimi jak next, które są wszystkie przez-ref. By-reference passing implikuje, że tablica musi być oddzielona, a zatem $array i foreach-array będą różne. Powód, dla którego otrzymujesz 2 zamiast 1 jest również wymieniony powyżej: foreach przesuwa wskaźnik tablicy przed uruchomieniem kodu użytkownika, a nie po. Tak więc, mimo że kod znajduje się w pierwszym elemencie, foreach już przesunąłem wskaźnik do drugiego.

Teraz spróbujmy małej modyfikacji:

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

Tutaj mamy przypadek is_ref=1, więc tablica nie jest kopiowana (tak jak powyżej). Ale teraz, gdy jest to Referencja, tablica nie musi być już powielana podczas przechodzenia do funkcji by-ref current(). Tak więc current() i foreach działają na tej samej tablicy. Nadal jednak widzisz zachowanie "off-by-one", ze względu na sposób, w jaki {18]} przesuwa wskaźnik.

Masz to samo zachowanie, gdy doing by-ref iteration:

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

Ważną częścią jest to, że foreach uczyni $array is_ref = 1, gdy będzie iteracją przez odniesienie, więc zasadniczo masz taką samą sytuację jak powyżej.

Kolejna mała odmiana, tym razem przypiszemy tablicę do innej zmiennej:

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

Tutaj refcount $array wynosi 2, gdy pętla jest uruchomiona, więc raz naprawdę musimy zrobić duplikację z góry. Tak więc $array i tablica używana przez foreach będzie zupełnie od początku. Dlatego otrzymujesz pozycję IAP wszędzie tam, gdzie była przed pętlą (w tym przypadku była na pierwszej pozycji).

Przykłady: modyfikacja podczas iteracji

Próba uwzględnienia modyfikacji podczas iteracji jest miejscem, gdzie powstały wszystkie nasze problemy z foreach, więc warto rozważyć kilka przykładów w tym przypadku.

Rozważ te zagnieżdżone pętle na tej samej tablicy (gdzie iteracja by-ref jest używana, aby upewnić się, że naprawdę jest ten sam):

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)

Oczekiwaną częścią jest to, że (1, 2) brakuje na wyjściu, ponieważ element 1 został usunięty. Prawdopodobnie nieoczekiwane jest to, że zewnętrzna pętla zatrzymuje się po pierwszym elemencie. Dlaczego?

Powodem tego jest opisany powyżej hack zagnieżdżonej pętli: zanim ciało pętli zostanie uruchomione, aktualna pozycja IAP i hash są archiwizowane do HashPointer. Po ciele pętli zostanie przywrócony, ale tylko wtedy, gdy element nadal istnieje, w przeciwnym razie obecna pozycja IAP (cokolwiek to może być) jest używana zamiast. W powyższym przykładzie jest to dokładnie przypadek: bieżący element zewnętrznej pętli został usunięty, więc użyje IAP, który został już oznaczony jako zakończony przez wewnętrzną pętlę!

Kolejną konsekwencją mechanizmu HashPointer backup+restore jest to, że zmiany w IAP poprzez reset() itd. zazwyczaj nie mają wpływu foreach. Na przykład poniższy kod wykonuje się tak, jakby reset() nie były obecne w wszystkie:

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

Powodem jest to, że podczas gdy reset() tymczasowo modyfikuje IAP, zostanie on przywrócony do bieżącego elementu foreach po ciele pętli. Aby zmusić reset() do wywołania efektu na pętli, musisz dodatkowo usunąć bieżący element, aby mechanizm kopii zapasowej / przywracania nie zadziałał:

$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

Ale te przykłady są nadal przy zdrowych zmysłach. Prawdziwa zabawa zaczyna się, jeśli pamiętasz, że HashPointer restore używa wskaźnika do elementu i jego hash, aby określić, czy nadal istnieje. Ale: Hasze mają kolizje, a wskaźniki mogą być ponownie użyte! Oznacza to, że przy starannym wyborze klawiszy tablicy możemy sprawić, że foreach uwierzy, że element, który został usunięty nadal istnieje, więc przeskoczy bezpośrednio do niego. Przykład:

$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

Tutaj powinniśmy normalnie oczekiwać wyjścia 1, 1, 3, 4 zgodnie z poprzednimi regułami. Jak to się dzieje, że 'FYFY' ma ten sam hash co usunięty element 'EzFY', a alokator ponownie wykorzystuje tę samą lokalizację pamięci do przechowywania żywioł. Tak więc foreach kończy się bezpośrednio skacząc do nowo wstawionego elementu, a tym samym skracając pętlę.

Zastępowanie iteracyjnej jednostki podczas pętli

Ostatni dziwny przypadek, o którym chciałbym wspomnieć, to to, że PHP pozwala na zastąpienie iteracji encji podczas pętli. Możesz więc zacząć iterację na jednej tablicy, a następnie zastąpić ją inną tablicą w połowie. Można też rozpocząć iterację na tablicy, a następnie zastąpić ją obiektem:

$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 widać, że w tym przypadku PHP po prostu rozpocznie iterację drugiego elementu Od początku, gdy nastąpi podstawienie.

PHP 7

Iteratory Hashtable

Jeśli nadal pamiętasz, głównym problemem iteracji tablicy było to, jak poradzić sobie z usuwaniem elementów w połowie iteracji. PHP 5 używało do tego celu pojedynczego wskaźnika tablicy wewnętrznej (IAP), który był nieco nieoptymalny, ponieważ jeden wskaźnik tablicy musiał być rozciągnięty, aby obsługiwać wiele jednoczesnych pętli foreach i interakcja z reset() itd. na dodatek.

PHP 7 używa innego podejścia, a mianowicie obsługuje tworzenie dowolnej ilości zewnętrznych, bezpiecznych iteratorów hashtable. Iteratory te muszą być zarejestrowane w tablicy, z której punktu mają taką samą semantykę jak IAP: jeśli element tablicy zostanie usunięty, wszystkie Iteratory z hashtable wskazujące na ten element zostaną przeniesione do następnego elementu.

Oznacza to, że foreach nie będzie już używać IAP w ogóle . Pętla foreach nie będzie miała żadnego wpływu na wyniki current() itd. a na jego własne zachowanie nigdy nie będą miały wpływu takie funkcje jak reset() itp.

Duplikacja tablicy

Kolejna ważna zmiana pomiędzy PHP 5 i PHP 7 dotyczy duplikacji tablicy. Teraz, gdy IAP nie jest już używany, iteracja tablicy według wartości spowoduje tylko zwiększenie refcount (zamiast powielania tablicy) we wszystkich przypadkach. Jeśli tablica zostanie zmodyfikowana podczas pętli foreach, w w tym punkcie nastąpi duplikacja (zgodnie z copy-on-write) i foreach będzie nadal działać na starej tablicy.

W większości przypadków zmiana ta jest przejrzysta i nie ma innego wpływu niż lepsza wydajność. Jednak jest jedna okazja, w której powoduje to inne zachowanie, a mianowicie przypadek, w którym tablica była wcześniej referencją: {]}

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

Poprzednio iteracja według wartości tablicy referencyjnej była szczególnymi przypadkami. W tym przypadku nie doszło do powielania, więc wszystkie modyfikacje tablicy podczas iteracji będą odzwierciedlane przez pętlę. W PHP 7 ten szczególny przypadek znikł: iteracja według wartości tablicy będzie zawsze pracować nad oryginalnymi elementami, pomijając wszelkie modyfikacje podczas pętli.

To oczywiście nie dotyczy iteracji by-reference. Jeśli iterujesz przez odniesienie, wszystkie modyfikacje zostaną odzwierciedlone przez pętlę. Co ciekawe, to samo odnosi się do iteracji po wartości zwykłej obiekty:

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

Odzwierciedla to semantykę obiektów (tzn. zachowują się podobnie jak odniesienia nawet w kontekstach wartości).

Przykłady

• Przypadki testowe 1 i 2 zachowują ten sam wynik: iteracja tablicy według wartości zawsze działa na oryginalnych elementach. (W tym przypadku nawet refcounting i zachowanie duplikacji jest dokładnie takie samo pomiędzy PHP 5 i PHP 7).

• Zmiana przypadku testowego 3: Foreach nie używa już IAP, więc pętla nie ma wpływu na each(). Będzie miał to samo wyjście przed i po.

• Przypadki testowe 4 i 5 pozostają takie same: each() i reset() powieli tablicę przed zmianą IAP, podczas gdy foreach nadal używa oryginalnej tablicy. (Nie żeby zmiana IAP miała znaczenie, nawet gdyby tablica była współdzielona.)

Drugi zestaw przykładów dotyczył zachowanie current() w różnych konfiguracjach reference/refcounting. To już nie ma sensu, ponieważ current() nie ma wpływu na pętlę, więc jej wartość zwracana zawsze pozostaje taka sama.

Jednak, gdy rozważamy modyfikacje w iteracji, dostajemy kilka interesujących zmian. Mam nadzieję, że znajdziesz nowe zachowanie saner. Pierwszy przykład:

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

Jak widzisz, zewnętrzna pętla nie przerywa już po pierwszej iteracji. Powodem jest to, że obie pętle mają teraz całkowicie oddzielne Iteratory hashtable i nie ma już żadnego skażenia krzyżowego obu pętli poprzez współdzielony IAP.

Kolejny dziwny przypadek krawędzi, który jest teraz naprawiony, jest dziwnym efektem, który uzyskujesz, gdy usuwasz i dodajesz elementy, które mają ten sam 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

Poprzednio mechanizm przywracania Hashpointera przeskoczył bezpośrednio do nowego elementu, ponieważ "wyglądał" tak, jakby był taki sam jak usunięty element (ze względu na kolizję hash i wskaźnika). Ponieważ nie polegamy już na element hash dla czegokolwiek, nie jest to już problemem.