Stack, Static i Heap w C++

Poniższe nie są oczywiście do końca precyzyjne. Weź to z przymrużeniem oka jak to przeczytasz:)

Cóż, trzy rzeczy, o których mówisz to automatyczny, statyczny i dynamiczny czas przechowywania , który ma coś wspólnego z tym, jak długo obiekty żyją i kiedy zaczynają życie.

Automatyczny czas przechowywania

Używasz automatycznego czasu przechowywania dla krótkotrwałych i małych danych, które są potrzebne tylko lokalnie w niektórych blok:

if(some condition) {
    int a[3]; // array a has automatic storage duration
    fill_it(a);
    print_it(a);
}

Życie kończy się, gdy tylko opuścimy blok, i rozpoczyna się, gdy tylko obiekt zostanie zdefiniowany. Są one najprostszym rodzajem czasu przechowywania i są znacznie szybsze niż w szczególności dynamiczny czas przechowywania.

Statyczny czas przechowywania

Używasz statycznego czasu przechowywania dla zmiennych wolnych, które mogą być dostępne przez dowolny kod przez cały czas, jeśli ich zakres pozwala na takie użycie (zakres przestrzeni nazw), oraz dla zmiennych lokalnych, które wymagają rozszerzenia ich czas życia w trakcie zakończenia ich zakresu (zakres lokalny) oraz dla zmiennych członkowskich, które muszą być współdzielone przez wszystkie obiekty ich klasy (zakres klas). Ich żywotność zależy od zakresu, w jakim się znajdują. Mogą mieć zakres przestrzeni nazw i Zakres lokalny oraz Zakres klasy. Co jest prawdą o obu z nich jest, gdy ich życie zaczyna, życie kończy się na koniec programu . Oto dwa przykłady:

// static storage duration. in global namespace scope
string globalA; 
int main() {
    foo();
    foo();
}

void foo() {
    // static storage duration. in local scope
    static string localA;
    localA += "ab"
    cout << localA;
}

Program drukuje ababab, ponieważ localA nie jest zniszczony po wyjściu z bloku. Można powiedzieć, że obiekty o zasięgu lokalnym rozpoczynają życie , gdy kontrola osiągnie swoją definicję . Dla localA, dzieje się, gdy ciało funkcji jest wprowadzane. W przypadku obiektów z zakresu przestrzeni nazw okres życia zaczyna się od uruchomienia programu . To samo dotyczy obiektów statycznych klasy scope:

class A {
    static string classScopeA;
};

string A::classScopeA;

A a, b; &a.classScopeA == &b.classScopeA == &A::classScopeA;

Jak widzisz, classScopeA nie jest związana z konkretnymi obiektami swojej klasy, ale z samą klasą. Adres wszystkich trzech nazwisk powyżej jest taki sam, i wszystkie oznaczają ten sam obiekt. Istnieją specjalne reguły dotyczące czasu i sposobu inicjalizacji obiektów statycznych, ale nie przejmujmy się tym teraz. Oznacza to termin statyczny porządek inicjalizacji .

Dynamiczny czas przechowywania

Ostatni czas przechowywania jest dynamiczny. Używasz go, jeśli chcesz, aby obiekty mieszkały na innej wyspie i chcesz umieścić wskaźniki wokół nich. Używasz ich również, jeśli twoje obiekty są Duże , a jeśli chcesz utworzyć tablice o rozmiarze znanym tylko w czasie działania . Ze względu na tę elastyczność, obiekty o dynamicznym czasie przechowywania są skomplikowane i wolne w zarządzaniu. Obiekty o tak dynamicznym czasie trwania rozpoczynają życie, gdy zachodzi odpowiednie wywołanie nowego operatora:

int main() {
    // the object that s points to has dynamic storage 
    // duration
    string *s = new string;
    // pass a pointer pointing to the object around. 
    // the object itself isn't touched
    foo(s);
    delete s;
}

void foo(string *s) {
    cout << s->size();
}

Jego żywotność kończy się tylko wtedy, gdy zadzwonisz Usuń dla nich. Jeśli o tym zapomnisz, te przedmioty Nigdy nie kończą życia. I Obiekty klasy, które definiują konstruktor zadeklarowany przez użytkownika nie będą miały dzwonili ich Niszczyciele. Obiekty o dynamicznym czasie przechowywania wymagają ręcznej obsługi ich żywotności i powiązanych zasobów pamięci. Biblioteki istnieją po to, aby ułatwić korzystanie z nich. jawny zbiór śmieci dla poszczególnych obiektów można ustalić za pomocą inteligentnego wskaźnika:

int main() {
    shared_ptr<string> s(new string);
    foo(s);
}

void foo(shared_ptr<string> s) {
    cout << s->size();
}

