O cemu ti to ?
Pa imas dovoljno za tipova za vecinu stvari, jedino ako ti ne treba nesto specificno veliko. A za kastom tipove ti svakako treba vremena, + kako C je namenjen i za primene gde su ti resursi ograniceni pa onda svakako pravis ono sto ti zadovoljava potrebe i ono sto mozes da smestis u ram i rom.

Ovaj momak tek otkriva C i nema veze o čemu priča.

Recimo, ne zna da u C postoje 32 rezervisane reči, od kojih je 17 u vezi tipova podataka (više od pola jezika).
C je "mali" jezik. Učenje jezika je brzo. Tek kada se nauče osnove jezika, počinju da se uče biblioteke.
Uzgred, 99% učenja C je da naučiš kako da rukuješ pokazivačima.

mislim da se oko pokazivaca nepotrebno dize buka. Meni je konkretno poziv funkcija i scope promenljivih mnogo komplikovanija stvar.

^^ Znači da još nisi počeo da radiš sa pokazivačima. ^^



http://www.acodersjourney.com/2018/05/top-20-c-pointer-mistakes/

Poziv funkcija ?? scope promenljivih ????, ako ti pointeri nisu frka sto onda ovo napisa ?

ja kazem koji je meni koncept bio tezi.

Ne mogu jos uvek da sagledam u cemu je prava prednost pointer. Shvatio sam kako mogu da pristede memoriju kod dinamickog dodeljivanja lokacija i ucine kod elegantnim, npr liste stack... jedino da budem iskren ne nam koliko je to danas narocito potrebno. Ali to je vec posebna tema...

Ko smatra da zna dovoljno C, neka odgonetne zadatke sa datim kodom (bez gledanja rešenja) iz Programiranja 2 na ETF-u:
https://rti.etf.bg.ac.rs/rti/ir1p2/rokovi.html

dobro to je nivo 2 na ETF, necemo sad preterivati

dajte mi 3 razloga zasto da dobro procitam Understanding and using C pointers

Može 1?

Da bi naučio da radiš u C-u.

Ako se budeš bavio programiranjem na C/C++ jezicima, bićeš prinuđen da razumeš, modifikuješ i koristiš već gotov C/C++ kod, ili da izrađuješ kod koji je usaglašen sa ostatkom projekta.

Nepoznavanje funkcionisanja i primene pointera (npr. link koji ti je ostavio djoka_l) tada postaje veliki hednikep.

Naravno da imaš pravo na svoje mišljenje, ali mislim da si poranio sa ocenama o jeziku.

E sad, niko nije zaljubljen u pointere, takav je jezik.


Ovo može da ime veze upravio sa pointerima.

C je zamisljen kao jezik koji ce zameniti asembler da bi se mogao napisati operativni sistem Unix.
Sa te strane treba razumeti dizajn odluke u vezi jezika.

da, nekako oseca se u C taj neki low level.

evo sad bas kad radim pointere susreo sam se sa konceptom steka i heapa. Nazalost nisam bas nigde nasao lepo objasnjnje kako operativni sisitem dodeli C programu memoriju i koji deo C onda brine o dodeljivanju adresa ? Ili pak brine sam OS ??

zivim za dan kad cu naci lepo napisanu knjjigu, Evo ovaj o pointerima kaze hajmo prvo memoriju to je vazno, yaay, ali nema ni jedan dijagram. Da li ima neko neki link na neki lep yt koji objasnjava the stack and the heap u C ?

(inace nije mi jeasno kako sam dospeo ovde)

ahh ok, evo u drugom poglavlju

A C program executes within a runtime system. This is typically the environment provided
by an operating system. The runtime system supports the stack and heap along
with other program behavior.

idem sada da vidim sta je runtime system

