Odpowiedź.

W języku Rust zarządzanie pamięcią tradycyjnie uważano za jeden z najtrudniejszych problemów w niskopoziomowym programowaniu. Przed pojawieniem się Rust wiele języków wymagało ręcznego zarządzania pamięcią (jak C/C++), co prowadziło do wycieków i uszkodzenia danych. Rust podszedł do problemu z innej strony — kolekcje takie jak Vec<T> wykorzystują automatyczną i bezpieczną strategię zarządzania pamięcią, kontrolując momenty alokacji, realokacji (zmiany rozmiaru) i zwalniania pamięci za pomocą systemu własności i pożyczek.

Problem polegał na tym, że większość języków albo zbyt abstrahuje szczegóły alokatora (GC), albo czyni programistę odpowiedzialnym za wszystko (malloc/free). W przypadku dynamicznych tablic niezwykle ważne jest, aby śledzić wycieki i przekroczenia granic tablicy, a także nie naruszać własności.

Rozwiązanie w Rust — automatyzacja przez bezpieczne abstrakcje. Vec<T> alokuje pamięć na stercie, dynamicznie zwiększa rozmiar (zazwyczaj ze wzrostem wykładniczym), i zwalnia wszystko przy wyjściu z zakresu widoczności (RAII).

Przykład kodu:

fn main() {
    let mut v: Vec<i32> = Vec::new();
    v.push(1);
    v.push(2);
    v.push(3);
    // Dodanie powoduje zwiększenie rozmiaru i realokację pamięci
    println!("Vector: {:?}", v);
    // Przy wyjściu z main pamięć jest zwalniana automatycznie
}

Kluczowe cechy:

Vec<T> alokuje pamięć z wyprzedzeniem i realokuje ją w razie potrzeby
Automatyczne zarządzanie czasem życia przez własność i RAII
Bezpieczeństwo pracy z pamięcią: nie można uzyskać dostępu do usuniętego lub niezinicjalizowanego obszaru, błędy są przechwytywane na etapie kompilacji

Pytania z pułapką.

Jaka jest złożoność wzrostu tablicy przy dodawaniu elementów do Vec?

Zwykle złożoność push amortyzowana to O(1), jednak kiedy tablica się przepełnia, alokowany jest nowy obszar pamięci (rozmiar jest mniej więcej podwajany), a wszystkie elementy są kopiowane. Ten moment to jedyne wyjątek, kiedy operacja staje się O(n).

Co się stanie, gdy spróbujesz uzyskać element poza zakresem przez v[index]?

Użycie nawiasów kwadratowych prowadzi do paniki przy przekroczeniu granicy. Należy użyć metody .get(), która zwraca Option i pozwala bezpiecznie obsłużyć błąd.

let element = v.get(10); // None, jeśli indeks nie istnieje

Czy można używać odniesienia do elementu Vec po możliwej zmianie rozmiaru (resize) wektora?

Nie, po zmianie rozmiaru wektora (np. poprzez push przy przepełnieniu) cała pamięć może zostać przeniesiona, a stare odniesienia stają się nieważne — występuje błąd kompilacji (lub undefined behavior w bloku unsafe, jeśli używasz ich ręcznie).

Typowe błędy i antywzorce

Utrzymywanie odniesień do elementów po potencjalnym rozszerzeniu wektora.
Próba ręcznego zwolnienia lub klonowania pamięci Vec.
Używanie indeksów bez sprawdzania granic.

Przykład z życia

Negatywny przypadek

Programista realizuje cache wiadomości oparty na Vec<T> i zwraca na zewnątrz odniesienia do elementów. Po nowym wstawieniu następuje realokacja pamięci, a wszystkie istniejące odniesienia stają się "wiszące". I następuje awaria aplikacji.

Zalety:

Wysoka wydajność w przypadku, gdy cache jest stabilny

Wady:

Trudne do zidentyfikowania błędy przy wzroście i aktualizacji kolekcji
Możliwe awarie w czasie wykonywania

Pozytywny przypadek

Używa się albo wewnętrznej identyfikacji elementów (indeksy/klucze + sprawdzenie ważności), albo zwraca się tylko kopie/immutable wartości, nie dopuszcza się przechowywania długotrwałych odniesień do elementów Vec.