Nie musisz przejmować się wywołaniem delete: współdzielony PST robi to za Ciebie, jeśli ostatni wskaźnik odwołujący się do obiektu wyjdzie poza zakres. Sam współdzielony PST posiada automatyczne czas przechowywania. Tak więc czas życia jest automatycznie zarządzany, pozwalając mu sprawdzić, czy powinien usunąć wskazywany na dynamiczny obiekt w swoim destruktorze. Aby uzyskać odniesienie shared_ptr, Zobacz dokumenty boost: http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr.htm

Zostało powiedziane dokładnie, tak jak "krótka odpowiedź":

• Zmienna statyczna (Klasa)
  lifetime = program runtime (1)
  widoczność = określana przez modyfikatory dostępu (prywatne/chronione/publiczne)

• Zmienna statyczna (zakres globalny)
  lifetime = program runtime (1)
  visibility = Jednostka kompilacji, w której jest utworzona(2)

• Zmienna sterty
  lifetime = defined by you (new to delete)
  widoczność = zdefiniowana przez Ciebie (niezależnie od tego, do czego przypisujesz wskaźnik)

• Zmienna stosu
  visibility = from declaration until scope is exited
  lifetime = from declaration until declaring scope is exited

(1) dokĹ ' adniej: od inicjalizacji do deinicjalizacji jednostki kompilacji (tj. pliku C / C++). Kolejność inicjalizacji jednostek kompilacji nie jest określona przez standard.

(2) Strzeż się: jeśli tworzy instancję zmiennej statycznej w nagłówku, a każda jednostka kompilacji otrzymuje własną kopię.

Jestem pewien, że jeden z pedantów wkrótce znajdzie lepszą odpowiedź, ale główną różnicą jest szybkość i rozmiar.

Stack

Znacznie szybszy przydział. Odbywa się to w O(1), ponieważ jest alokowany podczas ustawiania ramki stosu, więc jest zasadniczo wolny. Wadą jest to, że jeśli zabraknie miejsca na stosie jesteś kości. Możesz dostosować rozmiar stosu, ale IIRC masz ~2MB do zabawy. Ponadto, gdy tylko zakończysz funkcję, wszystko na stosie zostanie wyczyszczone. Więc to może być problematyczne, aby odnieść się do niego później. (Wskaźniki stosu przydzielonych obiektów prowadzą do błędów.)

Heap

Drastycznie wolniejszy przydział. Ale masz GB do zabawy i wskaż.

Garbage Collector

Garbage collector to jakiś kod, który działa w tle i zwalnia pamięć. Kiedy przydzielasz pamięć na stercie, bardzo łatwo jest zapomnieć o jej zwolnieniu, co jest znane jako wyciek pamięci. Z biegiem czasu pamięć zużywana przez aplikację rośnie i rośnie, aż rozbija się. Okresowe uwalnianie pamięci, której już nie potrzebujesz, pomaga wyeliminować tę klasę błędów. Oczywiście ma to swoją cenę, ponieważ Śmieciarz spowalnia wszystko.

Jakie są problemy statyczne i stack?

Problem z alokacją "statyczną" polega na tym, że alokacja jest dokonywana w czasie kompilacji: nie można jej użyć do przydzielenia jakiejś zmiennej liczby danych, której liczba nie jest znana do czasu uruchomienia.

Problem z alokacją na "stosie" polega na tym, że alokacja jest niszczona, gdy tylko powróci podprogram, który dokonuje alokacji.

Mógłbym napisać całą aplikację bez przydzielania zmienne w stercie?

Być może, ale nie nietrywialna, normalna, duża aplikacja (ale tak zwane "wbudowane" programy mogą być pisane bez sterty, używając podzbioru C++).

Co robi garbage collector ?

Obserwuje Twoje dane ("Oznacz i zamiataj"), aby wykryć, kiedy aplikacja nie odwołuje się już do nich. Jest to wygodne dla aplikacji, ponieważ aplikacja nie musi dealokować danych ... ale Śmieciarz może być kosztowne obliczeniowo.

Co mógłbyś zrobić samemu manipulując pamięcią, czego nie mógłbyś zrobić używając tego śmieciarza?

Poznaj mechanizmy deterministycznej dealokacji pamięci C++:

• 'static': never deallocated
• 'stos': gdy tylko zmienna "wyjdzie poza zakres"
• 'sterta' : gdy wskaźnik zostanie usunięty (jawnie usunięty przez w tym celu należy skontaktować się z inspektorem ochrony danych.]}

Alokacja pamięci stosu (zmienne funkcyjne, zmienne lokalne) może być problematyczna, gdy stos jest zbyt "głęboki" i przepełnia się pamięć dostępną do alokacji stosu. Sterta jest przeznaczona dla obiektów, które muszą być dostępne z wielu wątków lub przez cały cykl życia programu. Możesz napisać cały program bez użycia sterty.