Stek i heap su strukture podataka nevezano za OS. Stek je struktura gde se alokacija vrsi dodavanjem na kraj (raste u memoriji na dole uglavnom
ali ne mora), i oslobadja se brisanjem sa kraja samo tako sto se podesi stek pointer. Zgodan je za lokalne varijable zato sto svaki put
kada udjes u f-ju alocira se n bajtova koji se zovu frame, a svaki put kad izadjes iz f-je zadnji frame je upravo ono sto je alocirala
data f-ja pa se jednostavno oslobodi podesavanjem stek pointera.
Heap je struktura koja moze biti bilo kakva i koristi se za dinamicko alociranje memorije (malloc) koja se mora eksplicitno osloboditi
pozivom recimo f-je free. Kako ce to biti izvedeno zavisi od alokatora koji se koristi. Neoslobadjanje ovakve memorije ima za posledicu
tzv "memory leak".

edit: runtime sistem je biblioteka koja inicijalizuje sve potrebne strukture i poziva "main" f-ju kojoj prosledjuje sve potrebne parametre.
Znaci nije "main" ono sto OS poziva nego neku skrivenu f-ju iz libc-a, a ista poziva main.

Bez pointera nemas dinamicku memoriju. Gomila biblioteka ocekuju da im proslijedis nekakav kontekst ili handle koji je cesto pointer. Ako neces da koristis pointere, postavljas drasticna ogranicenja na arhitekturu aplikacije, npr. pointeri omogucavaju nivo indirekcije koji je cesto potreban da razdvojis slojeve u aplikaciji.

Npr. zamisli da imas strukturu Context koja sadrzi gomilu parametara (npr. CLI parametri isparsirani za lak pristup). Razlicite funkcije unutar programa moraju da rade drugacije u zavisnosti od proslijedjenih parametara koje je korisnik proslijedio. Ovo se uglavnom radi tako sto proslijedis pokazivac na konstantnu strukturu (const ctx*), tako da svaka funkcija moze da cita polja iz te strukture, a ne moze da ih mijenja (read only). Alternativa bi bila da kopiras komplet strukturu prilikom svakog pozivanja funkcije, sto je veoma neefikasno (sizeof(*ctx) vs sizeof(ctx)). Da ne spominjem tek slucaj ako zelis da funkcije mogu da mijenjaju dio ove strukture, bez pointera to ne mozes efikasno da uradis.

Na kraju, ako ne znas razliku izmedju sledece 3 linije, tesko da mozes da se zoves C programerom.

Upravo mi je pala na pamet analogija zasto su korisni pointeri.

Zamisli da trebas da das nekom psa da ga proseta. Kako ces to uraditi? Stavices mu povodac i daces povodac setacu. Mozes umesto toga i da odvedes psa u neki istrazivacki centar i da ga kloniraju pa da uzmes klona i pruzis ga ovom sto treba da ga seta. Ali.. Ipak ces koristiti povodac.

Runtime system ti je kod koji obicno dolazi ili od pisca operativnog sistema ili od pisca kompajlera.

Taj kod inicijalizuje tvoju aplikaciju, radi neke osnovne stvari koje su neophodne pre nego sto se uopste pozove main() i pruza interfejse za razne standardne C biblioteke (recimo kad pozoves printf(), to je funkcija implementirana u C runtime biblioteci).

Takodje, obicno runtime system se bavi i menadzmentom memorije u tvojoj aplikaciji - jako retko postoji potreba da direktno zoves operativni sistem da alociras memoriju (osim ako ne radis nesto vrlo specificno, recimo hoces da mapiras memoriju izmedju procesa ili ti treba jako veliko parce memorije sa specificnim osobinama npr. da mora da bude u fizickoj memoriji ne u swap-u i sl.). Takodje, C runtime biblioteka za tebe radi i menadzment malih alokacija memorije iz heap-a i stara se o tome da se memorija alocirana od OS-a optimalno koristi.

Zamisli "runtime system" kao sloj izmedju OS-a i tvoje aplikacije koji pruza API-je neophodne C programu da funkcionise.

Evo jednog izvanrednog tutorijala o pointerima u C-u:



Topla preporuka. Bez šale, čudo jedno koliko valja :)

