Odpowiedź.

Historia pytania:

W C++ praca z pamięcią jest fundamentalna, język daje programiście pełną kontrolę dla efektywności. Na początku istniały jedynie pojęcia „stos” (stack) i „sterta” (heap) jako obszary dynamicznej i automatycznej alokacji pamięci.

Problem:

Wybór obszaru lokalizacji zmiennej określa długość jej życia, dostępność, szybkość alokacji i zwalniania pamięci, a także ryzyka (wycieki, uszkodzenia stosu, fragmentacja).

Rozwiązanie:

Alokacja na stosie jest używana do zmiennych lokalnych o znanym czasie życia. Alokacja na stercie — dla obiektów, które potrzebują dynamicznego czasu życia lub dużych ilości pamięci. Zaleca się minimalizowanie ręcznego zarządzania stertą, preferując stos i korzystać z inteligentnych wskaźników do pracy z dynamiką.

Przykład kodu:

// Alokacja na stosie
int a = 5;

// Alokacja na stercie
int* b = new int(10);

// Praca z inteligentnym wskaźnikiem
#include <memory>
auto ptr = std::make_unique<int>(15);

Kluczowe cechy:

• Stos: szybki, automatyczny, ograniczony rozmiar, zasięg — funkcja.
• Sterta: dynamiczny, wymaga jawnego zwolnienia (lub inteligentnych wskaźników), duże objętości, elastyczny czas życia.
• Mieszanie może prowadzić do błędów i wycieków.

Pytania z podwójnym dnem.

Co się stanie, jeśli zwrócisz wskaźnik do zmiennej lokalnej z funkcji?

Nastąpi undefined behavior: po wyjściu z funkcji pamięć „zwalnia się” (w rzeczywistości stos nie jest czyszczony, ale dane mogą być nadpisane).

Przykład złego kodu:

int* foo() {
    int a = 42;
    return &a; // niepoprawne!
}

Czy pamięć alokowana na stosie może się wyciekać?

Nie, pamięć stosu zawsze zwalnia się automatycznie po wyjściu z zasięgu — powstaje tylko tak zwane przepełnienie stosu (stack overflow), ale nie wyciek.

Czy zawsze wystarczy używać delete do zwalniania pamięci dynamicznej?

Nie, znacznie częściej używa się inteligentnych wskaźników (std::unique_ptr, std::shared_ptr), aby uniknąć zapomnianych delete i podwójnego usuwania.

Typowe błędy i antywzorce

• Zwracanie wskaźnika/odniesienia do zmiennych lokalnych.
• Używanie raw new/delete bez kontroli.
• Niedocenianie ograniczenia rozmiaru stosu (rekursja bez końca — stack overflow).

Przykład z życia

Negatywny przypadek:

Programista użył new dla wszystkich obiektów tymczasowych, zapominał je zwolnić — z czasem w dużych aplikacjach pojawiły się wycieki pamięci.

Plusy: na początku szybko i wygodnie Minusy: niestabilne programy, wzrost pamięci, awarie

Pozytywny przypadek:

Użycie zmiennych lokalnych i inteligentnych wskaźników dla obiektów tymczasowych i pomocniczych. Brak jawnego delete, wszystko zwalnia się automatycznie.

Plusy: brak wycieków, niezawodność Minusy: wymaga zrozumienia nowoczesnych podejść do pracy z pamięcią