Kezdőoldal » Számítástechnika » Programozás » Mi a különbség a két konstans...

Mi a különbség a két konstans definíció között?

Figyelt kérdés

#define VALAMI BIT(7)


#define VALAMI 7



2013. ápr. 24. 06:54
1 2
 11/17 iostream ***** válasza:

#9 Nem kéne neki működnie, mert main függvényből csak egy lehet, és annak kötött a szignatúrája (nem void a visszatérési érték). Az egy más dolog, hogy trehány szar emberek vannak, és a fordítók ehhez alkalmazkodnak.


#10 Ebből lesznek az olvashatatlan fos kódok, és switch helyett elifet használni meg hihetetlen nagy butaság.

2013. ápr. 25. 13:39
Hasznos számodra ez a válasz?
 12/17 anonim válasza:

Kedves előttem szóló:


Ez mióta két main függvény? :)

Működik, gcc-vel fordítsd le és menni fog szépen... Fordítótól függ egyébként, hogy a main int vagy void típusú kell legyen. Én a C-t mikroprocesszorok programozásánál szoktam használni, ott a legtöbb fordító nem is engedi, hogy int típusú legyen, csak void lehet! Szóval annyira nem kötött mint hiszed. Lehet ezt tanultad, de ez hülyeség!

Int típusra akkor van szükség, ha valaminek kell adni visszajelzést a program befejezéséről. Egy operációs rendszer esetén van értelme, hiszen értesítheted azt arról, hogy hiba nélkül lefutott a program. Egy mikroprocesszor esetén viszont nincs minek visszaadni egy ilyen értéket.


Miért lenne olvashatatlan? Pont a jobb olvashatóság kedvéért szoktam magamnak egyszerűsíteni.


Nem azt mondtam hogy ne használj switchet, hanem hogy néhol nagyon elüt a C szintaktikától és emiatt zavaros lesz tőle a forrás, ezért olyankor inkább else if szerkezet kell. Na de annál meg azért csak szebb az elif :)

2013. ápr. 25. 14:11
Hasznos számodra ez a válasz?
 13/17 iostream ***** válasza:

Senki sem mondta, hogy két main függvény van, csak a linker egyet keres, és az általad írt pont nem lesz neki jó. Ilyenkor kereshetne tovább, hátha van egy jobb main (C++-ban van túlterhelés függvénynévre), de nem fog keresni, mert mainből csak egy lehet. De mit is tudsz te a linkelésről :)


Ha előkaparod a szabványt, explicit kimondja, hogy hogy nézhet ki a main. Mint említettem, a fordítók megengednek mást is, de ettől az még nem jó. A mikrokontroller meg egy külön világ, ott eleve korlátozottan áll rendelkezésre a C is.


Azért lesz olvashatatlan, mert olyan nyelvi elem nincs, hogy elif. Valaki leül a kódod elé, és sejti, hogy mit akarhat jelenteni, de nem lehet benne biztos, és meg kell néznie. Ezek után semelyik másik dologban nem lesz biztos. Persze amíg csak magadnak hegesztesz, addig minden fasza, csak addig nem igazán vagy komoly programozó, és addig is rossz szokásokat veszel fel.


A switch egyrészt nem üt el a C szintaktikától, pontosan annak mutatja, ami: egy ugrótábla. Erre utalnak a goto-label szerű case labelek.

Az else if meg azért praktikus, mert pontosan annak mutatja, ami: az if else ágában nyitott if-nek.

2013. ápr. 25. 14:20
Hasznos számodra ez a válasz?
 14/17 anonim válasza:

Az hogy mi jó, a gyakorlatban nem a szabvány mondja meg, hanem a fordító amivel dolgoznod kell. Erősködhetsz te a főnöknek, hogy az nem lenne szabványos, hogyha le kell fordítanod és nem működik a szabványos kódod...


Tisztában vagyok vele, hogy ha nem mikroprocesszorra fordítok, akkor int-ezni illik, de mint mondtam a GCC-nek semmi baja ezzel úgyhogy most megengedtem magamnak azt a luxust, hogy kicsit hanyag módon kispóroltam a plussz sort ahol a return 0 kellene :)


Elifre visszatérve, ja a C-ben nincs, de ez nem jelenti azt, hogy magamnak ne lehessen kibővíteni vele a nyelvet. Legfeljebb a munka végeztével lecserélem az elifeket else ifre seddel, hogy a kollégák is megértsék majd. Nem túl nehéz művelet.


cat elifes_main.c | sed {s/elif/else if/} >main.c


Sajnos én már csak ilyen maradi vagyok, szeretem kerülni a kényelmes fejlesztői környezeteket, kattingatós vackokat és inkább scriptelek mindent amit lehet.


Azzal meg nagyon nem értek egyet hogy nem üt el a switch a C szintaktikájától. Olyan mintha egy teljesen más nyelvből lenne beollózva :)

2013. ápr. 25. 14:53
Hasznos számodra ez a válasz?
 15/17 iostream ***** válasza:

Értelemszerűen, ha a fordítód szar, alkalmazkodni kell hozzá. Ettől még nem jó teljesen általános esetben (mint pl ez a kérdés) hülyeséget tolni.


Van jó hírem is: a return 0 elhagyható, implicit odaérti a fordító.


A sed amúgy tud inplace dolgozni (-i), és akkor nem kell cat meg > (cat amúgy sem, mert feldolgoz fájl paramétert). Abban a valószínűtlen esetben viszont, ha több elif van egy sorban (pl makrót nem akarsz szétcsapni sorvégi visszaperekkel), a seded csak az elsőt cseréli, javaslom a g módosító hozzácsapását a substitute parancshoz.

Láthatod, hogy én sem vagyok nagy klikkelőbajnok :D

2013. ápr. 25. 15:17
Hasznos számodra ez a válasz?
 16/17 anonim válasza:

Na ez utóbbi hozzászólásodban nem találok hibát :)


És ja, a return 0 is elhagyható, de úgy lenne szabványos!


De amúgy több elifet eleve nem tennék egy sorba :D


A sedet meg ismerem nyugi, csak így sokkal érthetőbb hogy mit csinál annak aki annyira nem ismeri. De örülök neki, hogy ismered és nem vagy te se klikkelőbajnok :)


A külső olvasóknak azért leírom azt amit te mondasz, hogy össze tudják hasonlítani:


sed {"s/elif/else if/g"} -i main.c

2013. ápr. 25. 15:39
Hasznos számodra ez a válasz?
 17/17 anonim válasza:
Mondjuk abban igazad van, hogy lehet nem kellett volna hanyag módon void-ot írnom, mert ez megzavarja a kezdőket. De szerintem azért az is hülyeség, ha azt etetik meg velük, hogy mindenhol az kell, mert az a szabvány és punktum.
2013. ápr. 25. 16:01
Hasznos számodra ez a válasz?
1 2

Kapcsolódó kérdések:




Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)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!