C kód, funkciók sorrendje. ?

Ez fordítótól is függ.

Ha nem deklarálod a függvényeidet, akkor csak a hívást tartalmazó sor pozíciója előtt lehetnek, ha deklarálod őket, akkor lehetnek bárhol.

Egy mezitlábas fordító honnan tudja, hogy mit hívjon mondjuk a 24. sorban, ha nem dolgozta fel előtte?

Szabvány szerint static esetén a fájl elején, nem static függvény esetén pedig egy header fájlban deklarálni kell a függvényt használat előtt.

Ez 25 éve is feltétel kellett hogy legyen, legfelljebb a fordító "megjavította"/megkereste így is, de attól az még nem volt szabályos kód.

Alapban az a sorrend kell, amit a kolléga is említ.

Ha a függvény, amire a 24. sorban hivatkozol, a forrásban csak a 40. sor után következik, akkor a szimplább fordító nem tud mit kezdeni a helyzettel.

Az okosabb fordító ilyen esetben azt csinálja, hogy a hívás helyén a hívott függvény neve helyett oda kerülő memóriacímet (mivel név helyett úgyis csak egy cím lesz ott) üresen hagyja és a forrás feldolgozásának végén a később megtalált függvény címét utólag írja be. Ha nem találja a függvényt, amire hivatkozás történt, akkor meg hibaüzenetet küld.

De ez nem kötelező kör, tehát akadhat fordító, ami nem tud ilyet, vagy akadhat olyan is, ami csak akkor hajlandó ezt meglépni, ha (vmilyen paraméterrel) utasítást kap erre.

Ha nem deklarálod előre a függvényeidet, akkor a compiler nem tudja előre, hogy milyen a függvényed szignatúrája. A szignatúrát viszont a hívó oldalon is ki tudja találni, megnézi, hogy milyen típusú változókat adsz át neki, és ez szerint fogja legenerálni azt az assembly-t vagy gépi kódot, ami a hívást végrehajtja.

A probléma akkor van, hogyha a függvényednek végső soron más a szignatúrája, mint ahogy hívtad.

Nézd meg ezt: [link]

Itt látszik, hogy a main-ben legenerált assembly csak két paramétert ad át(esi és edi regisztereken keresztül) a

multiply függvénynek. Viszont a multiply ha megnézed, kiolvassa az edx-et is, hisz azt hiszi, hogy ott van a harmadik paramétere.

Az, hogy mi van az edx-ben, az undefined(most ebben a példában az értéke konkrétan a második paraméter értékével azonos, de ez csak esetleges)

Ezért warning az implicit declaration.

Ellenben ha a függvényedet előre deklarálod ( [link] akkor a fordító a hívás helyén már tudni fogja, hogy mi a függvény helyes szignatúrája, így el tud szállni egy errorral.

Én azt ajánlom, hogy ha írsz egy modult:

a) A publikus függvények deklarációját tedd be valami my_module.h-ba, ezt include-old mindenhol, ahol használod a modulodat

b) Amiket nem akarsz kívülről hívni, azoknak a deklarációját tedd be egy my_module_internal.h-ba. Itt includeold a my_module.h-t

c) A module.c-ben pedig include-old a my_module_internal.h-t.

Így mindenki azt látja, amire szüksége van, nem lesz implicit deklaráció, a compiler pedig fog tudni szólni, ha elbaszod.

#4 > Ez 25 éve is feltétel kellett hogy legyen

Nem volt az. Ha felcsapod a c99 standard doksit( [link] akkor a "Foreword"-ben láthatod, hogy az 5. pontban van egy lista a nagyobb változtatásokról az előző standardhoz képest. Itt találod azt, hogy "Remove implicit function declaration".

25 évvel ezelőtt 1997 volt, akkor ez a doksi még nem létezett, a c89/ansi c volt a legfrissebb c szabvány.

"hisz azt hiszi, hogy ott van a harmadik paramétere."

Bocs, de ezzel hülyeséget állítasz.

Éppen a nyegle, lazán megtervezett C nyelv az, ahol a paraméterek száma eltérhet a deklarációban foglaltaktól, tehát, három paraméter helyett csak kettőt, vagy akár egyet használva is lefordítja a forrást a fordító, ha a paraméter amúgy hiányolható a függvényben.

Bizonyos esetekben még akkor is, ha nem hiányolható, de ez már nagyon mellékvonal.

#8

Félre értetted, amit írtam. Pont ez a probléma, hogy lefordítja(ahogy a példában is látható, amit linkeltem). A gcc "csak" warningot dob, még akkor is, ha expliciten megmondod neki, hogy -std=c99

Ok, így rendben van. Mea culpa.

Egyébként, nem értettem félre, csak addig olvastam, amit idéztem, tovább már nem.