Można łatwo wyciekać pamięć bez garbage collector, ale można również dyktować, kiedy przedmioty i pamięć są uwalniane. Wbiegłem do problemy z Javą podczas uruchamiania GC i mam proces w czasie rzeczywistym, ponieważ GC jest wyłącznym wątkiem (nic innego nie może działać). Więc jeśli wydajność jest krytyczna i możesz zagwarantować, że nie ma wycieków obiektów, nie używanie GC jest bardzo pomocne. W przeciwnym razie po prostu nienawidzisz życia, gdy aplikacja zużywa pamięć i musisz znaleźć źródło przecieku.

Co jeśli twój program nie wie z góry ile pamięci ma przeznaczyć (stąd nie możesz użyć zmiennych stosu). Powiedzmy, że listy połączone, listy mogą rosnąć, nie wiedząc z góry, jaka jest ich wielkość. Tak więc przydzielanie na stertę ma sens dla połączonej listy, gdy nie wiesz, ile elementów zostanie do niej wstawionych.

Zaletą GC w niektórych sytuacjach jest irytacja w innych; poleganie na GC zachęca do nie myślenia o tym zbyt wiele. Teoretycznie czeka do "bezczynnego" okresu lub do momentu, w którym absolutnie musi, kiedy ukradnie przepustowość i spowoduje opóźnienie odpowiedzi w aplikacji.

Ale nie musisz o tym nie myśleć."Tak jak Wszystko inne w aplikacjach wielowątkowych, kiedy można ustąpić, można ustąpić. Tak więc na przykład w. Net można zażądać GC; robiąc to, zamiast rzadsze dłuższe uruchamianie GC, możesz mieć częstsze krótsze uruchamianie GC i rozłożyć opóźnienia związane z tym obciążeniem.

Ale to pokonuje główną atrakcję GC, która wydaje się być " zachęcana, aby nie myśleć o tym wiele, ponieważ jest to auto-mat-ic."

Jeśli po raz pierwszy zetknąłeś się z programowaniem, zanim GC stało się powszechne i czułeś się komfortowo z malloc / free i new / delete, to może nawet okazać się, że GC jest trochę irytujące i / lub są nieufne(jak można być nieufnym "optymalizacji", która miała sprawdzoną historię.) Wiele aplikacji toleruje losowe opóźnienia. Ale w przypadku aplikacji, które tego nie robią, gdzie losowe opóźnienia są mniej akceptowalne, powszechną reakcją jest unikanie środowisk GC i poruszanie się w kierunku czysto niezarządzanego kodu (lub broń Boże, dawno umierająca sztuka, język asemblacji.)

Jakiś czas temu miałem tu letniego studenta, stażystę, mądrego dzieciaka, który został odstawiony na GC; był tak zachwycony wyższością GC że nawet przy programowaniu w niezarządzanym C / C++ odmówił podążania za modelem malloc / free new / delete, ponieważ, cytuję, " nie powinieneś tego robić w nowoczesnym języku programowania."I wiesz? W przypadku małych, krótkich aplikacji można rzeczywiście ujść na sucho, ale nie w przypadku długotrwałych aplikacji wydajnych.

Stos jest pamięcią przydzieloną przez kompilator, kiedy kiedykolwiek kompilujemy program, w domyślnym kompilatorze przydziela trochę pamięci z systemu operacyjnego (Możemy zmienić ustawienia z ustawień kompilatora w IDE) i OS jest Tym, który daje pamięć, jego zależy od wielu dostępnych pamięci w systemie i wiele innych rzeczy, i przychodząc do pamięci stosu jest przydzielać, gdy deklarujemy zmienną kopiują (ref jako formals) te zmienne są pchane do stosu postępują niektóre konwencje nazewnictwa domyślnie its CDECL w Visual studios ex: notacja infiksowa: c=A + b; pchanie stosu odbywa się od prawej do lewej, pchanie b do stosu, operator, a do stosu i wynik tych i, e c do stosu. W notacji Pre fix: = + cab Tutaj wszystkie zmienne są wypychane do stosu 1st (od prawej do lewej), a następnie wykonywana jest operacja. Pamięć przydzielona przez kompilator jest stała. Załóżmy więc, że 1MB pamięci jest przypisane do naszej aplikacji, powiedzmy, że zmienne używane 700kb pamięci (wszystkie zmienne lokalne są wypychane do stosu, chyba że sÄ ... przydzielane dynamicznie) wiÄ ™ c pozostaĹ ' e 324kb pamiÄ ™ ci jest przydzielane do sterty. I ten stos ma mniej czasu życia, gdy zakres funkcji kończy te stosy zostanie wyczyszczone.