Uzgred, u C-u zaista ima mnogo tipova, pogotovo ako se uračunaju i njihovi modifikatori; ali pravo bogatstvo ovog jezika su operatori!

Operatori se uglavnom lakše uče od pointera, pa čak neke ni ne moraš da koristiš "odmah", nego "kad ti dođe", mada ih većina C-početnica pobrojava sve kada naiđe lekcija o njima.

Operativni sistem ima API-je (funkcije) za alokaciju i dealokaciju memorije.

Medjutim, obicno, ti API-ji imaju ogranicenja, recimo memoriju alociraju u blokovima od, npr., 4 kilobajta i sl.

Tvoj C program koristi C runtime biblioteku koja pruza standardne C lib. funkcije malloc(), free() i sl. - kad ti pozoves malloc(), C runtime biblioteka ce da alocira memoriju od OS-a i tebi vrati adresu (pointer) na alocirani blok memorije.

Obicno su C runtime biblioteke pametnije, pa alociraju malo vece blokove memorije pa tebi daju delice tih blokova kako ne bi stalno zvale OS API-je koji su em skupi (u smislu da mora da se "zove" OS), em imaju ogranicenja tipa. da ti daju N*4K blokove. Zamisli situaciju da tvoj program 1000 puta zove malloc(100), kada u Windows-u svaki put zvao OS (VirtualAlloc) ti bi 1000 puta alocirao po 4 kilobajta umesto 100 bajtova. Zato C runtime biblioteka ima svoj menadzment memorije koji se stara o malim alokacijama.

Znaci prica obicno ide ovako:

Tvoj C program <-> C runtime biblioteka <-> Operativni sistem

hvala svima zadali ste mi mnogo domaceg, treba to sve iscitati sada. Onaj tutorial o pointerima procitao sam u dahu i saznao za koncept lvalue i rvalue.

Jos na pocetku rada sa pointerima zapitao sam se sledece.

int x=5

ko vodi racuna o adresi x ? Sad shvatam da je to runtime biblioteka. To znaci da ona pravi svoju tabelu opet nekih pointera gde kaze aha kad vidis x to je na adresi toj i toj.

Dakle OS kad se startuje c program odmah odredi deo memorijei kaze eto to ti je to sad se ti organizuj kako hoces na tom prostoru tvoja stvar, a sto se tice procesora to cu ti ja reci kad mozes da ga koristis kad ne kad ide prioritet.

Ma nisi shvatio.
Kada napišeš
int x=5;
kompajler ubaci naziv x u tabelu simbola. U zavisnosti da li je x lokalna promenljiva ili globalna promenljiva, tom se simbolu dodeljuje adresa od strane kompajlera.
Lokalne varijable se smeštaju na stek, pa kompajler u tom slučaju generiše mašinsku komandu

MOVE SP-4, 5

Uz pretpostavku da je SP sadržaj registra koji je stek pointer, a ofset varijable 4 bajta ispod vrha steka.
Moguće je da kompajler odluči da je zgodno da x drži u registru, na primer R03, pa generiše kod

MOVE R03, 5

Ili, da vrednost drži u RW delu memorije, recimo na adresi 1024000, pa onda ni ne generiše nikakvu mašinsku komandu, nego na adresu 1024000 upiše 5, a prilikom korišćenja varijable x piše ili čita sa adrese 1024000.

Dakle, deklaracija i incijalizacija varijable se ne dešavaju od strane runtime biblioteka (obično) nego se kod generiše u proceu kompajliranja.

malo sam istrazivao...

taj stack pointer ima veze sa konceptom scope tipova zar ne ? Kako sam raumeo main kad pozove funkciju fun1 onda se njene promenljive stavljaju na vrh steka, a kad se vrati u main SP se vraca na main, a fun1 ostaje iznad pointer tj ide u garbage i tako lokalne promenljive iz fun1 nisu vise dostupne main-u D/N ?

