Tablica statyczna, przyczyna określenia rozmiaru

2

@mpaw powiem, ci że my też tego do końca nie wiemy, to trudne trochę jest.
Heap program sobie dostaje stronę pamięci od systemu, i malloc, heap allocator mają swój algorytm rozporządzania danych na tej stronie.

A na stosie nie masz takich dynamicznych menadżerów pamięci jak malloc i tam lepiej jak statycznie wszystko jest, lub jak jesteś reverse enignnerem to możesz czasem przewidzieć kompilację i zmusić program do działąnia dla ciebie, ale to nie będzie przenośnę i jest obardzone unefinded behavior.

7

Wydajność: dużo łatwiej takie tablice trzymać przy innych danych, zmniejszając liczbę skoków do L2/L3/RAM-u, które są kosztowne i konieczne jeśli masz wskaźniki. Tablice o znanej wielkości możesz też łatwo wpakować na stos lub do binarki.

4

Wszystko się sprowadza do kompromisu pomiędzy tym ile wolności daje się programiście, zabierając mu komfort. Tworząc tablicę w wyżejpoziomowych językach nie musisz się tym martwić, ale też nie możesz zmienić implementacji takiej tablicy/kolekcji pod spodem (np w PHP tablica jest pod spodem zawsze zaimplementowana jako hashmapa z kluczami string|int zachowująca kolejność, i nie można stworzyć swojej implementacji polegając na swoich bajtach, tak jak się da np w C).

Mając dostęp do tak niskopoziomowego rozwiązania, nie musisz polegać na persystencji wybranej przez kompilator/język/runtime/biblioteki. Cenę jaką płacisz, jest oczywiście to że sam musisz to napisać i utrzymać.

3
mpaw napisał(a):

Moje pytanie dotyczyło tego, po co w ogóle są tablice statyczne. Jakie były przyczyny tego, że zdecydowano się na alokację statyczną i dynamiczną. Jakby nie można było wszystkiego zrobić dynamicznie. A jeżeli jednak nie jaka jest tego techniczna przyczyna :)

Statyczna ma szczególnie prosta implementację w języku maszynowym. A wręcz brak implementacji, rzecz się dzieje podczas ładowania programu, przed przekazaniem pierwszego JMP do kodu.
I jedyną dostępną w C inicjacją inną niż zerową (w C++ są opcjonalne konstruktory, czyli kod)

masz dobrą intuicję, nie jest to konieczne. Wiele nowszych języków nie ma tego wynalazku,. i nie ma z tego jakiegoś cierpienia.

Jest wręcz na odwrót: wielość modeli pamięci w C to duży problem.
Jakby wiedzieć na 100%,w C "acha, ten blok pamięci był alokowany dynamicznie, więc zrobię mu free", wiele rzeczy by się uprościło.

To nawet nie jest tak, ze GC w Javie czy C# to wielkie lekarstwo. Bo rodzaj C, czy C++, w którym by była gwarancja "każdy obszar pamięci nie ma innego pochodzenia niż dynamiczne", świat byłby prostszy. Nawet z free() / delete

Żegnaj o pamięci statyczna, nie będzie nam ciebie brakowało [^]
:(

1

Pamięć statyczna to iluzja. Przed załadowaniem system operacyjny robi alokacje dynamiczną, czyli musi znaleźć wolne miejsce w RAM i zarezerwować ja dla procesu, którego kod i dane zostaną następnie wczytane z pliku exe/elf. OS odpowiada za alokację i zwolnienie tej pamięci i robi to dynamicznie. Z perspektywy procesu ona jest statyczna i nie musi się on martwić o jej zarządzanie. Na wstępie proces dostaje w prezencie ileś tam stron RAMu, która powinna mu wystarczyć. Jak chce więcej to musi później o nią poprosić (malloc, calloc, new, etc.) i oddać kiedy jej nie potrzebuje (free, delete).

1 użytkowników online, w tym zalogowanych: 0, gości: 1