Do ... While
2008-05-02T14:00:48+02:00
2008-05-05T17:15:58+02:00
2022-07-26T00:47:24+02:00
  • Ha már fel akarunk háborodni a C nyelv szintaktikáján, szerintem sokkal érdemesebb a switch utasítást kipécézni.

    A switch gyakorlatilag egy többirányú goto utasítás, ahol a case címkékre lehet ugrani. Az ágak elválasztása nem kötelező, a kezdők (főleg, ha Pascalból jönnek) hajlamosak lehagyni a végükről a break-et. Másfelől nézve, minden címkét csak egy konstanshoz lehet rendelni, tehát ha tíz konstansra kell ugyanazt végrehajtani, az tíz címkét igényel. Aki még nem ismeri, tessék rákeresni a "Duff's device" kifejezésre, az szépen megmutatja, hogy lehet visszaélni a switch szerkezettel...

    Vessük össze a Pascal case szerkezetével, ahol kötelező szétválasztani az ágakat, minden ág egy tisztességes blokk, és egy ághoz nem csak több konstanst, hanem résztartományt is lehet rendelni. A Pascalnak is megvannak a hülyeségei, de a case szerkezet nagyon jól ki van találva.

    A szomorú persze az, hogy nem csak a C++, de (többek között) a Java és a C# is átvette ugyanezt a ronda szerkezetet. A C++ érthető, hiszen kompatibilis akart lenni a C-vel, de a másik kettőnél simán behozhattak volna új szintaxist. A C#-ban láttam annyi javítási próbálkozást, hogy két case címke között vagy nem szerepelhet utasítás, vagy szerepelnie kell egy break-nek, azaz nem lehet "átfolyni" a következő ágba. Ez ugyan jó dolog, de nem olyan szép, mint egy Pascal-stílusú case...
    Mutasd a teljes hozzászólást!
  • Ahogy mondjuk a mondat a magyar nyelvben a pontig tart, ami a pont után van, másik mondat.


    Ha mát itt tartunk, ez alól az egyszerű szabály alól is van kivétel: mondat véget érhet kérdőjellel és felkiáltójellel is. Hozzá kell tenni, hogy ezen szabályok az általános szövegben nagyon ritkán érvényesülnek (a te előző hozzászólásodban pl. 1 kérdőjel, 0 felkiáltójel és 22 pont volt). Most akkor vegyük ki ezen viszonylag ritkán használt kivételeket a nyelv szintaxisából csak azért, hogy egyszerűsítsük azt? A magyar nyelv, melyet mindnyájan beszélünk, eszméletlen sok szabályt tartalmaz, mégis mindannyian, magyar anyanyelvűek, nap mint nap használjuk anélkül, hogy tehert nyújtana a számos szabály megléte, szüntelen tiszteletben tartásuk. Igaz nem is világnyelv, de ennek talán más okai is vannak.

    A hozzászólásod többi része a te személyes véleményed, arra nem kívánok reagálni.

    A hétvége valóban véget ért, sajnos (nekem vakációm is volt egész múlthéten ), úgyhogy back to work. További jó filózást!
    Mutasd a teljes hozzászólást!
  • Igen, úgy tűnik, az a jónéhány év, amit C, C++ és Java programozással töltöttem, súlyos hátrányt jelent számomra ebben a kérdésben. Úgy szokta meg a szemem, hogy a blokkban deklarált változó érvényességi köre a blokk végéig tart, mert így szól a C szintaxis. Ahogy mondjuk a mondat a magyar nyelvben a pontig tart, ami a pont után van, másik mondat. Ennek előnyeit sajnos számodra hitelesen elmagyarázni nem tudom.

    Az idézett kód értelmezésétől visít minden neuronom... Mintha azt javasolnád, hogy mostantól az ismétlődést kifejező kijelentő mondatoknál (és csak ott) az erre utaló részt a pont után is lehessen írni, ha úgy tartja kedvem - például a "Hetente járok uszodába." jobban hangzik, ha így mondom: "Uszodába járok. hetente" - aha

    Találkoztam már bonyolult problémákkal és nagyobbacska projektekkel mindegyik nyelvben. A tapasztalatok által vált meggyőződésemmé, hogy az egyszerű szabály a jó szabály - amiben az szerepel, hogy "általában", az felesleges bonyolítása egy amúgy sem egyszerű dolognak.

    Hasznát meg végképp nem látom. Ha azt akarom, hogy egy változó egy adott blokkon kívül látható legyen, a blokkon kívül deklarálom. Bonyolult? Nem, szerintem sokkal tisztább, mint a "kivéve" tartalmú szabályok. Vannak bonyolult feladatok, amiket meg kell oldani. De bonyolult feladatot csinálni valamiből, aminek van egyszerű megoldása - az sport és nem szakma.

    Off: tanultam egy ideig egy asztalos mestertől, és készíteni akartam egy ládát, a sarkokhoz bonyolult 3D-s illesztést rajzoltam, hogy minden oldalról csúszásmentesen, a terhelésnek megfelelően stb illeszkedjen. Ő kicsit röhögött rajtam, de hagyta, hadd csináljam. A láda nyolc sarkából egy készült el így, vért pisiltem vele. Aztán a többi sarkát simán összecsapoltam, ahogy javasolta - és látható volt, hogy az fog tovább tartani. Ez ilyen. Szerintem.

    A C is azért tart ennyi ideig, azért "változatlan és meghaladhatatlan", mert egyszerű, mint egy balta, pont annyit tud, amennyit neki kell, és nincsenek benne "akár így is lehetne" megoldások: a legtisztább nyert.

    A hétvégének vége, többet/szebbet/jobbat úgysem tudok mondani - maradtam tisztelettel és kellemes filozofálást...
    Mutasd a teljes hozzászólást!
  • Támadt egy ötletem: egyáltalán ne használj do-while-t, csak for-t, ugyanarra való, ugyanazt tudja, pl:

    for (int leave= 0; !leave; ) { ... }

    vagy

    int found= -1; for (int i= 0; found==-1 && i<limit; ++i) { if (...) found= i; }
    Mutasd a teljes hozzászólást!
  • Kedves rynn - ezek szerint eléggé elbeszélünk egymás mellett.


    Nem beszélünk el, te leírtad, hogy szerinted az úgy korrekt és következetes, szerintem meg úgy is az ha kiegészítjük ezzel az apró módosítással.

    Te javasolsz egy olyan szabályt, a láthatóság "általában a zárójelig tart, kivéve, ha..." - na, szerintem ez a gáz, és nem 10mp-re botránkoznék meg rajta, hanem folyamatosan. Vegyük a következő példát:


    Fejezzük be a mondatot: "a láthatóság általában a zárójelig tart, ami a do-while ciklus esetében kiterjed a while-ig". Olyan bonyolult?

    ...
    ... és magyarázd el a programozónak, hogy a nyelv alapjaival ellentétben a while feltételben levő flag az egyébként már nem látható blokkon belüli változó, nem pedig a blokkon kívül deklarált, minden máshol elérhető adat


    Ha meg bevennénk azt az egy plusz feltételt a nyelv alapjaiba akkor az is képezné a nyelv alapját. A programozónak meg ennél jóval bonyolultabb dolgokkal is meg kell tudnia barátkoznia ha C++-ban akar programozni.

    itt az egy szinten levő while és if zárójelében szereplő "flag" nem ugyanaz az adat


    A szint fogalma abszolút nézőpont kérdése. Ha úgy szokta volna meg a szemed, hogy a do-while blokkját és a while kifejezését egy szintnek tekintsd, akkor most nem tűnne olyan vadnak az ötlet.

    És ezért az ostobaságért össze-vissza bonyolítanád a fordító működését.


    Ez az "ostobaság" nagyon is hasznos ostobaság lenne ám. A fordítónak pedig ennél 1000x bonyolultabb dolgokkal is meg kell birkózzon a C++ esetében (ezt nyílván nem kell fokozzam, aki ért a C++ az tudja ), szóval őket nem kell sajnálni.

    ... és ha tudnád, miken filozofálok szabad időmben...


    Hát még ha te tudnád miken filózok én.
    Mutasd a teljes hozzászólást!
  • Kedves rynn - ezek szerint eléggé elbeszélünk egymás mellett. Valóban főleg arról írtam, hogy úgy általában a C-t kritizálni nincs sok értelme - és nem tértem ki arra, hogy semmi előre mutatót nem látok az ötletedben azon kívül, hogy a felhozott "érveket" nem tudom elfogadni.

    Tehát:
    1: a C-ben a blokk határait a { } jelöli.
    2: a blokkon belül deklarált változó láthatósága a blokk záró jelig tart.

    Ez a szabály egyszerű, világos, egyértelmű, ennek alapján a do-while működése tiszta - ezen kellene felháborodnom? Szerintem ez egy "jó" szabály.

    Te javasolsz egy olyan szabályt, a láthatóság "általában a zárójelig tart, kivéve, ha..." - na, szerintem ez a gáz, és nem 10mp-re botránkoznék meg rajta, hanem folyamatosan. Vegyük a következő példát:

    { bool flag = true; do { bool flag = false; ... } while (flag) if ( flag) { ... } }

    ... és magyarázd el a programozónak, hogy a nyelv alapjaival ellentétben a while feltételben levő flag az egyébként már nem látható blokkon belüli változó, nem pedig a blokkon kívül deklarált, minden máshol elérhető adat (itt az egy szinten levő while és if zárójelében szereplő "flag" nem ugyanaz az adat...). És ezért az ostobaságért össze-vissza bonyolítanád a fordító működését. Ugyan már...

    Ez elég releváns volt?

    ... és ha tudnád, miken filozofálok szabad időmben...
    Mutasd a teljes hozzászólást!

  • ...kód...

    Ezzel pl. mit kezdjen szegény fordító? Ha valamifeltétel teljesül, honnan szedjen flag objektumot?


    Ezzel egyet tudok érteni, ez tényleg egy olyan eset amikor nem működne a dolog. Mi lenne ha egy olyan feltétellel kerülne kiegészítésre a dolog, hogy egy continue utasítás után deklarált változóra ne lehessen hivatkozni? Megoldana mindent, a fordító pedig egy diszkrét hibaüzenetben tájékoztatná a programozót ha esetleg megszegné ezt a szabályt.

    Itt ahhoz, hogy 'másik' működjön, még egyikobjektum-nak is a memóriában kell maradnia, tehát a teljes szkópot meg kéne őrizni!


    Valóban meg kéne őrízni, de csak 1 lépéssel tovább, amíg kiértékelődik a ciklus feltétele, utána ugyanúgy megsemmisülne mind.

    Egy ilyen szabály felállításának pont a rugalmasság növelése lenne a célja, azon rugalmasságé amiről amúgy a C/C++ nagyon is híres. Nem értem miért vannak egyesek ennyire ellene.

    még mindig előttetek áll a lehetőség, hogy a megfelelő fórumokon apelláljatok, úgyis készül az új C++!


    Nem is rossz ötlet!
    Mutasd a teljes hozzászólást!
  • A C/C++-ban a { és } mindenképpen blokkhatárt jelöl

    +
    Egy nyelv szabályai legyenek minél egyszerűbbek és mindenképpen következetesek, ugyanaz a jelenség (pl. itt a blokkok) viselkedjen minden körülmény között ugyanúgy, ne legyenek kivételek.


    Az a divat, hogy egy nyelv számos bonyolult szabállyal is lehet sikeres (pl. C#), továbbá, biztos vagyok benne, hogy nem lenne olyan egetverően nehéz a do-while esetében a közbenső blokkhoz csatolni még azt az egy, szerencsétlen while utasítást... úgyis egyből követi, tehát áttekinthetőség és szerintem a következetesség is megmaradna ebben az esetben. Ebben az egy esetben kellett volna csupán ezt az általános szabályt ("A C/C++-ban a { és } mindenképpen blokkhatárt jelöl") kibővíteni.

    ugyanaz a jelenség (pl. itt a blokkok) viselkedjen minden körülmény között ugyanúgy, ne legyenek kivételek.


    Valószínű, hogy így gondolták a nyelv tervezői is.

    interpet2:
    Mutasd a teljes hozzászólást!

  • do
    {
    if (valamifeltétel) continue;
    int paraméter = kiszámol;

    SajátTípusBonyolultKonstruktorral flag(paraméter);
    // ciklusmag
    } while( flag.ciklusfeltétel() );


    Ezzel pl. mit kezdjen szegény fordító? Ha valamifeltétel teljesül, honnan szedjen flag objektumot?

    --------

    Más:

    do
    {
    int paraméter = kiszámol;
    EgyikOsztály egyikobjektum(paraméter);
    MásikOsztály másik(egyikobjektum); // referenciát vezs át
    // ciklusmag
    } while( másik.ciklusfeltétel() );

    Itt ahhoz, hogy 'másik' működjön, még egyikobjektum-nak is a memóriában kell maradnia, tehát a teljes szkópot meg kéne őrizni!

    ----

    Amúgy ilyen best effort alapon tényleg be lehetett volna ilyesmit rakni a compilerbe egyszerű típusok és/vagy egyféle lefutás esetén. Most már valószínűleg késő, a breakage miatt, bár még mindig előttetek áll a lehetőség, hogy a megfelelő fórumokon apelláljatok, úgyis készül az új C++!
    Mutasd a teljes hozzászólást!
  • Nekem az a célom, hogy igen, bontránkozzunk meg rajta, kb. 10 másodpercig, és aztán éljük tovább az életünket a megszokott módon. Nem célom javítani, annak nyílván nincs helye.


    Fújj, fújj, fújj , attack, dobjátok a záptojást!
    MONGYON le!, MONGYON le!
    Mutasd a teljes hozzászólást!
  • Én is teljesen logikusnak tartom a jelenlegi működést, eleve nem is feltételeztem volna, hogy a QXY által próbált dolgok működnének, s ha úgy lenne, ahogy te és QXY várnátok, az következetlenség lenne a nyelv szempontjából. A C/C++-ban a { és } mindenképpen blokkhatárt jelöl (de mint láthattuk nem csak ezek határozhatnak meg egy blokkot), véleményem szerint hiba és következetlenség lenne ezt a viselkedést bárhol is felülbírálni. Egy nyelv szabályai legyenek minél egyszerűbbek és mindenképpen következetesek, ugyanaz a jelenség (pl. itt a blokkok) viselkedjen minden körülmény között ugyanúgy, ne legyenek kivételek.
    Mutasd a teljes hozzászólást!
  • Elvileg ez is logikus, meg jól kellene működnie. Igen ám, de a blokk végén megsemmisül az input, lefut a destruktora. A blokkon kívül már szemetet olvasnál.


    Lol... és mi lenne akkor, ha csak a ciklus feltételének kiértékelése után semmisítené meg az abban a blokkban létrehozott lokális változókat? Mindenféle probléma nélkül működne így QXY változata mindenféle hátrány és kompromisszum nélkül...
    Mutasd a teljes hozzászólást!
  • Szerintem írj egy saját fordítót, ami fordítás előtt átkovertálja az általad definiált szintaxist a hagyományosra :D


    Nagyon vicces.
    Mutasd a teljes hozzászólást!
  • amit mondasz, soha nem lesz megvalósítva


    Ki mondta, hogy az a célom, hogy forradalmat indítsak el és mindenki az én változatomat használja? Egyszerűen csak felhívni az emberek figyelmét, hogy még egy ennyire bevállt és elterjedt és egy tényleg "minden kalappal le előtte" nyelvben is lehetnek rossz pontok.

    mindnyájunk részéről kidobott idő ezzel bohóckodni ahelyett, hogy valódi feladatokat oldanánk meg.


    Mondtad volna ezt az ókori görög filozófusoknak és matematikusoknak, hogy mi a fenéért filozofálnak meg gondolkodnak hülyeségekről amikor vár a jószág etetésre.

    Most jönne a hozzászólásod többi része, de sajnálatos módon teljesen irreveláns, ezeket eddig is tudtuk. Egy dologra biztos, hogy jó, a te terminológiáddal élve: "bohóckodni ahelyett, hogy valódi feladatokat oldanánk meg".

    Szabályokról írsz amelyek felépítik a nyelvet, de azt nem írod le, hogy kétfajta szabály van: jó és rossz szabály. Ha egy nyelvben 100 szabályból 99 jó és 1 rossz, akkor az még ugyanúgy elterjedhet, legfeljebb az emberek megpróbálnak együtt élni azzal a rossz szabállyal.

    Ne vesztegesd az időt azzal, hogy hibát keresel vagy javítgatni próbálod, hidd el, millióan használják évtizedek óta (és nem a "millió légy", tudtak benne írni oprendszert, világméretű adatkezelő rendszereket, beágyazott cuccokat, bármit) - ha nekik megy és ügyi vagy, neked is fog...


    Csak azért mert az C nyelv ennyire elterjedt és a ma használatos programozási nyelvek jórészét nagyrészét ő ihlette, még nem azt jelenti, hogy csak jó szabályok vannak benne. Az meg, hogy ennyire elterjedt nem érv amellett, hogy csak jó szabályok vannak benne, és ennek a rossznak is biztos van valami célja, valami oka.... és hunyjunk szemet felette. Nekem az a célom, hogy igen, bontránkozzunk meg rajta, kb. 10 másodpercig, és aztán éljük tovább az életünket a megszokott módon. Nem célom javítani, annak nyílván nincs helye.
    Mutasd a teljes hozzászólást!
  • Az, ahogy most működik, logikusabb, mint QXY változata. Hogy meg tudjam világítani, mutatok egy hasonló C++ -os példát:

    do { std::string input; std::cin >> input; //.... } while (input=="vege");

    Elvileg ez is logikus, meg jól kellene működnie. Igen ám, de a blokk végén megsemmisül az input, lefut a destruktora. A blokkon kívül már szemetet olvasnál.

    Persze egy bool esetén nincs destruktor, ezért nem lenne ilyen probléma. Mégis logikusabb, ha konzisztensen kezeljük a dolgokat, és úgy vesszük, hogy a bool is megsemmisül a blokk végén. Ha az esetek felében úgyse működne, jobb, ha egyáltalán nem működik...
    Mutasd a teljes hozzászólást!
  • Szerintem írj egy saját fordítót, ami fordítás előtt átkovertálja az általad definiált szintaxist a hagyományosra :D
    Ha jól emlékeszem, akkor talán a CCC valahogy így működik (clipper -> C/C++).
    Mutasd a teljes hozzászólást!
  • 1. Ilyet C-ben nem lehet, C++-ban lehet.
    2. Az "int a" a blokkon kívül van, tehát nem jó példa a blokkon belül definiált változóra.
    3. Az "int a" a blokkon kívül van, de ez semmiképp sem jelenti azt, hogy ne látszana bármely őt követő utasításban.
    Pl:
    char s[]= "msg"; ... { printf (s); }
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Csak a tisztánlátás kedvéért nem vitatkozom, mert nincs értelme: amit mondasz, soha nem lesz megvalósítva (hacsak ezért az apróságért nem írod újra a C szintaktikai elemzőt minden olyan architektúrára, amire már létezik, és nem veszed rá a világot, hogy használja a tiédet). Tehát: mindnyájunk részéről kidobott idő ezzel bohóckodni ahelyett, hogy valódi feladatokat oldanánk meg.

    De a sport kedvéért folytatom
    A nyelv feladata az, hogy formalizálja a működés leírási módját. Éérted? Papíron(!) Első körben semmi köze ahhoz, hogy az általad ismert architektúrán, optimalizálás nélkül ez épp a verem milyen használatával valósul meg.
    Ennek a formalizálásnak rendkívül fontos eleme, hogy a használt adatterületek, amiket "változónak" nevez, leírási módját, és láthatóságát egyértelműen szabályozza - utóbbira a "blokk" fogalmát használja, és a láthatóságot ehhez köti, erre logikus (bizony, abszolút logikus, és ami még fontosabb: egyszerű és egyértelmű!) szabályokat alkot. Ismétlem: ennek a világon semmi köze ahhoz, hogy a gépi fordítás során ebből éppen veremfoglalás meg ilyesmik keletkeznek. Ha nekiáll a fordító egy bonyolultabb spagettikódot optimalizálni, nem fogsz ráismerni a C kódodra a gépi utasítássorból (regiszterek, cache, újrahasznosított területek, stb). A dolog nem arról szól, hogy pontosan hogyan jelenik meg, hanem hogy az elkészült, szénné optimalizált kód is úgy működjön, ahogyan azt te (most éppen a C szintaxis használatával) előírtad.

    Ennyi. Megtanulod a szabályokat, használod, és a gép azt csinálja, amit mondasz. A nyelv NEM alkalmazkodik sem a te elképzeléseidhez, sem ahhoz az architektúrához, amin éppen dolgozol. A nyelv egy közvetítő csatorna a "programozható bármi" irányában, örülünk, hogy van, és működik.

    ... ha összefutsz néhány, több, mint három ember több, mint egyéves munkájával összerakott, határidős projekttel, (tervezői és nem megvalósítói szinten), megérted a következő mondás értelmét: If it works, don't fix it. Elmagyarázni úgysem tudom, szerintem az idő és a felelősségtudat hozza magával azt, hogy az ember a kérdései között is szelektál: mi értelmes és mi értelmetlen.

    A C ennél nagyságrendekkel nagyobb falat. Ne vesztegesd az időt azzal, hogy hibát keresel vagy javítgatni próbálod, hidd el, millióan használják évtizedek óta (és nem a "millió légy", tudtak benne írni oprendszert, világméretű adatkezelő rendszereket, beágyazott cuccokat, bármit) - ha nekik megy és ügyi vagy, neked is fog...
    Mutasd a teljes hozzászólást!
  • Akkor most mi is legyen vizsgálva a while-ban? Egyszerűen a while nem látja a blokkon belül deklarált változókat, ami szerintem teljesen logikus a működés.


    Miért is olyan logikus? Nagyon is szükség annak a benne deklarált változónak az értékére, technikailag a legapróbb probléma nélkül megoldható, pusztán egy } áll az útjában... nagyon is nem logikus, hogy így csinálták meg. Vagy vannak esetleg érveid is amellett, hogy miért jó ez így?
    Mutasd a teljes hozzászólást!
  • Akkor itt van ez a kód, bár nem vagyok biztos bene hogy ilyet a C megenged, de C++ igen:

    for( int a = 1; a < 10; a++ )
    {
    a++; // a blokkon belül
    }

    A vermes dolgot azért írtam le, hogy értsétek miért akadtam ki rajta.


    Na igen, de ha megnézed, már a {} blokk előtt deklaráltad a változókat (honnan látná a for vizsgálat, ha a {} blokkon deklarárálnád az a -t ?).
    Hasonló az eset a do-while esetében, a while azt várja el, hogy a {} blokk előtt deklaráld a változót!

    do { bool flag = true; // ciklusmag } while( flag );


    A példakódodban minden alkalommal újra deklarálod a változód!!!
    Akkor most mi is legyen vizsgálva a while-ban? Egyszerűen a while nem látja a blokkon belül deklarált változókat, ami szerintem teljesen logikus a működés.

    Valahogy így kéne csinálni:


    bool flag = true; do { flag = true; // ciklusmag } while( flag );
    Mutasd a teljes hozzászólást!
  • ÚÚÚÚRRRRRRIIIIISSSSTTEEEENNNNNN!

    Szerintem ezen nincs értelme görcsölni. Ha már ezen kiakadsz, mi lesz ha .netezni fogsz, és pl. generics-et haszálsz...
    Mutasd a teljes hozzászólást!
  • Ok, rendezzünk egy vitát. Legyen pro és kontra:

    Pro:
    -üres-

    Kontra:
    1. kényelmetlen, pedig tökéletesen megvalósítható és értelmes lenne, és emellett lenne rá igény (ezeket több pontba is lehet szórni a látványosság kedvéért)

    Várom a pro érveket.
    Mutasd a teljes hozzászólást!
  • Ez mind OK - de mi értelme van ennek a kérdésnek? Miért írjuk úgy, hogy Attila, amikor mindenki atillának ejti? Miért muszáj és nem muszály, amikor pedig uszály vagy dagály?

    Rajongok a C nyelvért, szeretem amit és ahogyan meg lehet benne csinálni, és valóban komoly tiszteletet érzek azok iránt az emberek iránt, akik kitalálták és megvalósították. Továbbá azok iránt is, akik elképesztő dolgokat tudnak megvalósítani benne.

    Egy nyelvben az az érték, hogy szabályokat alkot, amelyek segítségével kommunikálni tudunk egymás között vagy gépekkel. Minden szabály megkérdőjelezhető - de ennek, ha bizonyítottan működik, semmi értelme nincs. A nyelv szintaxisa leírja, hogy mit szeret és mit nem. Aszerint használható, máshogy meg nem.

    Zavaró dolog van millió, ha nagyon muszáj, nevezheted ezt is annak, de szerintem... programozzunk inkább.
    Mutasd a teljes hozzászólást!
  • Rakd a do-t is egy külön blokkba, és így gyakorlatilag ugyanazt a hatást érheted el:

    ... { bool flag; do { flag = true; // ciklusmag } while( flag ); } ...

    De abban szerintem mindenki egyetért, hogy a szintaktika/szemantika általad leírt működése minden értelmet nélkülöző, nagyon zavaró dolog (engem legalábbis nagyon zavar hogy így találták ki a "nagyokosok").
    Mutasd a teljes hozzászólást!
  • Részlet a ISO/IEC 9899:TC2-ból (C nyelvi specifikáció)
    6.8.5.5 An iteration statement is a block whose scope is a strict subset of the scope of its
    enclosing block. The loop body is also a block whose scope is a strict subset of the scope
    of the iteration statement.


    Teljes összhangban azzal, amit mondtál.
    Megjegyezném még, hogy ez nem szintaxis, hanem szemantika kérdése.
    Mutasd a teljes hozzászólást!
  • A while zárójelek közti része eggyel külsőbb blokkba tartozik, mint amit a ciklusmagba írtál, s így a belsőben deklarált változó a külsőben nem elérhető. A for-nál fordítva van a helyzet, a változót egy külsőbb blokkban deklaráltad (a for ciklus zárójelek közti része), s egy belsőbben is használod (a ciklusmagban a { és } közti rész).
    Mutasd a teljes hozzászólást!
  • Én értem hogy "szintaktikai okokból" miért nem lehet, de ennyi erővel, ha a for { előtti lokális változója érvényes a blokkon belül, akkor az említett esetben miért nem? A ...while(kifejezés); is ugyanúgy a ciklus része! A gépi kódnak csupán annyi köze van hozzá, hogy minden programnyelv ott "végzi" miután a lefordítódott. Pontosan azért írtam le hogy ez kb. hogyan működik alacsony szinten. De akkor itt semmi másról nincs szó, csak szintaktikáról?! Több munkatársamtól is megkérdeztem ezt és mindenki - kis gondolkodás után - rávágta hogy igen miért ne lehetne... Aztán kipróbáltuk és nem ment. :)
    Mutasd a teljes hozzászólást!
  • A C-ben az utasításon belül deklarált dolgok is a blokkon belülinek számítanak. Ilyet tudsz csinálni if-en belül is,
    Pl. if ((FILE fi=fopen("a.txt","rt")!=null).

    Amúgy a for mint dolog sok nyelvben ennél sokkal "formabontóbb", Pl. néha érdekes dolgok történnek ha a ciklusmagban próbálod önhatalmúlag megváltoztatni a ciklusváltozó értékét.
    Mutasd a teljes hozzászólást!
  • hatáskörök fordítási időben értékelődnek


    Es az optimalizalas elott, kozben es után (szvsz)
    Mutasd a teljes hozzászólást!
Címkék
abcd