a ti kazes da kompajler odredjuje adrese prmenljvih. meni to ne zvuci logicno. Zar se to ne desava tokom runtime jer tek onda zapravo nas kod kontaktira OS i moli dodelu prstora koga ce on onda izdeliti na svoj stack, heap itd....

???

Stek i scope (opseg) nemaju veze jedan sa drugim.
Stek je struktura podataka a opseg je logički koncept koji kaže kakva je vidljivost simboličkih naziva unutar programa.

Evo primera:


U programu je deklarisana varijabla "i" čija je vidljivost cela funkcija main. Međutim, za for petlju je ponovo deklarisana varijabla "i", pa zbog načina na koji C obrađuje scope, "maskira" varijablu "i" iz main funkcije.

Možeš da zamisliš da je "i" iz main funkcije neko "i1", a "i" iz for petlje neko "i2". Kompajler, kada analizira kod, nema problema sa ovim načinom deklarisanja varijabli.
A to, da li je "i" u petlji na steku, u registru ili negde u memoriji, nema veze sa tim koja je njena vidljivost.

ne nisam mislio na petlju for, npr:



promenljiva vfun3 nece biti dotupna u fun2 jer ce SP pokazivati na nju samo dok se izvrsava fun3, a kad se SP pomeri na fun2 sve vezano za fun3 postaje garbage,,,

bar tako sam razumeo objasnjenje. Znam ja sta je stek LIFO itd...

Sta ti je to SP? Ako si mislio na Stack Pointer onda si u velikoj zabludi. Alokacija za lokalne varijable jedne f-je se vrsi napocetku obicno za sve lokalne varijable bez obzira na scope.
SP pokazuje na vrh steka bez obzira kojoj varijabli pristupas. Scope je cisto stvar kompajlera.

da, SP mi je (i ne samo meni) je pokazivac na stek, a to je vrh steka.

upis na stek SP++ i upis,
skidanje sa steka SP-- uz ostavljanje bivseg vrha kao garbage

govorim o assembleru valda tako komunicira kompajlirani C kod sa runtime ?

SP se oduzme za alokaciju (stek raste na dole) i to na pocetku f-je. Dealoakcija se na kraju izvrsi ili vracanjem sacuvane prethodne vrednosti ili sabiranjem na kraju f-je. Izgenerisi asembler pa onda pricaj, nemoj napamet.

vidi, u kontekstu ovoga o cemu pricamo sasvim je nebitno da li stek raste na gor ili na dole.

Kao što ti ja Branko već napisao, to nema veze sa stekom. Kompajler je onaj koji određuje scope. To što fun2 ne vidi vfun3 je zato što kompajler ne dozvoljava da je vidi, a ne zato što je na steku. I nemoj da pridaješ magične osobine runtime okruženju. Kompajler generiše MAŠINSKI kod. Možeš da napraviš takav program da ne poziva NI JEDNU runtime funkciju. Ali ipak radi. Alokacija prostora na steku nije usluga runtime biblioteke, to radi generisani kod od strane kompajlera. Samo što kompajler pokušava da te spase od tvojih brljotina. Ako si ipak čuo za problem buffer overrun, to je kad tvoj program počne da divlja i da dohvata i menja podatke koje ne bi trebao da menja. Obično zato što ne kontroliše indekse nizova.

U kontekstu onoga o cemu pricamo netacno si izneo kako stvari rade...

@Whitewater,

Kompajleri imaju korisnu opciju da generisu i citljivi asemblerski kod (.asm fajlove). Ova opcija moze biti vrlo korisna ako tek ucis low-level C programiranje i sa njom ce ti biti mnogo jasnije sta se tacno desava tj. za koje stvari je zaduzen kompajler (tj. generisani masinski kod) a za koje stvari je zaduzena C runtime biblioteka.

Evo ti primer C koda:



A evo kakav je asemblerski kod generisao Microsoftov C kompajler:



Kao sto vidis, scope nema veze sa tim gde kompajler alocira memoriju za promenljive.

ovo je bio klizeci start