C kérdés: int i; i;
2017-12-27T02:50:50+01:00
2018-01-04T15:27:56+01:00
2022-07-21T08:43:47+02:00
  • Sem a literál 5-öt sem a "hello"-t nem arra fordítja le, hanem valamilyen semmit nem csináló gépikódra (compilertől függően).

    Én is ezt mondom. Amit te "semmi"-nek hívsz, az a kifejezés kiértékelése, aminek bonyolultabb példáknál lehet (elérni kívánt) mellékhatása. És igen, a fordító bizonyos optimalizációi ki is hagyhatják ezt a részt a végleges kódból.

    Bocs, de "a mai napig olyan jól csinálják"-ról így kapásból és többek közt a Go programozási nyelv jut az eszembe

    Hát erre majd akkor térjünk vissza, ha a google újraírja az androidot go-ban. Attól, hogy ők hárman azt mondják, hogy ez a nyelv célja, még nem lesznek belőle oprendszerek. Kerestem ilyen OS-eket, de valahogy mind elakad valahol. (Ez pl. tök vicces: GoFY)

    Való igaz, hogy a C nem modern, és sok jellemzője ma már felesleges szöszölésnek tűnik még nekem is. A konkrét példád engem nem zavar, mint ahogy az egyébként rigiózus java-ban elfogadott másik példa sem.

    Konkrétan rendszerprogramozásnál épp el tudok képzelni szükséges mellékhatásokat kiváltó "semmi"-ket.

    Nem szerecsenmosdatás ez, hanem a nyelv érdemeinek elismerése a hiányosságainak elnézésével. Szerintem a C nyugdíjba se vonul még jó ideig. Nem tudom mi mással lehet még pl. hardver-illesztőprogramokat írni.
    Mutasd a teljes hozzászólást!
  • Köszi az infókat.

    Persze nem tudjuk, hogy van-e (vagy volt-e a 70/80-as években) olyan exotikus compiler, ami a szabvány ezen "hiányosságát" (?, lásd 2./3. pont) kihasználja.

    Én is hasonlóra gondolok.
    Mutasd a teljes hozzászólást!
  • Ok, ezúton szeretnék elnézést kérni azoktól, akiknek beletapostam a lelkivilágába, igyekszem ezentúl kerülni.
    Mutasd a teljes hozzászólást!
  • Hirtelen nem találtam forrást arra vonatkozólag, hogy milyen filozófia szerint alkották meg a C-t. De mivel a C++ eredetileg egy C kiterjesztésnek indult ezért gondolom erős az átfedés a kettő között. Stroustrup filozófiája pedig a következő: (3. oldal, rules of thumb for the design of C++)

    Don’t get involved in a sterile quest for perfection.
    ...
    Don’t try to force people to use a specific programming style.
    ...
    It is more important to allow a useful feature than to prevent every misuse.

    Ezek alapján te az 1. pontot kéred számon, mert a PC-dhez készült compileren nincs érteleme valaminek. Persze nem tudjuk, hogy van-e (vagy volt-e a 70/80-as években) olyan exotikus compiler, ami a szabvány ezen "hiányosságát" (?, lásd 2./3. pont) kihasználja.

    Minden nyelv/framework vagy bármilyen technológia valamilyen filozófia alapján készül, ami bizonyos dolgokat előtérbe helyez más dolgok kárára. Ez teljesen rendben van hiszen emiatt jobb x technológia A megvalósítására, mint y, viszont y sokkal jobb, ha B-t kell csinálni.
    Ehhez az egészhez hozzáadódik, hogy a szabványosítás során általában ipari szereplők a saját aktuális érdekeiket tolják előre, ami nem biztos, hogy a nap végén a legoptimálisabb döntést eredményezi.

    A lényeg, hogy a C közösség nem tartja ezt akkora problémának, mint te, hiszen akkor már régen szabványosították volna. Ha nem tetszik a filozófia, ami a nyelv mögött áll, akkor egyszerűen állj tovább és használj egy hozzád közelebb álló nyelvet. Biztos van olyan is, amivel azonosulni tudsz.
    Mutasd a teljes hozzászólást!
  • Hali!

    Figyu, én már többször is lezártam részemről a topicot, most is pont, hogy te kezded előröl, ráadásul úgy, hogy legyen újból min csámcsogni.

    Nem te kérdeztél rá matt383-nál? Idézem: „És hol is voltam troll? Kíváncsivá tettél.” Nos, matt383 megmutatta, hogy „hol” (miben) is voltál troll. 

    Mutasd a teljes hozzászólást!
  • Nem is vitatkozik veled senki igazából, mindenki egyetért ...

    Figyu, én már többször is lezártam részemről a topicot, most is pont, hogy te kezded előröl, ráadásul úgy, hogy legyen újból min csámcsogni.
    Mutasd a teljes hozzászólást!
  • Röviden összefoglalom neked a topicot, ha már így rákérdeztél.

    NPL: Szerintem ez hülyeség a C-ben.
    Valaki: Szerintem nem.
    NPL: Pedig szerintem ez hülyeség.
    Valaki: Szerintem is hülyeség, de lehet, hogy okkal került a specifikációba.
    NPL: De szerintem ez hülyeség.
    Valaki: Itt van példa, ahol értelme lehet.
    Valaki más: Itt van még példa, ahol értelme lehet.
    NPL: De szerintem ez hülyeség, a példák rosszak.
    ...
    ...

    Nem is vitatkozik veled senki igazából, mindenki egyetért vele, hogy túl sok értelme nincs, ha minden kifejezés utasítás, mégis újra és újra megismétled a topiknyitó hozzászólást anélkül, hogy bármilyen irányba tartana a beszélgetés.
    Mutasd a teljes hozzászólást!
  • Ok, neked nem volt hasznodra, másnak viszont lehetett.
    És hol is voltam troll?
    Kíváncsivá tettél.
    Mutasd a teljes hozzászólást!
  • Szóval szerinted trollkodtam és az egész topic senkinek nem volt hasznára.

    Szerintem igen.
    Mutasd a teljes hozzászólást!
  • Szóval szerinted trollkodtam és az egész topic senkinek nem volt hasznára.

    Dehogy is nem! Legalább volt egy topic a holt szezonban, amin lehetett röhögni :)
    Mutasd a teljes hozzászólást!
  • Mi többiek meg etetjük... szerintem süllyedhet

    Szóval szerinted trollkodtam és az egész topic senkinek nem volt hasznára.
    Mondod pont te, akinek csak kb. 20-dik hozzászólás után esett le a tantusz, hogy mi a probléma lényege:
    "Miért nem ezzel kezdted, időt takarítottunk volna meg"

    Amúgy én veled eddig nem személyeskedtem, te viszont már az elején így indítottál többed magaddal és én már kétszer is beakartam fejezni ezt a topicot úgy hogy nem az enyém az utolsó szó.
    Tényleg szükség van az ilyen személyeskedésekre, sértésekre?
    Másképp nem megy?

    Egyébként nem arról van szó, hogy itt a fórumon ne lenne minden vélemény egyformán értékes. Legfeljebb annyi az eltérés a teljes egyenlőségtől, hogy a szakértői pontok számával súlyozódnak a vélemények;)

    Ja hogy ez objektíven nem megy és nálad a tekintélyedet is figyelembe kell venni.
    Ez csak téged minősít.
    Mutasd a teljes hozzászólást!
  • Mi többiek meg etetjük... szerintem süllyedhet
    Mutasd a teljes hozzászólást!
  • Semmilyen szerecsenmosdatás nincs itt. Már többször leírtuk, hogy akkor, amikor a nyelvet tervezték, jó ötletnek tűnt pár egyszerű elv mentén megalkotni egy nyelvet. Jó ötlet is volt, mert akkor akkor volt, most meg most van. Te a mostból nézed az akkort, de akkor bírálhatnád a tömör kerekű kordét is egy mai autóhoz képest, csak épp nincs semmilyen értéke a bírálatnak. A többség helyén is kezeli a C-t, mert nem áll neki C-ben dolgozni, amikor valamit Java-ban, C#-ban, JavaScriptben, PHP-ben, stb. meg tud csinálni könnyen. Most ez valamiért becsípődött neked, de ennyi erővel a JS, meg a PHP problémái is becsípődhetnének.
    Mutasd a teljes hozzászólást!
  • "Erre belehetett volna vezetni egy explicit nop (no operation) utasítást a C nyelvbe."

    Nem kell, mert már van benne. Az egy szál pontosvessző magában az üres utasítást jelenti.

    Szerintem az egy szál pontosvessző nem explicit (ezért is problémás).
    Mutasd a teljes hozzászólást!
  • Egyszerűen arról van szó, hogy amikor a C-t kitalálták, az volt a feladata, hogy azt a kódot, amit a programozó leír, fordítsa le gépi kódra.

    Sem a literál 5-öt sem a "hello"-t nem arra fordítja le, hanem valamilyen semmit nem csináló gépikódra (compilertől függően).

    És ezt a C fordítók a mai napig olyan jól csinálják, hogy pl. operációs rendszerek készülnek C-ben.

    Bocs, de "a mai napig olyan jól csinálják"-ról így kapásból és többek közt a Go programozási nyelv jut az eszembe, amit alapvetően 3 programozó tervez és ezek közül az egyik az a Ken Thompson, aki pont a C nyelv egyik megalkotója volt.
    Az ELTE programozási nyelvek weboldala pl. ezt írja a Go-ról:

    "... A fejlesztés célja egy olyan nyelv kifejlesztése volt, mely megfelel a 2010-es évek kihívásainak. A fejlesztők észrevették, hogy (széles körben elterjedt) rendszerprogramozásra szánt nyelv már évtizedek óta nem készült, és amik akkor készültek (C, esetleg C++), már elavultak ..."

    Tudom, hogy egy kicsit ez tekintélyelvű volt, de elég sokszor érezni a C nyelvnél, hogy nem modern.
    Ettől függetlenül nem akarom a C nyelv érdemeit elvitatni, de azért a helyén kéne kezelni a C nyelvet és őszintén szembe nézni azokkal a dolgokkal, amik ma már elavultak és jó lenne nem csak azt a szerecsenmosdatást látni, amivel lépten-nyomon találkozni.

    Bizonyos esetekben haszna is lehet a dolognak. Ha például kikapcsolod az optimalizációkat, ciklusban mérheted vele a változó kiolvasásának idejét. Vagy lehet okod arra, hogy a lefordított kód egy bizonyos méretű legyen, amit pl. ilyesmivel növelhetsz.

    Mint írtam, nem vagyok egy C guru, de szerintem ezeket meglehet oldani másképp is és szerintem alapvetően nem ezért engedélyezték a nyelvben ezeket a "semmi" feature-öket ráadásul úgy, hogy bizonyos compilerek (pl. GCC) alapértelmezetten csont nélkül lefordítsák.
    Mutasd a teljes hozzászólást!
  • Még olyat is írhatsz, hogy:

    5; "hello";
    aminek még annyi értelme sincs, mint a változónak. Egyszerűen arról van szó, hogy amikor a C-t kitalálták, az volt a feladata, hogy azt a kódot, amit a programozó leír, fordítsa le gépi kódra. És ezt a C fordítók a mai napig olyan jól csinálják, hogy pl. operációs rendszerek készülnek C-ben. Java-ban meg, ami nem hagyja a fentit, nem készülnek, legalábbis elterjedtek nem.

    Mellesleg Java-ban is lehet írni olyat, hogy

    int i=0; i=i;
    Aminek ugyanúgy nincs értelme, de nem hiba.

    Egy átlagos C fordító nem fog téged korlátozni, ha értelmetlen dolgot akarsz csinálni, különösen olyankor, ha a dolog nem okoz hibát.

    Bizonyos esetekben haszna is lehet a dolognak. Ha például kikapcsolod az optimalizációkat, ciklusban mérheted vele a változó kiolvasásának idejét. Vagy lehet okod arra, hogy a lefordított kód egy bizonyos méretű legyen, amit pl. ilyesmivel növelhetsz. Vagy lehet mellékhatása egy makrónak, amit egyébként csak átláthatatlanabbul tudnál megfogalmazni.
    Mutasd a teljes hozzászólást!
  • Én semmit nem mernék alapozni arra, hogy az ilyen utasítások bármiben különböznek egy üres utasítástól.

    Általánosságban én sem. De C fordítóból van sok. El tudom képzelni, hogy adott esetben, adott fordítónál, adott platformon és hardveren van értelme ennek, bár nem szorgalmaznám az ilyesmit és még véletlenül sem szeretnék ennek bármilyen híve lenni.
    Mutasd a teljes hozzászólást!
  • Erre belehetett volna vezetni egy explicit nop (no operation) utasítást a C nyelvbe.

    Nem kell, mert már van benne. Az egy szál pontosvessző magában az üres utasítást jelenti. Lehet is vele lábon lőni magadat, ha mondjuk egy while ciklus feje után pontosvesszőt raksz, ezzel az üres utasítást megtéve ciklustörzsnek.

    @tihamer.lovassi:

    Akkor sem ugyanaz. Mert a nop és a semmire nem használt a+b funkcionálisan ugyanaz, de végrehajtási időre nem.

    Ha bármi optimalizáció be van kapcsolva, akkor teljesen ki fogja venni a gépi kódból a fordító (kivéve a volatile módosítós esetet). Én még arra se vennék mérget, hogy kikapcsolt optimalizáció mellett minden fordító benn hagyja a gépi kódban. Én semmit nem mernék alapozni arra, hogy az ilyen utasítások bármiben különböznek egy üres utasítástól.
    Mutasd a teljes hozzászólást!
  • Erre belehetett volna vezetni egy explicit nop (no operation) utasítást a C nyelvbe.

    Akkor sem ugyanaz. Mert a nop és a semmire nem használt a+b funkcionálisan ugyanaz, de végrehajtási időre nem.

    Ez pedig nem futásidejű hiba, mert a compiler nagyon helyesen figyelmezet már fodításkor, KÉRÉS NÉLKÜL:
    x = z / 0;

    Értem én, hogy warning, de mi van, ha én szándékosan akarok konstans nullával osztani?

    A furcsa számomra az, hogy ez rajtam kívül senkit sem zavar.

    Félreérted szerintem: a többség itt próbált magyarázatot találni, vagy valamiféle választ a miértre, nem pedig azt mondja, hogy neki tetszik, hogy így van. Nekem pl. mindegy. Engem nem zavar a C ilyen működése, de ha tiltva lenne, az sem zavarna, de ha választani lehet, akkor inkább úgy legyen, mint ahogy most van. A te szempontjaidat is értem, vannak nyelvek, ahol érvényre is jutnak a szempontok. Viszont a C egy régi, buhera nyelv, ahol tudod, mi történik a háttérben. Az i; inkább tűnik nekem szándékos, valami jó okkal történő dolognak, mint véletlen elgépelésnek.
    Mutasd a teljes hozzászólást!
  • Rengeteg fölösleges dolgot lehet csinálni...... Pl. a println("") sem csinál semmit ...

    Erre belehetett volna vezetni egy explicit nop (no operation) utasítást a C nyelvbe.
    De nem tették.

    A 0-val való osztás más eset, mert az tényleg futási idejű hiba lesz, de az azonosító nem.

    Nem feltétlenül futásidejű hiba.
    Ez pl. futásidejű hiba:
    int x = 0;
    int y = 1 / x;

    Ez pedig nem futásidejű hiba, mert a compiler nagyon helyesen figyelmezet már fodításkor, KÉRÉS NÉLKÜL:
    x = z / 0;
    Valószínűleg ez egy elgépelés volt, akárcsak ez:
    i;
    A különbség az, hogy erre az elgépelésre csak akkor figyelmeztet a compiler, HA KÉRED.

    Másrészt az is lehet egy legitim elv, hogy az nem hiba, ami amúgy helyes és nem "okoz kárt".

    Fogalmazzunk inkább úgy, hogy valószínűleg vagy jó eséllyel nem okoz kárt.
    Mindazonáltal az ilyen nüansznyi vagy elbagatelizált hibaforrásokból tudnak lenni a legváratlanabb hibák, balesetek, katasztrófák, stb.
    A furcsa számomra az, hogy ez rajtam kívül senkit sem zavar.
    Mindenki
    - bagatelizál
    - meg hogy ez nem okoz problémát, ez helyes működés
    - jól kell ismerni az eszközt
    - teszteléskor előjön
    - használj verzókövetőt
    - a 70-es években ez nem volt szempont, mostmár együtt kell vele élni
    - ez ízlés dolga
    - hülye vagy
    - stb.

    Szerintem meg alapértelmezetten, kérés nélkül kéne küldenie warningot.
    Ennyi.
    Mutasd a teljes hozzászólást!
  • Egyetértek azzal, hogy az esetek nagy részében elírást jelez egy ilyen utasítás. De vajon milyen esetekben szerepelhet helyes kódban ilyen? Három ötletem van:

    Ahogy Csaboka2 írta, simán lehet, hogy egy trükkös makró, vagy gép által generált kód speciális esetben ilyen utasítást is létrehozhat. Erre van néhány nem túl életszerű ötletem, helyette álljon itt egy feltételes fordításhoz kapcsolódó (képzeljük el mondjuk MAC-en):
    #ifdef __linux__ int linuxspec = 2 * #elif _WIN32 int windowsspec = 3 * #endif i;
    Bár normál esetben az i; tényleg nem csinál semmit, ha esetleg pusztán egy hozzáférés a változóhoz undefined behavior (pl. érvénytelen mutató / trap representation / C++: érvénytelen referencia / C++11: race condition ?), akkor más lehet a helyzet. Elfogadható olyan kódot írni, mely adott platform/fordító/optimalizációs szint esetén már jól definiált. Ilyenkor akár csinálhat is valamit az a sor.

    Vajon létezik olyan helyzet, ahol egy ilyen utasításnak meghatározott hatása van a szabvány szerint? Nem feltétenül erre gondolok :)
    #define i system("format c:") i;
    Pl.: NevemTeve/Csaboka2 példája, volatile változó + memory mapped IO, pl. eszköz regiszter olvasás? GCC már nem is ad warningot erre:
    volatile int i = 0; i;
    Mutasd a teljes hozzászólást!
  • A 0-val való osztás más eset, mert az tényleg futási idejű hiba lesz, de az azonosító nem.

    Rengeteg fölösleges dolgot lehet csinálni, amik egy része valójában mégis jó legalább arra, hogy megmérd kódok futási idejét. Pl. a println("") sem csinál semmit, de mégis jó arra, hogy a println hívás overheadjét lemérd. Az i+2; utasítás is jó arra, hogy az "add AX, 2", vagy valami hasonló idejét lemérd. Másrészt az is lehet egy legitim elv, hogy az nem hiba, ami amúgy helyes és nem "okoz kárt". Mert törvénybe sem iktatjuk azt, hogy nem mehetek át egy másik szobába csak azért, hogy egyből visszajöjjek onnan.

    Valamennyire ízlés dolga, amiről vitázol. Amellett azt sem értem, hogy mit szeretnél még, mert ha kimondjuk, hogy a C nyelv tervezői slendriánok voltak, aztán az egész úgy maradt, akkor mi van? A C# egyébként megtiltja az olyasmit, amiről a téma szól, ahány nyelv, annyi szokás.

    fontosabb volt a szabály mindenáron történő erőltetése

    Nekem az az érzésem, hogy amikor a C született, akkor pont nem az erőltetésen volt a hangsúly, hanem azon, hogy a kifejezések C-beli használata jó, kompakt és kényelmes, az pedig egyszerűen nem volt szempont, hogy az ilyesmi edge case-ekre felkészüljön egy fordító, mert akkoriban nem programozott még mindenki, a programozás nem mainstream hobby tevékenység volt, hanem munka és a kódok sem voltak akkorák, mint manapság, tehát az ilyesmi hiba jelentősége igazából nem volt nagy. Újabb nyelvek egy része pedig már figyel erre. Az idő telik, a világ fejlődik. Nem lehet a barlangrajzolás másnapján tökéletes fordítókkal előállni.
    Mutasd a teljes hozzászólást!
  • Igen, az jó dolog, ha a fejlesztő ismeri az eszközöket, amiket használ.

    Szerintem ez a topic is hozzájárult ehhez.
    Mutasd a teljes hozzászólást!
  • 1990-ben lett véglegesítve az ANSI C.

    Addigra már épp elég kódbázis lehetett, hogy ilyen és ehhez hasonló apróságok miatt ne törjék meg a visszafelé kompatibilitást.

    Ha a megfelelő fordítási parancsokat használod, akkor igen, figyelmeztet.

    Igen, az jó dolog, ha a fejlesztő ismeri az eszközöket, amiket használ.
    Mutasd a teljes hozzászólást!
  • Van még ezer másik lehetőség, amit a szintaktika megenged, de nincs értelme, vagy nem definiált viselkedést eredményez.

    Ezzel egyetértek. Szinte bárhová nyúl az ember a C-ben, csontvázak hullanak ki.
    Mutasd a teljes hozzászólást!
  • ... szokott-e random billentyűket nyomogatni mikor unatkozik ...

    Senki nem beszélt "random billentyű" nyomogatásról, végig elgépelésről volt szó, bár ezt te is nagyon jól tudod.

    Nem hiszem, hogy a programnyelvnek hülyebiztosnak kellene lennie (abban sem vagyok biztos, hogy lehet ilyen nyelvet csinálni.).

    Segítek. Nem lehet csinálni "hülyebiztos" programozási nyelvet és eddig sem erről volt szó.
    Mutasd a teljes hozzászólást!
  • Aztán, hogy ki milyen opciókkal fordítja le a kódját, az már egy másik kérdés.

    Az pedig egy harmadik (negyedik, ötödik, stb...) kérdés, hogy az illető
     - szokott-e random billentyűket nyomogatni mikor unatkozik, hogy ez jöjjön ki (i; az i--; ból, mint az előző példádban)
    - szokott-e teszteket írni és rendszeresen futtatni, (ami megvédi őt az ilyen vagy ehhez hasonló hibáktól)
    - használ-e valamilyen verziókövető rendszert, (amiben nyomon tudja követni a változtatásait, hogy kiderüljenek az ilyen vagy ehhez hasonló hibák)
    - stb...


    Átolvastam ezt a threadet, de őszintén nem értem a problémádat ezzel. Van még ezer másik lehetőség, amit a szintaktika megenged, de nincs értelme, vagy nem definiált viselkedést eredményez. A sok közül ez a legkisebb probléma, hiszen nem csinál semmit.

    Nem hiszem, hogy a programnyelvnek hülyebiztosnak kellene lennie (abban sem vagyok biztos, hogy lehet ilyen nyelvet csinálni.).
    Mutasd a teljes hozzászólást!
  • ... a 70-es években, amikor az első C fordítók készültek, még szerintem nagyon is lényeges volt az akkori számítási kapacitás mellett.

    1990-ben lett véglegesítve az ANSI C.
    Akkor azért már volt megfelelő számítási kapacitás (főleg a nagy gépekben) és a parserek is sokat fejlődtek már addigra.
    Mutasd a teljes hozzászólást!
  • Egy nem valós problémáról beszélsz.
    .... minden normális fordító képes detektálni és figyelmeztet ...

    Ha a megfelelő fordítási parancsokat használod, akkor igen, figyelmeztet.
    Aztán, hogy ki milyen opciókkal fordítja le a kódját, az már egy másik kérdés.
    Mutasd a teljes hozzászólást!
  • Valószínűleg régen egyszerűbb volt így megadni/definiálni a nyelv-et,
    "An expression followed by a semicolon is a statement.", kivételek, edge-casek említése nélkül.

    Így van, és a fordítót is egyszerűbb így implementálni. Ma már nem lényeges a különbség, de a 70-es években, amikor az első C fordítók készültek, még szerintem nagyon is lényeges volt az akkori számítási kapacitás mellett.
    Mutasd a teljes hozzászólást!
Címkék
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd