Weboldalunk cookie-kat használhat, hogy megjegyezze a belépési adatokat, egyedi beállításokat, továbbá statisztikai célokra és hogy a személyes érdeklődéshez igazítsa hirdetéseit. További információ
Kezdőoldal » Számítástechnika » Programozás » C kód, funkciók sorrendje. ?

C kód, funkciók sorrendje. ?

Figyelt kérdés

Még nagyon régen (25+ éve) tanulgattam C-ben programozni, azt az élet úgy hozta hogy nem foglalkoztam vele tovább.. Mostanában néha gyakorolgatom szabad időmben, és van egy dolog amit nem letem a neten, és nem értem?


Régen, a funkciók sorrendje mindegy volt, tehát ha a main-ban hívtam meg valamit ami a main után volt lefordult

Ma ez nem történik meg, ezt elfogadtam, figyelek a sorrendre.. De most a githubról kellett egy kód ami egy az egyben jó nekem, és meglepődtem, nem fordult le.. Szépen átrendeztem a funkciókat, és lefordult..


Tehát a kérdésem: Mitől függ hogy pl ez

[link]


a fejlesztő gépén jó, nálam a void setup () elé át kellett helyezni mindent ami a void loop () után van. (és itt is kellett 1-2 dolgot felcserélni de az már mindegy)


Szóval mitől függ hogy ezt a sorrendet be kell e tartani vagy sem ?


nov. 24. 16:01
 1/10 anonim ***** válasza:

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?

nov. 24. 16:30
Hasznos számodra ez a válasz?
 2/10 anonim ***** válasza:
16%
Az a tradícionális sorrend, hogy legfelül van a deklarációs rész, alatta a függvények és legalul a main.
nov. 24. 16:32
Hasznos számodra ez a válasz?
 3/10 A kérdező kommentje:

1: értem, illetve logikus is, egy sima bash script is ilyen.. Ott egyértelmű hogy soronként kell hogy feldolgozza..

Ellenben úgy rémlik hogy 25 éve nem volt ilyen feltétel, most lett. Ez is logikus..


De azt továbbra se értem hogy egy friss fejlesztésű szoftver esetében miért nincs így illetve miért is működik a fejlesztőnél, és nálam nem.

nov. 24. 16:50
 4/10 anonim ***** válasza:
70%

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.

nov. 24. 16:56
Hasznos számodra ez a válasz?
 5/10 anonim ***** válasza:

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.

nov. 25. 12:14
Hasznos számodra ez a válasz?
 6/10 anonim ***** válasza:

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.

nov. 25. 15:17
Hasznos számodra ez a válasz?
 7/10 anonim ***** válasza:

#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.

nov. 25. 15:28
Hasznos számodra ez a válasz?
 8/10 anonim ***** válasza:
16%

"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.

nov. 25. 15:35
Hasznos számodra ez a válasz?
 9/10 anonim ***** válasza:

#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

nov. 25. 15:48
Hasznos számodra ez a válasz?
 10/10 anonim ***** válasza:

Ok, így rendben van. Mea culpa.


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

nov. 25. 16:25
Hasznos számodra ez a válasz?

További kérdések:





Minden jog fenntartva © 2022, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | WebMinute Kft. | Facebook | Kapcsolat: info@gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!