reference - referencja

DICTIONARY_PL.md

@@ -80,3 +80,4 @@
 - to escape - uwolnić (uciec?)
 - structure types - typy struktury
 - idiomatic - idiomatyczny
+- with respect to - w odniesieniu do (mając na uwadze?)

src/04-pointers.md

@@ -67,7 +67,7 @@ user -> ------------ (id)
         ------------
 ```
 
-Należy zwrócić uwagę na dwie ważne rzeczy. Po pierwsze, nasza zmienna `user` wskazuje na początek naszej struktury. Drugą jest to, że pola są ułożone sekwencyjnie. Pamiętaj, że nasz `user` ma również typ. Ten typ mówi nam, że `id` jest 64-bitową liczbą całkowitą, a `power` jest 32-bitową liczbą całkowitą. Uzbrojony w odniesienie do początku naszych danych i typu, kompilator może przetłumaczyć `user.power` na: _dostęp do 32-bitowej liczby całkowitej znajdującej się 64 bity od początku_. Na tym polega moc zmiennych, odwołują się one do pamięci i zawierają informacje o typie niezbędne do zrozumienia i manipulowania pamięcią w znaczący sposób.
+Należy zwrócić uwagę na dwie ważne rzeczy. Po pierwsze, nasza zmienna `user` wskazuje na początek naszej struktury. Drugą jest to, że pola są ułożone sekwencyjnie. Pamiętaj, że nasz `user` ma również typ. Ten typ mówi nam, że `id` jest 64-bitową liczbą całkowitą, a `power` jest 32-bitową liczbą całkowitą. Uzbrojony w referencję do początku naszych danych i typu, kompilator może przetłumaczyć `user.power` na: _dostęp do 32-bitowej liczby całkowitej znajdującej się 64 bity od początku_. Na tym polega moc zmiennych, odwołują się one do pamięci i zawierają informacje o typie niezbędne do zrozumienia i manipulowania pamięcią w znaczący sposób.
 
 > Domyślnie Zig nie gwarantuje układu pamięci struktur. Może przechowywać pola w kolejności alfabetycznej, według rosnącego rozmiaru lub z przerwami. Może robić co chce, o ile jest w stanie poprawnie przetłumaczyć nasz kod. Ta swoboda może umożliwić pewne optymalizacje. Tylko jeśli zadeklarujemy `packed struct`, otrzymamy silne gwarancje dotyczące układu pamięci. Możemy również utworzyć `extern struct`, która gwarantuje, że układ pamięci będzie zgodny z binarnym interfejsem aplikacji C (ABI). Mimo to, nasza wizualizacja `user` jest rozsądna i użyteczna.
 

src/05-stack_memory.md

@@ -129,7 +129,7 @@ User 9114745905793990681 has power of 0
 
 Możesz uzyskać inne wyniki, ale na podstawie moich danych wyjściowych `user1` odziedziczył wartości `user2`, a wartości `user2` są bezsensowne. Kluczowym problemem w tym kodzie jest to, że `User.init` zwraca adres lokalnego użytkownika, `&user`. Nazywa się to zwisającym wskaźnikiem, wskaźnikiem, który odwołuje się do nieprawidłowej pamięci. Jest to źródło wielu naruszeń ochrony pamięci (segfaults).
 
-Gdy ramka stosu jest usuwana ze stosu wywołań, wszelkie odniesienia do tej pamięci są nieważne. Wynik próby uzyskania dostępu do tej pamięci jest niezdefiniowany. Prawdopodobnie otrzymasz bezsensowne dane lub segfault. Moglibyśmy spróbować wyciągnąć jakieś wnioski z moich danych wyjściowych, ale nie jest to zachowanie, na którym chcielibyśmy lub nawet moglibyśmy polegać.
+Gdy ramka stosu jest usuwana ze stosu wywołań, wszelkie referencje do tej pamięci są nieważne. Wynik próby uzyskania dostępu do tej pamięci jest niezdefiniowany. Prawdopodobnie otrzymasz bezsensowne dane lub segfault. Moglibyśmy spróbować wyciągnąć jakieś wnioski z moich danych wyjściowych, ale nie jest to zachowanie, na którym chcielibyśmy lub nawet moglibyśmy polegać.
 
 Jednym z wyzwań związanych z tego typu błędami jest to, że w językach z garbage collectorami powyższy kod jest całkowicie w porządku. Na przykład Go wykryłby, że lokalny `user` przeżyje swój zakres, funkcję `init` i zapewniłby jej ważność tak długo, jak jest to potrzebne (sposób, w jaki Go to robi, jest szczegółem implementacji, ale ma kilka opcji, w tym przeniesienie danych na stertę, o czym jest następna część).
 
@@ -142,7 +142,7 @@ fn read() !void {
 }
 ```
 
-Cokolwiek `Parser.parse` zwróci, przeżyje `input`. Jeśli `Parser` przechowuje odniesienie do `input`, będzie to zwisający wskaźnik, który tylko czeka na awarię naszej aplikacji. Idealnie, jeśli `Parser` potrzebuje `input` tak długo, jak to robi, utworzy ich kopię, a ta kopia będzie powiązana z jej własnym czasem życia (więcej na ten temat w następnej części). Nie ma tu jednak nic, co pozwoliłoby wyegzekwować ten kontrakt. Dokumentacja `Parser` może rzucić nieco światła na to, czego oczekuje od `input` lub co z nim robi. W przeciwnym razie będziemy musieli zagłębić się w kod, aby to rozgryźć.
+Cokolwiek `Parser.parse` zwróci, przeżyje `input`. Jeśli `Parser` przechowuje referencję do `input`, będzie to zwisający wskaźnik, który tylko czeka na awarię naszej aplikacji. Idealnie, jeśli `Parser` potrzebuje `input` tak długo, jak to robi, utworzy ich kopię, a ta kopia będzie powiązana z jej własnym czasem życia (więcej na ten temat w następnej części). Nie ma tu jednak nic, co pozwoliłoby wyegzekwować ten kontrakt. Dokumentacja `Parser` może rzucić nieco światła na to, czego oczekuje od `input` lub co z nim robi. W przeciwnym razie będziemy musieli zagłębić się w kod, aby to rozgryźć.
 
 ---
 

src/08-coding_in_zig.md

@@ -513,7 +513,7 @@ pub const add = @import("add.zig").add;
 test {
   // Domyślnie, tylko testy w określonym pliku
   // są uwzględniane. Ta magiczna linia kodu
-  // spowoduje, że odniesienie do wszystkich zagnieżdżonych kontenerów
+  // spowoduje, że referencja do wszystkich zagnieżdżonych kontenerów
   // do wszystkich zagnieżdżonych kontenerów.
     @import("std").testing.refAllDecls(@This());
 }