- Samsung Galaxy S25 Edge - a tegnap határán
- Milyen okostelefont vegyek?
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy A56 - megbízható középszerűség
- Bemutatkozott a Poco X7 és X7 Pro
- Megjött a jubileumi Pixel széria
- Apple Watch Sport - ez is csak egy okosóra
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- Kínosan környezettudatos a HMD
- Yettel topik
Új hozzászólás Aktív témák
-
pmonitor
aktív tag
válasz
dabadab
#6299
üzenetére
Mi nem érthető azon, hogy "Elméletileg a goto-ra soha sincs szükség, és gyakorlatilag majdnem mindig egyszerűen programozhatunk nélküle is."
És mikor írta ezt a könyvet?
Egyébként a ciklust is meg lehet írni goto nélkül(bár az azért 1 kicsit bonyolultabb, de megoldható). Pl. ezt sem vették figyelembe. Azóta már sok minden változott, még ha alap könyvről is van szó. -
pmonitor
aktív tag
válasz
buherton
#6296
üzenetére
B. W. Kernighan - D. M. Ritchie: A C programozási nyelv című C alapkönyvben írják:
A C-ben is használhatjuk a sokat szidott goto utasítást, ugrathatunk címkékre. Elméletileg a goto-ra soha sincs szükség, és gyakorlatilag majdnem mindig egyszerűen programozhatunk nélküle is. Ebben a könyvben nem használtunk goto-t. Mindazonáltal bemutatunk néhány olyan esetet, ahol a goto-knak meg lehet a maguk helye. A leggyakoribb eset, amikor a feldolgozást valamilyen mélyen skatulyázott szerkezet belsejében akarjuk abbahagyni oly módon, hogy egyszerre két, egymásba ágyazott ciklusból lépünk ki.
-
pmonitor
aktív tag
válasz
buherton
#6293
üzenetére
Ki mondta, hogy tömegesen kell a goto-t használni?
Te is tömegesen használtad a kódodban. De pl. amit jattila48 linkelt, ott is tömegével használják. Goto hegyek, hová legyek?
Azok a nevek C-ben dolgoztak? ... csak annyi maradt meg hogy BASIC, meg Pascal?!
Személyesen László Józsefet idéztem, aki ezt írta:
A goto utasítást a Pascal-ban nem használjuk, mert ugye programozók vagyunk.Egyenesen azt mondta, hogy aki Gotot használ, az nem programozó(mondjuk nekem mondhatja, mert én tényleg nem vagyok az, tehát én használhatnék goto-t
). Igaz, hogy Pascal-ra mondta, de gyakorlatilag a goto minden nyelvben ugyanazt csinálja(már amelyikben létezik, ugye). -
jattila48
aktív tag
válasz
pmonitor
#6291
üzenetére
Mintha kicsit gondjaid lennének a formális logikával. Abból, hogy A-ból következik B, még B-ből nem következik A. Pedig többször ezt a sémát használod érveléseidben.
"léteznek olyan problémák, amiket ott is csak egymásba ágyazott if-ekkel lehet megoldani."
És? Senki nem állította ennek az ellenkezőjét. Abból, hogy vannak olyan problémák (C hibakezelés), amit egymásba ágyazott if-ek helyett goto-kal érdemes megcsinálni, még nem következik, hogy minden probléma ilyen. Tehát ettől lehet olyan probláma, amit egymásba ágyazott if-ekkel célszerű (vagy azzal lehet) megcsinálni. Hol itt az ellentmondás? Miért kérsz számon olyan állításokat, amit a másik fél nem mondott? Ha én azt mondom, hogy A-ból következik B, akkor miért kéred számon, hogy mért mondok olyan butaságot, hogy B-ből következik A? Én ilyet nem mondtam, meg a többi vitapartnered sem.
-
buherton
őstag
válasz
pmonitor
#6291
üzenetére
*leírom ismét, amit eddig leírtam a goto-ról és annak használhatóságáról*
Azért legyünk őszinték: sem a tömeges goto, sem az egymásba ágyazott if nem szép.
Ki mondta, hogy tömegesen kell a goto-t használni?
Azok a nevek C-ben dolgoztak? Nem emlékszem már kikről van szó, csak annyi maradt meg hogy BASIC, meg Pascal?!
Továbbra sem értem, hogy miért kell az almát a körtével összehasonlítani.
-
pmonitor
aktív tag
válasz
buherton
#6290
üzenetére
Teljesen más a programozási filozófiánk.
A goto esetleg hatékony, de semmiképpen nem egyszerűbb. Elég megérteni, hogy mikor mit csinál. Azért legyünk őszinték: sem a tömeges goto, sem az egymásba ágyazott if nem szép. De valahogy meg kell oldani egy adott feladatot.Komoly neveket említettél, de sztem. én is(csak én nem neveztem meg személyeket, csak azt amit alkottak).
Hiába írod le még egyszer az oop nyelvekre vonatkozó gondolataidat. Ettől függetlenül léteznek olyan problémák, amiket ott is csak egymásba ágyazott if-ekkel lehet megoldani. Attól függetlenül, hogy vannak olyan eszközei, amiket leírtál(azokkal sem lehet mindent megoldani). Erre írtam példának a Java-t, amiben nincs is goto, tehát ott eleve kizárt még a lehetősége is a használatának. Pl. C#-ban sztem. van goto, de sosem néztem meg, mert minek? Én semmiképp nem használom, az biztos.
-
buherton
őstag
válasz
pmonitor
#6285
üzenetére
Rendben, vegyük végig.
Hiába mutattuk meg, hogy a goto hatékony, továbbá egyszerűbben és hatékonyabban le lehet írni valamit gotoval, mint a nélkül. Nem fogadtad el és ütötted tovább a vasat.
Hiába lettek komoly nevek megemlítve a Linux területéről, akik mérvadónak számítanak a szakmában. Nem fogadtad el és ütötted tovább a vasat.
Most olyan nyelvekkel jössz, aminek minimális, de inkább semmi köze sincs a C-hez vagy annak a filozófiájához, de mégis jön a méricskélés és az összehasonlítás, meg a bezzegek.
Leírom még egyszer: Az objektumorientált nyelvekben azért nem kell a goto, mert ott a class destructor-ral meg constructor-ral ezeket szépen le lehet írni. Vagy ha azokkal nem is, akkor még mindig lehet exception-t dobni. Sőt, kiegészítem a funkcionális programozással, ami már non plusz ultra.
Ha most ebben is megfogunk, akkor mi lesz a következő?
-
-
buherton
őstag
válasz
pmonitor
#6282
üzenetére
Almát a körtével? Most komolyan? Jó, menjünk bele. Az objektumorientált nyelvekben azért nem kell a goto, mert ott a class destructor-ral meg constructor-ral ezeket szépen le lehet írni. Vagy ha azokkal nem is, akkor még mindig lehet exception-t dobni. A C-ben nincs ilyenek, így marad a goto.
Nem értem a motivációdat btw.
-
pmonitor
aktív tag
válasz
buherton
#6279
üzenetére
Ha már ilyen provokáló választ írtál, akkor reagálok. Kérdésre kérdéssel válaszolok:
Szted. a Java megalkotói nem tudnak programozni? Mert a nyelvben nem létezik a goto utasítás. Ciklusokra van egy kibővített tulajdonsággal rendelkező break, viszont if-es feltételes szerkezetre NINCS. És mégis meg tudnak Javaban is oldani mindent.Sztem. azért ha olyan nyelv is életben tud maradni, amiben nincs goto, akkor érdemes elgondolkodni rajt, hogy tényleg szükség van-e goto-ra.
-
#90088192
törölt tag
válasz
kovisoft
#6280
üzenetére
Mindig valami új, azért érdeklődöm, mert tirisztor gyújtás szöget akarok kiszámolni a szinusz hullám integrálásával ami megadott kimenő teljesítmény mellett értendő
A másik pedig egy inverter IGBT gyujtasa ami impulzus alapon nyugszik, vagyis egyfajta kvantalast akarok csinálni.Tudom ez nem C de a matek igen, hiszen egy processzor lesz megbízva a számítással.
Köszönöm
-
kovisoft
őstag
válasz
#90088192
#6278
üzenetére
Igazából processzor típusonként és C fordítónként is változhat, hogy melyik milyen algoritmust használ. De az eléggé általános, hogy valamilyen gyorsan konvergáló iteratív algoritmussal történik, nem pedig táblázatból olvassák ki. Régebben, még az FPU-k előtti időkben volt inkább jellemző pl. játékprogramokban a táblázatok használata, ahol nem volt szükség nagy pontosságra, viszont nagyon gyorsnak kellett lennie.
-
buherton
őstag
válasz
pmonitor
#6269
üzenetére
Ühüm, szóval azt mondod, hogy Jonathan Corbet, Alessandro Rubini, és Greg Kroah-Hartman buták, akik nem tudják hogyan kell programozni?
Továbbá leírtam azokat az eseteket is, amikben a példád elbukik. Mindezek ellenére csak azért is kötöd az ebet a karóhoz, hogy a goto rossz.A laposföld-hívőkkel nem tudok mit kezdeni így feladom. Ezzel együtt felveszem az interjú kérdéseim közé a goto kérdéskört, mert többet ér az idegrendszerem ennél.
Igen, kirekesztő vagyok, mert kirekesztem a másként gondolkodókat
![;]](//cdn.rios.hu/dl/s/v1.gif)
.#6275 pmonitor: Most már ha felverted a port magad körül, ne fuss el.
-
-
kovisoft
őstag
válasz
#90088192
#6272
üzenetére
A processzorok általában egy speciális iterációs algoritmussal számítják ki a szögfüggvényeket. Ezt úgy hívják, hogy CORDIC, aminek az az alapja, hogy a szöget felbontják olyan kisebb szögek összegére, amiknek a tangense 1/kettőhatvány. Az ilyen szögekkel történő forgatásnál a szorzást shifteléssel lehet helyettesíteni, ezért lesz hatékonyabb ez a módszer a Taylor-sor használatánál.
-
pmonitor
aktív tag
válasz
sztanozs
#6274
üzenetére
Lehet, hogy nevemfel csinálta jól. A #6199-#6200-as hsz-ében leírta a véleményét, aztán befejezte. De ha én is ezt csináltam volna, akkor meg nem jutottunk volna el az előző kódokhoz.
Na mind1. Az biztos, hogy én a goto ellenesek táborába tartozom. És ha valaki nem ír olyant, amivel válaszkényszert generál részemre, akkor én is megpróbálom nevemfel viselkedését követni.
-
pmonitor
aktív tag
válasz
sztanozs
#6270
üzenetére
Kijelentettem. Nem vitatkozok. Főleg nem győzködök. Mint láthatod, megírtam a kódot. Nekem hasznos időtöltés volt, mert megpróbáltam megérteni az olyanokat, akik annyira oda vannak a goto-ért. Nem árt, ha az ember tanul más szemléletmódot is, még akkor is, ha nem szimpi. Már nem tudom ki írta, meg betű szerint nem is tudom idézni, de megpróbálom: "Programozni annyi, mint megérteni valamit". Teljesen igaza van.
-
#90088192
törölt tag
válasz
buherton
#6268
üzenetére
Akkor atfogalmazom, a processzor egy megadott szögből, képes-e kiszámolni a hozzá tartozó értéket a szögfüggvénynek megfelelően, vagy csak táblázatból lesi ki? Ez a kérdés magában a C nyelvben is. Van e egy táblázat amiből kilesi, vagy van rá eljárás ami ki tudja számolni/meg tudja közelíteni?
-
pmonitor
aktív tag
válasz
buherton
#6263
üzenetére
Mondjuk sztem. ez az if mélység még nem veszélyes(értelmezés szempontjából).
De itt is működik új változó bevezetésével az, hogy ha még tovább kellene mélyíteni, akkor a változó(mint kapcsoló) "beállításával" lehet követő if-ben rendezni a további feltételeket.
Nekem is azért nagyon oda kellett figyelnem, hogy ezt a goto-val tele kódot megértsem egyáltalán, hogy mi miért is van. És még így sem biztos, hogy sikerült. Ezért írtam, hogy nem biztos, hogy ekvivalens. Úgyhogy nekem meg a goto-kkal teletűzdelt kód antipattern. -
buherton
őstag
válasz
#90088192
#6266
üzenetére
Vagy nem teljesen érthető a kérdésed, vagy nekem vagy nagyon hétfő.
Ha jól azt szeretnéd elérni, hogy ne kiszámolja, hanem rögtön adja vissza az értéket, ugye? Gondolom ez a sebesség miatt kell.
A lookup table-re keress rá. Ezt sokféleképpen lehet implementálni. Talán a legegyszerűbb, hogy minden fokra legenerálod előre egy tömbbe és majd arra hivatkozol. Valahogy így:
const float degree_to_sin[] ={0, /* 0 degree */0.017, /* 1 degree */...};float res = degree_to_sin[1]; // res = sin(1)Persze ilyenkor a pontossággal lehetnek gondok.
-
jattila48
aktív tag
válasz
#90088192
#6266
üzenetére
Tudtommal az Intel processzorok tartalmaznak transzcendens (sin, log,...) floating point műveleteket. Egyébként valószínűleg vegyesen használnak táblázat adatokat, és közelítéseket. Igen hatékony tört közelítések léteznek ezekre. A szögfüggvények hatványsorai ugyan gyorsan konvergálnak, de tudtommal nem ezeket használják. Lehet, hogy táblázatból kikeresik a legközelebbi érték sinusát, majd az akörüli Taylor sor néhány tagjából egy törtet számítanak ki. Ez csak tipp.
-
#90088192
törölt tag
Nekem lenne egy kérdésem: a szög függvény számítható dolog, vagy adathalmazként van tárolva?
Értem ez alatt, hogy a pl Sin 45 az 0.707.
Tömbben van tárolva és arra hivatkoznak az elérhető könyvtárak vagy van valami módja annak hogy több adat bevonása nélkül kiszamoljuk? -
jattila48
aktív tag
válasz
pmonitor
#6262
üzenetére
Nem a felmenőidet emlegettem! Ezek szerint nem ismered ezt a vicces kis mondatot, aminek tagadását formális logikai feladatnak szokták adni. Írhattam volna a saját nagynénimet. Tartalmilag értelmetlen, éppen ezért sok embernek okoz gondot a tagadása. Másrészt példa arra, hogy hamis előtagból bármi következik. Vagyis, ha száműzzük a goto-t, akkor lehet száműzni a return-t is.
-
buherton
őstag
válasz
pmonitor
#6260
üzenetére
Nem használok 2-nél mélyebben if-eket, mert annál több pont az ellenkezőjét éri el.
A verziód azért nem jó, mert:
- ha a 'this' megváltozik, akkor a unreg-es párját több helyen is át kell írni
- ha új resource jelenik meg, mint modjuk a 'these', akkor lehet copy-pastelni és +1 mélységet kap ez a csoda if szerkezet
- antipattern és jobb helyeken az ilyeneket be sem lehet szállítani, mert a checkerek megfogják -
jattila48
aktív tag
válasz
pmonitor
#6258
üzenetére
Azta q*va! Komám, te aztán tényleg nagy mestere vagy a csúsztatásnak!
Ezt írtam: "Ennyi erővel a return utasítást is száműzni kéne, mert a fv. közepéből kiugrasz a fv. törzsből ".
Szerinted itt bajom volt a fv. törzs közepében elhelyezett return-nel? Ez pont azt jelenti, hogy ha a goto-t száműzzük, akkor a return sem kéne meghagyni, mert az is ugyanúgy megtöri a struktúrált szerkezetet, mint a goto általi hibakezelés. Vagyis egyiket sem kell száműzni. Tudod, ha nagynénédnek kerekei lennének, ő lenne a miskolci gyors...
Egyébként buherton kódjához egyáltalán nem szóltam hozzá, ha nem vetted volna észre. -
jattila48
aktív tag
válasz
pmonitor
#6251
üzenetére
Hát már csak tudom, hogy mit írtam, és mit gondoltam! Nehogy megmagyarázd már! Most már kezdesz bosszantani!
"jattila48 is elismerte, hogy a szóban forgó kód jobb, mint a tiéd."
Márpedig én ilyet nem írtam. Nem jobb, hanem az is jó. Leglábbis logikailag. Dabadab kritkája pedig másra vonatkozott, amiben igaza is van. Remélem érted, mi a különbség. Szóval nem csúsztatsz, hanem hazudsz.
Azt ismertem el, hogy struktúrálttá alakítottátok a kódot, ami azért nem egy nagy érdem. Nem a kód szép, hanem a szépen arra vonatkozott, hogy könnyen (==szépen, egyszerűen) lehetett struktúrálttá alakítani. És ezennel egyértelműen kijelentem, hogy a struktúrált kód nem lett szép (==könnyebben értelmezhető mint a goto-s kód), főleg nem szebb, csak logikailag ekvivalens az eredetivel.
A csúsztatásokat pedig légy szíves hagyd abba! Vagy a szövegértelmezéssel vannak problémáid, vagy csak egyszerűen kötekedni akarsz.
Nem libsi újságíró vagy véletlenül? Azoknál tipikus ez az attitűd. -
pmonitor
aktív tag
válasz
buherton
#6253
üzenetére
Ezt kalkuláltam ki:
int __init my_init_function(void) {
int err = register_this(ptr1, "skull");
if (!err)
{
err = register_that(ptr2, "skull");
if(!err)
{
err = register_those(ptr3, "skull");
if (err)
{
unregister_that(ptr2, "skull");
unregister_this(ptr1, "skull");
}
} else {
unregister_this(ptr1, "skull");
}
}
return err;
}Lehet, hogy még nem teljesen ekvivalens, de a logika látszik benne.
-
buherton
őstag
válasz
pmonitor
#6235
üzenetére
[centralized-exiting-of-functions]
vagy
int __init my_init_function(void) {int err;/* registration takes a pointer and a name */ err = register_this(ptr1, "skull");if (err) goto fail_this;err = register_that(ptr2, "skull");if (err) goto fail_that;err = register_those(ptr3, "skull"); if (err) goto fail_those;return 0; /* success */fail_those: unregister_that(ptr2, "skull");fail_that: unregister_this(ptr1, "skull");fail_this: return err; /* propagate the error */}amikor nem tudtad másképp megoldani?
Jaj, az annyira olyan ez a kérdés. Lehet programozni if-else nélkül is. Lehet programozni for, while, do-while nélkül is, de nyilvánvalóan nem érdemes. -
pmonitor
aktív tag
válasz
dabadab
#6249
üzenetére
Ha a 300-301. sorban látod, hogy goto out; , akkor honnan tudod, hogy az hova ugrik? "Csak" 170 sort kell lejjeb "tekerned", hogy megtudd, hogy az out mit csinál. Addig csak sejtheted(a neve alapján).
@jattila48:
Nem csúsztattam. Az egyértelműen látszott, hogy dabadab mellett vagy. De az is igaz, hogy a #6216-ban ezt írtad:
A #6179 példa valóban jó, de dabadab kritikájában is van azért igazság, annál is inkább, hogy ennél az egyszerű szerkezetű példánál sokszor bonyolultabb a vezérlésszerkezet, amit nem lehet ilyen szépen struktúrálttá alakítani.Ezért nem csúsztatás, amit írtam. Ez nem az az eset, hogy túl finoman fogalmaztál, hanem egyértelműen elismerted, hogy ez egy szép, struktúrálttá alakított kód. Csak most változtattad meg a véleményed.
Egyébként nem csak téged nézett le, hanem a felsorolásból kihagytam Livius-t és nevemfel-t. Legalábbis itt a topic-on belül. Nézd meg légyszíves nevemfel #6199-es hsz-ét.
És ki tudja, hogy hány embert nézett le az olvasók között. -
jattila48
aktív tag
válasz
pmonitor
#6242
üzenetére
Légy szíves ne csúsztass! Nem azt mondtam, hogy az a kód jobb mint dabadabé, hanem csak annyit, hogy logikailag az is jó. Dabadab kritikája pedig jogos, csak úgy látszik túl finoman fogalmaztam. Azt próbáld megérteni, hogy senki nem mondta, hogy bizonyos esetekben a goto-t nem lehet elkerülni. Mindig el lehet kerülni, csak nem mindig célszerű. Vannak olyan helyzetek (tipikusan a dabadab által bemutatott C hibakezelés), amikor "bűn" a goto kiirtásán görcsölni. Másik eset, amit kovisoft említett, hogy ha egy régi, mások által írt (legacy) kódban kell túrkálnod, akkor a legkevesebb kárt úgy teszed, ha kényszerűen goto-kat használsz, ahelyett, hogy mások átláthatatlan struktúráiba próbálnál belepiszkálni.
Legtöbben igyekszünk elkerülni a goto használatát (ez egy javasolt gyakorlat), de nem minden áron. Én pl. igen ritkán használom, csak a dabadab által mutatott C hibakezeléskor. Akkor viszont ez az ajánlott pattern. Tényleg nem akar senki megbántani (én aztán főleg nem), de amint látod, vagyunk itt páran, akiknek szakmája a programozás, és feltehetően jóval nagyobb a tapasztalatunk mint neked. Ez persze nem ultimate érv, de hogy el se gondolkozz azon, hogy esetleg nem Te mész-e szembe az autópályán... ez bizony jókora önbizalomra vall. -
pmonitor
aktív tag
válasz
kovisoft
#6247
üzenetére
Egy olyan kódot, mint ami itt a 272-473 sorok között van(vagy ennél hosszabb függvény) kódot így sem, úgy sem lát át utólag senki, akármennyire az olvashatóság jegyében íródott, nem az akadémiai szempontok szerint. Tehát így is úgy is, megizzad vele, aki ezt utólag át akarja látni. Még ha az nézi, aki csinálta, ő is beleizzad.
-
kovisoft
őstag
válasz
pmonitor
#6244
üzenetére
Pedig mondott érveket, csak azokat a részeket rendre ignorálod.
És abban is teljesen igaza van, hogy 1 emberes home projektes tapasztalattal a hátad mögött nem látod át, hogy milyen egyéb szempontok merülnek fel egy több millió kódsorból álló, akár 100+ programozó által évtizedek alatt megírt, sok különböző ügyfél újabb és újabb igényeit kielégítő, folyamatosan változó rendszer programozása során. Amikor akkora a rendszer, hogy senki sem látja át részleteiben annak minden elemét, amikor az eredeti kód készítői már rég nincsenek a cégnél, amikor ha nem értesz valamit a kódban, akkor nincs is kitől megkérdezned, hogy mi volt a szerző (majd az eredeti kódot módosító tucatnyi más programozó) eredeti szándéka, stb. Ilyenkor nem az akadémiai szempontok a legfontosabbak, hanem hogy a kód minél olvashatóbb, minél könnyebben értelmezhető és karbantartható legyen.
-
pmonitor
aktív tag
válasz
sztanozs
#6245
üzenetére
Egy példát tudnál mutatni? Mert amit én a #6219-ben írtam példát, ott egyetlenegy szinttel mélyült csak, nem többel. De ha a #6233-ban lévő behúzást használnánk, sztem alig lehetne ezt is észrevenni.
Meg a tapasztalatom szerint inkább ilyen szerkezetek lesznek:
if(feltétel1 || feltétel2 || feltétel3)
{
}Tehát inkább csak az if-ben növekszik a feltételek száma, nem a feltétel mélysége. Általában VAGY, de ritkán előfordul ÉS kapcsolat is.
-
-
válasz
pmonitor
#6242
üzenetére
Bocs, de tényleg nem merül fel benned az, hogy ha nulla tapasztalattal akarsz valamit megmagyarázni olyannak, aki nagyon régóta ezzel foglalkozik, hogy esetleg nem neked van igazad és érdemes lenne legalább megfontolni, amit mond?
És nem, baromira nem szubjektív. Addig érezheted mindegynek, hogy mi hova kerül, amíg nem látod át, hogy azok mit jelentenek. Onnan kezdve viszont nagyon is objektíven értékelhető lesz a dolog.
A 6179-nél például azt nem érted, hogy a vezérlési szerkezet a program lefolyásáról is beszél, márpedig ott mást mond, mint ami a tényleges helyzet.
-
pmonitor
aktív tag
válasz
dabadab
#6240
üzenetére
Az, hogy mennyire olvasható, az nagyon szubjektív dolog. A következő példát mondom rá:
#6216 hsz-ében jattila48 is elismerte, hogy a szóban forgó kód jobb, mint a tiéd. Pedig a te oldaladon állt, mert azt írta, hogy:
>A #6179 példa valóban jó, de dabadab kritikájában is van azért igazságEz egyértelműen tükrözi, amit az előbb írtam. Na ennyire szubjektív, hogy 1 kód mennyire "jó"(a te szavad járása szerint). Aki melletted van, még ő is azt mondta, hogy a szóbaforgó kód jó.
Zárójelben jegyzem meg, hogy szerintem ha csak az olvashatóságot nézzük, akkor az én 2 return-os kódom a legolvashatóbb. Mert a return egyértelműen jelzi, hogy itt nincs mese, kilépés van a függvényből.
De mint mondtam, ez nagyon szubjektív dolog.
-
válasz
#90088192
#6224
üzenetére
A számítástudomány az tényleg sokkal előrébb járt, mint maguk a számítógépek, George Boole (a Boole-algebra (a számítógépeknél alkalmazott logika) megalkotója halála után még majdnem egy évszázadott kellett várni az első digitális számítógépre, az információelméletről meg Shannon kb. mindent elmondott az 1940-es években.
A GOTO-problematika viszont nem ide tartozik, az színtisztán gyakorlati kérdés - azt Ada Lovelace nem láthatta előre, amikor Babbage gépére talált ki pár soros programokat, hogy milyen érzés lesz olyan kódot túrni, amit egy tíz évvel ezelőtt más céghez távozott kolléga írt
Az, hogy feltétlenül kell egy olyan utasítás, ami megváltoztatja a program végrehajtási helyét, az soha nem is volt kérdés, persze, hogy kell. Sőt, több is kell, mert olyanok is kellenek, amik különféle feltételek alapján változtatják meg.
Az összes processzorban vannak ilyen utasítások, senkinek semmi baja nincs ezzel, senki nem akarja kiírtani, vagyis tulajdonképpen bármilyen program fut a gépeden az tele van JMP-kkel (a GOTO gépi kódú megfelelőjének ez a mnemonikja).
Viszont a magasabb szintű nyelvekbe ezt egyre inkább becsomagolták, mint ahogy minden egyéb ilyen nyers dolgot is, hiszen a programozók általában nem arra vágynak, hogy megváltoztassák a programszámláló tartalmát, mert csak, hanem valamilyen összetett struktúrát hoznak létre: hurkot, feltételes programvégrehajtást, ilyeneket. Márpedig ha ők ilyeneket akarnak létrehozni, akkor adjunk a kezükbe olyan eszközöket, amikkel ezt csinálják közvetlenül, ahelyett, hogy JMP-vel bohóckodnának.
Ezzel együtt a GOTO megmaradt egy csomó magasabb szintű nyelvben is, egyszerűen azért, mert az azokban meglévő struktúrák lefedték a GOTO-használat nagyon-nagyon-nagy részét, de nem az összeset, így aztán maradtak olyan helyek, amikor az ember azt használja, mert adott esetben nincs jobb megoldás rá.
-
válasz
pmonitor
#6239
üzenetére
Már megint nem érted.
Senkit nem érdekel az, hogy hány goto van a programban, az az érdekes, hogy mennyire olvasható.
Én a 20+ éves pályám nagy részében olyan, sokmillió kódsoros rendszereken dolgoztam, amik másfél-két-két és fél évtized alatt programozók tucatjai írtak és írtak át. Ebből kifolyólag rengeteget olvasom és módosítom mások kódját és ennyi idő után azért eléggé el tudom dönteni, hogy mi az, ami jól olvasható, a programozó szándékát tisztán kommunikálja és könnyű karbantartani, meg mi az, ami nem az.
A fenti megoldásokkal mind az volt a baj, hogy az eredeti gotos megoldásnál a fenti szempontokból nem hogy nem voltak jobbak, de kifejezetten rosszabbak voltak.
-
pmonitor
aktív tag
-
pmonitor
aktív tag
válasz
dabadab
#6236
üzenetére
A fenti példád nem mutatta meg. Csak sajnos nem én mutattam rá(elkapkodtam a dolgot), hanem a munka oroszlánrészét #6172-ben Livius végezte el(ő használta legjobban a szürkeállományát). És #6179-ben nevemfel tette fel az i-re a pontot. Azt, hogy hogy kell az ilyent megcsinálni. A kódod azt mutatta meg, hogy hogyan ne.
-
-
buherton
őstag
válasz
pmonitor
#6231
üzenetére
Az egyetemi elmélet és a gyakorlat jellemzően nincs párban.
Ott az OpenFlow, amiről 1001 publikáció készült, de a gyakorlatban kb senki nem használja.
A legtöbb network protokoll is fantasztikus elméleti háttérrel rendelkezik, de a gyakorlati alkalmazásban már megy a tákolás, mert pl. a biztonságra nem gondoltak az akadémikusok. Erre kiváló példa az IPv6, vagy nagyjából az összes network protokoll.
Úgy érzem, hogy itt is egy hasonló vita alakult ki. Van egy ékesnek tűnő elképzelés, ami egyetemi keretek között maradéktalanul megállja a helyét, de a gyakorlatban már nem mindig tartható mindenféle olyan okból, ami az egyetemen nem is létezik.
Csak néhányszor írtam le goto-t az elmúlt 7 év alatt, de annak jó oka volt. Egyébként én sem pártolom a használatát, de néha nagyon jól jön.
-
pmonitor
aktív tag
válasz
kovisoft
#6232
üzenetére
Ki mit szokott meg. Nekem pl. teljesen idegen ez a behúzás:
if (!raw)
{
utasítás1;
}Tehát hogy a blokk elejét-végét jelző kapcsos zárójelet is behúzzák.
Én inkább így szoktam:if (!raw)
{
utasítás1;
}Vagy pl. Javascriptben:
if (!raw) {
utasítás1;
}Így sokkal több behúzást könnyebb megérteni számomra.
-
-
pmonitor
aktív tag
válasz
#90088192
#6228
üzenetére
Ebben a témakörben én egyértelműen az ELTE-vel értek egyet(pedig az egyetemekről sem jó a véleményem ÁLTALÁNOSSÁGBAN). Egyébként meg minden esetben el lehet kerülni a használatát. Ez alól nincs kivétel. Az viszont igaz, hogy néha plusz változó(kat) kell bevezetni, de még így is áttekinthetőbb, mint a goto.
-
#90088192
törölt tag
válasz
pmonitor
#6227
üzenetére
Látod, a lényeg Nem ajánott, abból semmilyen logikával nem következik a tiltott.
Vagyis aki tudja elkerülni, de ez nem azt jelenti hogy nem lehet használni. Ezért vaskalapos és hibás az ELTE logika.
Csak ezt nehéz beismerni.
Tudod tekintély elvű marhaság.
El lehet mondani, hogy próbáljuk ne használni, de ha épp az a legegyszerűbb, legolvashatobb megoldás, akkor miért ne?
Én elkezdtem C Ben illeszto programot írni PIC re, érdekes, nekem eszembe sem jutott GOTO-t használni pedig előképzettség részemről 0.
Van amit nem lehet tanítani, max megérteni.
Ezért tartom marhaságnak a tiltást.
A legtöbb okos sokkal többet tud mint amit valójában megért, mert bemagolt frazisokat hajtogatva okosnak lehet tűnni. Nem azt jelenti, hogy érti is miről beszél
(nem személyes, nem neked szól, ne vedd magadra kérlek ) -
pmonitor
aktív tag
válasz
#90088192
#6226
üzenetére
Idézet innen: > Ezekben a különböző számítógépeken futó BASIC programok szinte mindig inkompatibilisek voltak egymással: az egyik géptípusra írt programot más számítógéptípusokon nem lehetett futtatni.
Ez azért nem a magas szintű nyelvekre jellemző tulajdonság. Továbbá: > Az 1990-es évek elejére sokan leírták a Basicet, mivel a Basic alapú mikroszámítógépek kora lejárt, PC-n a C/C++ és a Pascal nyelvek vívtak ki vezető szerepet.
Igazából nem csak sokan leírták a BASIC-et, hanem a valóságban meg is szűnt. A Visual Basic már nem BASIC, csak BASIC-alapján készült. De már a Visual Basic is inkább csak a VBA-ban létezik. A Vb.Net meg egészen más dimenzió.
sztanozs elítélt, mert pascal témakörben készült irományokból idéztem. De ezek az idézetek nem csak a Pascal-ra vonatkoznak, hanem általánosan is igazak. Mint ahogyan írták, Pascalban nincs is return. Ettől függetlenül lehet a függvény törzsében is értéket adni a függvénynek a
függvénynév:=valamiformátumban(ej, de régen Pascaloztam). De látható, hogy a C-hez viszonyítva ennyivel szigorúbb nyelvben is tiltják a Goto-t(alapból nem is lehet használni benne, csak direktívával lehet bekapcsolni).De ha mindenképpen ragaszkodunk ahhoz, hogy csak szigorúan C nyelvre létrehozott irományokat fogad el valaki, akkor az olyannak meg itt van ez. Itt ezt írja:
> A strukturált programozást a goto utasítás elkerülésére, a program olvashatóbbá tételére találták ki, ezért a goto használata egyáltalán nem javasolt.Ezt direkt a C nyelvre írták(nem Pascal-ra).
A "ma" használt nyelvek között már a BASIC nem található meg. Sőt, az ismertebb nyelvek közül pl. a Java-ban nem is létezik a goto. Ebben a nyelvben pl. a #6219-es hsz-emben írt kódot nem is lehetne megírni. Java-ban a break-nek van 1 olyan "kibővített" funkciója, hogy egymásba ágyazott ciklusok esetén label használatával meg lehet adni, hogy a break melyik ciklusra vonatkozik. De ez nem egyenlő a goto-val(amivel össze-vissza LEHET ugrálni).
Szóval akárhol nézegetek utána, mindenhol a legfinomabb megfogalmazás is az, hogy nem ajánlják a használatát.
-
#90088192
törölt tag
válasz
pmonitor
#6225
üzenetére
Nekem a BASIC magas szintű az ASM és a gépi kodhoz hasonlítva. Nem tudom hol a határ, de nem volt megerőltető a BASIC Ben való programozás. Az ASM viszont tortúra számomra már látvány szinten, így sosem volt hozzá szerencsém.
A csaj és Marcsa esetén a végeredmény ugyan az
Megszabadulhat az ember pár gramm feherjetol.
-
pmonitor
aktív tag
válasz
#90088192
#6224
üzenetére
BASIC != Visual Basic. A BASIC nem magas szintű nyelv(legalábbis ez alapján). Amit írsz, hogy pont azért olyan amilyen, hogy Egyszerű legyen használni, ez a Visual Basic-re igaz. A BASIC-et nem volt 1szerű használni. Ha azt látod, hogy
GOTO 100, akkor honnan tudod, hogy mi van a 100-as sorban? De szükség volt a GOTO-ra a sorok számozása miatt. A Visual Basic-et valóban 1szerű használni, de ott meg szükségtelen a GOTO használata. Tényleg csak hagyománytiszteletből maradt benne.Azért a marcsának és a csajnak nem ugyanaz az eredménye. Marcsánál nincs, ami olajozza/ápolja a matériát!
-
#90088192
törölt tag
válasz
pmonitor
#6215
üzenetére
Köszönöm, ami ismereteim illeti, én úgy tudom, a számítás tudomány jóval megelőzte a valós felhasználást (lásd belső égésű motorok, az összes típus fel lett találva, mielőtt azt meg tudták volna építeni), vagyis a matematika, strukturális alapok megvoltak már rég, főleg ha az alacsonyabb rendű nyelveket vesszük figyelembe. Hiszen a szövő gépet is programozni kellett. A logikai adott, ott sem volt GOTO.
Vagyis valamiért megjelent, a BASIC nagyon jó példa, pont azért olyan amilyen, hogy Egyszerű legyen használni.
Vagyis ezzel el is érkeztünk a GOTO lét jogosultságához.
Azért létezik kb minden program nyelvben, mert lehet maszturbalni, meg lehet egy gyönyörű csajjal szeretkezni. Mindkettő rendelkezésre áll, mindkettőnek ugyan az az eredménye. Persze lehet tiltani a csajt, maradj csak a marcsanal. De akkor minek vannak csajok? -
kovisoft
őstag
válasz
pmonitor
#6219
üzenetére
Ami részletet idemásoltál, abból nem nyilvánvaló, de itt az okokat jobban meg lehet érteni, ha megnézed a forráskód historyját. Ebből látszik, hogy eredetileg csak a switch volt ott, a goto és az előtte lévő rész hiányzott. Aki hozzáadta a raw függvényparamétert, az gondolom nem akarta, hogy az egyébként változatlan switch kompletten mint módosult kód jelenkezzen a historyban. Illetve (ami szintén nem látszik az idemásolt részleten) mivel a switch már így is elég nagy, eléggé tele van if-ekkel és eléggé be van indentálva, ezért az is lehet, hogy nem akart még egyet növelni az indentálás mértékén. Valószínűleg másképp csinálta volna, ha nulláról most írja meg az egész függvényt.
Szóval ez inkább a "történelmileg így alakult" kódra példa.
-
válasz
pmonitor
#6219
üzenetére
Ott mondjuk pont meg lehetne egyszerűen, bár szerintem ez a felírás egyértelműbb, mint ha a sswitch egy negált feltételben volna (egyébként szerintem amúgy is pont erre az alakra fogja fordítani a fordító). De "optimalizáld" ki lsz a 2921. sorban kezdődő switch-ből a goto-t, hogy ne nézzen ki nagyon csúnyán...
Ezek (mind a 300 sorban), mind később a switchben szemantikailag pont jól néznek ki:
ha (feltétel) ugorj a labelre
És amúgy itt sem látsz olyat, hogy a goto "összevissza" ugrálna, csak előrefelé. -
pmonitor
aktív tag
válasz
jattila48
#6218
üzenetére
Nem sértődtem meg. Nézzünk 1 nagyobb projektet. Ezt remélem elfogadod 1 nagyobb projektnek. Itt a 300. sortól ez van(csak a szerkezetet mutatom):
if (raw)
goto out;
switch (token->type)
{
.
.
}
out:
timevar_pop (TV_LEX);Ezt miért nem lehet így:
if (!raw)
{
switch (token->type)
{
.
.
}
}
timevar_pop (TV_LEX);??
A nagy projekt is lépésekből épül fel.
-
jattila48
aktív tag
-
pmonitor
aktív tag
válasz
jattila48
#6216
üzenetére
>A hozzászólásaidból az jön le, hogy kezdő vagy a programozásban (ez persze egyáltalán nem baj), és nem írtál még igazán nagyobb programot.
Nem kezdő vagyok, hanem egyszerűen nem vagyok programozó, ez miatt kezdő sem.
Az előéletem megnézheted itt, ahol azért 1-2 kérdésre válaszoltam.De ha a referenciáim érdekelnek, akkor többek között ezek, valamint ezek, továbbá ezek a publikus kódjaim, amelyek között van nagyobb is(persze relatív, hogy mi az az igazán nagyobb program?).
Neked mik a referenciáid/publikus kódjaid?
-
jattila48
aktív tag
válasz
pmonitor
#6213
üzenetére
A #6179 példa valóban jó, de dabadab kritikájában is van azért igazság, annál is inkább, hogy ennél az egyszerű szerkezetű példánál sokszor bonyolultabb a vezérlésszerkezet, amit nem lehet ilyen szépen struktúrálttá alakítani.
Egyébként nem tudom mit nem értesz meg, senki nem mondta, hogy ha lehet és ésszerű, akkor ne struktúrált szerkezetet használj. Csak arról írtunk, hogy nem mindig célszerű erőltetni a dolgot. Van ahol igenis helyénvaló a goto használata (C hibakezelés), a mindenáron történő struktúrált kikerülése pedig kifejezetten antipattern. A késsel is megvághatod magad, mégis használod pl. kenyérszeletelésre, ellenben fogpiszkálónak valóban nem a legalkalmasabb. Csak erről beszéltünk. Hogy mit írt Dijkstra több mint 50 évvel ezelőtt, az csak egy dolog. Akkor még nem volt eseményvezérelt és objektumorintált programozás, nem léteztek grafikus UI-k, stb. Az akkori környezetben teljesen helyénvaló volt a szigorú struktúrált programozási elv, ami egyébként az assembly/Fortran nyelvek kényszerű használatából adódó programozási krízis megoldására született. Az általa leírt struktúrált programozási elveket/szerkezeteket automatikusan (sémaszerűen) meg lehetett valósítani assembly és fortran nyelveken természetesen goto-k használatával. Azonban a probléma ott volt, hogy (mivel a nyelvekben nem voltak struktúrált szerkezetek beépítve), sokszor elég ötletszerűen (túl intuitívan) alkalmazták a goto-t. Másrészt a memóriával is spórolni kellett, úgyhogy ha volt egy már egyszer megírt programrészlet, egyszerűen goto oda, majd vissza... Na ennek a helyzetnek a kezelésére született Dijkstra (aki egyébként kiváló tudós volt) struktúrált programozás javaslata. Azóta a helyzet sokat változott. Részben születtek struktúrált szerkezeteket támogató programozási nyelvek, részben pedig ahogy írtam, az objektumorintáltság és eseményvezéreltség is előtérbe került (ezeket nem igazán lehet tankönyvszerűen struktúrált módon kezelni). A Dijkstra féle megközelítést most is érdemes szem előtt tartani, de eszetlenül erőltetni (goto kategórikus tiltása), szerintem butaság.
Végezetül engedj meg egy személyes megjegyzést, amit egyáltalán nem bántásnak szánok. A hozzászólásaidból az jön le, hogy kezdő vagy a programozásban (ez persze egyáltalán nem baj), és nem írtál még igazán nagyobb programot. Ragaszkodsz bizonyos (túlságosan is megkövesedett) elvekhez, amit a tanáraidtól tanultál, csak a gyakorlat sajnos más, mint a tankönyvi példák. Ha majd windows (Linux) rendszeren kell nagyobb programokat írnod, rájössz, hogy szépek az elvek, de időnként érdemes testreszabni őket. -
pmonitor
aktív tag
válasz
#90088192
#6214
üzenetére
Hogy miért találták ki? Hát pl. azért, mert a BASIC-ben pl. lehetetlen volt a programozás nélküle(ott még a sorok számozva voltak. De itt is írják:
> Léteztek olyan ősnyelvek, amelyekben nélkülözhetetlen voltHát többek között ezért. Na meg azért, mert akkor még nem bizonyították be, hogy GOTO nélkül mindent meg lehet oldani, nincs szükség rá.
Egyébként itt osztályozzák a programnyelveket, ahol látszik, hogy a C/C++ is magas szintű nyelv.
-
pmonitor
aktív tag
válasz
jattila48
#6211
üzenetére
Látom, hogy hozzászólásonként válaszolsz. #6181-ben leírtam, hogy nevemfel #6179-ben lévő megoldása a legjobb arra a feladatra(nem az enyém).
#6184-ben Stroustrup-ot idéztem, aki azt írta, hogy:
>A "soha ne tegyük ezt" alakú szabályokat haszontalannak tekintem.
A #6190-ben idéztem László Józsefet:
>A goto utasítást a Pascal-ban nem használjuk, mert ugye programozók vagyunk.
Majd a #6197-ben innen is idéztem 2 programnyelvtől független idézetet.A véleményem a #6209-ben foglaltam össze. A goto-cimke párossal összevissza lehet ugrálni, áttekinthetetlen lesz a kód tőle. Ha cimkét látsz, akkor egyrészt nem tudod, hogy fentről, vagy lentről tévedt oda a vezérlés. De azt sem tudod ránézésre, hogy amik utána vannak utasítások, azok micsodák(pl. a cimke 1 ciklus kezdetét jelzi-e, vagy egy - vagy több - if ágból ugrottak-e oda). Ugyanakkor, ha goto-t látsz, akkor sem tudod, hogy az a cimke felfelé, vagy lefelé ugrik-e. Az összevissza ugrálás lehetősége miatt mondom én azt, hogy a goto - cimke párost soha! Míg ha azt látod, hogy
while(f), akkor totózás nélkül, kapásból tudod, hogy mi következik(1 cimkével ellentétben).Én ugyan nem vagyok programozó, de remélem, hogy az ELTE-n(is) vaskalaposan ragaszkodnak a struktúrált programíráshoz, és tiltják a goto-t azokban a nyelvekben is, amelyekben még létezik. Mert ahogy a fenti linkemen is írják:
>a mai magasszintű nyelvekbe azonban többnyire hagyománytiszteletből került be, nincs rá szükség. (mármint a goto-ra). -
jattila48
aktív tag
válasz
pmonitor
#6168
üzenetére
"Biztos vagyok benne, hogy a megfelelő if-ek megválasztásával ha nem is teljesen..."
De, teljesen. Csak tök fölösleges, mert csak érthetetlenebb, nehezebben karbantartható, több hibalehetőséget magában rejtő lesz a kód. Tökéletesen egyetértek dabadab-bal, hogy lehet hülyén használni a goto-t, de ezért kategorikusan megtiltani, még nagyobb hülyeség lenne. A dabadab által mutatott példa abszolút tipikus a megfelelő goto használatra, az általad mutatott elkerülése pedig tipikus antipattern. Ennyi erővel a return utasítást is száműzni kéne, mert a fv. közepéből kiugrasz a fv. törzsből (kivéve a fv. végére írt return-t; Pascalban egyébként ezért nincs is return). Remélem az ELTE-n már nem ragaszkodnak ennyire vaskalaposan a struktúrált programíráshoz (mikor én végeztem ott, akkor még igen), mert a mai objektumorientált és eseményvezérelt programok korában részben egyszerűen idejétmúlt. Persze megvan a maga létjogosultsága a józanság keretei között. Hasonlóan értelmetlen káros vaskalaposság a globális változók tiltása. Mindent meg lehet írni globális változók nélkül, csak rengeteg fölösleges paraméterátadással, hibázási lehetőséggel jár, ha eszetlenül ragaszkodunk hozzá. Ha belegondolsz, a C++ osztályok tagfüggvényei számára az adattagok lényegében globális változók. -
pmonitor
aktív tag
válasz
sztanozs
#6208
üzenetére
A megerőszakolt while ciklus sztem. egyértelműbb(ha ennél a példánál maradunk), mint a goto. Mert a while ciklus esetén kapásból látod, hogy itt f értékétől függő ciklusról van szó. Ráadásul ugye ott még a code syntax(behúzás) is segít a megértésben. Ha egy cimkét látsz, akkor azt nem tudhatod, hogy fentebbről jövő if, vagy else, vagy alulról jövő ciklustól téved-e oda a vezérlés. Ráadásul a cimkéknél nem nagyon van syntax(behúzás), illetve ha van, az meg még rosszabbul olvasható. Ugyanakkor a for-ban lévő goto esetén sem tudod egyből megmondani, hogy az előre, vagy hátra ugrik-e. Szóval a megerőszakolt while esetén egyből látszik a szerkezet, míg goto esetén nem.
Azért a vb6/vba/vbs esetén amit linkeltél, az nem ugyanaz, mint a Try/Catch/Finally. Ezt is figyelembe kell venni. Egyébként ezek közül én csak az On Error Resume Next-et szoktam használni. De amit linkeltem, az a pascal program végén látható "A goto eredménye" című kép, az sztem abszolút nem nyelvfüggő. Másrészt meg én úgy tudom, hogy a C-t is a magas szintű nyelvek közé sorolják.
-
válasz
pmonitor
#6206
üzenetére
Mondjuk ha folyamatosan Pascal példát hozol, akkor én meg azt mondom, hogy Try/Catch hiányában nem lehet (értelmesen) error handlinget csinálni Visual Basic 6 (és VBA / VBS-ben) Goto nélkül: [link]
Most akkor egy platformon vagyunk, hogy tökre irreleváns magasszintű nyelvekben alkalmazott Goto megoldásokról vitatkozunk a C topikban?
-
pmonitor
aktív tag
válasz
sztanozs
#6205
üzenetére
Technikailag nem ugyanazt csinálja, mert az
// utasítások-ban lehet olyan is, ami átugorja a for és a while ciklust is egyben, vagy még hátrébb is mehet. Ezért értek egyet azzal az állásponttal, hogy goto-t soha, még ha durvább megfogalmazás is.Nézd meg légyszíves ezen oldal végén a "goto eredménye részt". Na ezért mondom, hogy gotot soha...
-
válasz
pmonitor
#6204
üzenetére
Mondjuk ha pont erre van szükséged, akkor a break-kel is ezt csináljuk:
int f = 1;
while (f) {
// utasítások
for (int i=k; i>l; i+=m) {
//még utasítások
if (feltétel) {
f = 0;
break;
}
}
Technikailag pont ugyanazt csinálja (és szerintem amúgy goto-val jobban is néz ki, mint ez a megerőszakolt while 1 ciklus...) -
pmonitor
aktív tag
válasz
sztanozs
#6202
üzenetére
Nem az implementációról beszéltem. Nem tudsz olyan kódot írni, hogy az implementációban break(vagy continue) legyen. Ott valóban minden goto(és ha tovább megyünk a kész kódra, akkor jmp) lesz. Arról a forráskódról beszéltem, amit a user ír. A példádban erről:
for (int i=k; i>l; i+=m)Itt a continue visszafelé lép a törzsből az "i+=m"-re. Míg a break csak előre lép, a törzs utáni helyre. break-el nem tudsz visszafelé lépni. A goto-val meg össze-vissza tudsz lépkedni(akár hátrafelé is ki tudsz lépni a ciklusból(aztán vagy újra belelépsz, vagy akkor már kihagyhatod a ciklust is). Pl.:
cimke_1:
//utasítások
for (int i=k; i>l; i+=m) {
//utsítások
goto cimke_1;
}Ilyent a break-el nem tudsz csinálni. Az, hogy az implementációban mi van, az más kérdés.
Szerk:
A break esetén megvalósul a szekvencia - iteráció elv. Szekvenciálisan mennek az utasítások, amíg egy ciklushoz nem érsz. A ciklus más dimenzió, mint a szekvencia. Viszont a break tartja a szekvenciát(hiszen előre ugrik. Tehát az iteráció előtt és mögött is megmarad a szekvencia. Persze közben lehet szelekció bárhol, de a példámat nem akartam annyira bonyolítani. -
buherton
őstag
-
válasz
pmonitor
#6197
üzenetére
Igazából azt sem tudom min vitatkozol...
Csak annyit írtam (viccesen), hogy ha a continue-t tiltják, akkor miért nem tiltják a break-et is... amúgy implementálva mind-mind goto (ráadásul az is előrefelé, nem hátra - pl for (int i=k; i>l; i+=m).// értékadás
int ix = k;
:loop_start
//kilépési feltétel
if n>l goto outside_of_loop;
/*
utasítások
*/
// continue
if condition_continue goto loop_increment;
/*
még utasítások
*/
// break
if condition_break goto outside_of_loop;
/*
még utasítások
*/
:loop_increment
i += m;
goto loop_start;
:outside_of_loop -
Livius
őstag
válasz
buherton
#6196
üzenetére
A National Instrument mérő hardverek 90%-a az Windows 10-re van komoly supporttal és driverekkel ellátva, ezért a saját CVI fordítójuk és IDE-jük volt sok 10 évvel ezelőtt már bevezetve hogy majd az jó lesz. Tehát nincs lehetőség, csak a Windows-ra, és sajnos az se nagyon könnyű eset, hogy az elavult C helyett mondjuk egy C#-ban történjen a GUI-s SW fejlesztés ebben a témában. A WSL2-öt amúgy ismerem, Yocto projectes Linux buildre már teszteltem, elég fasza kezd már lenni.
). Igaz, hogy Pascal-ra mondta, de gyakorlatilag a goto minden nyelvben ugyanazt csinálja(már amelyikben létezik, ugye).
Továbbá leírtam azokat az eseteket is, amikben a példád elbukik. Mindezek ellenére csak azért is kötöd az ebet a karóhoz, hogy a goto rossz.![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
(nem személyes, nem neked szól, ne vedd magadra kérlek 
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- A fociról könnyedén, egy baráti társaságban
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- PlayStation 5
- Videós, mozgóképes topik
- Azonnali notebookos kérdések órája
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Sony MILC fényképezőgépcsalád
- Samsung Galaxy S25 Edge - a tegnap határán
- ASZTALI GÉP / ALKATRÉSZ beárazás
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- Számítógép, ryzen 5 2600, RX 580 8GB, 16gb ddr4, 512gb ssd, 1tb hdd
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 16/512 Iris Xe FHD
- Gigabyte GeForce GTX 1660 Ti OC hibátlan, dobozos, 14 nap személyes garanciával
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD
- Playstation 5 Lemezes kiadás!
- Wimius W2 okosprojektor / Számla + Garancia / 30 000 Ft
- Huawei P20 64GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! Asus B450 R7 2700X 16GB DDR4 512GB SSD RTX 2070 8GB Rampage SHIVA Thermaltake 500W
- Lenovo V130-15IGM laptop (Pentium Silver N5000/8GB/256GB SSD
- Asus Zenbook 15 OLED UM3504 - 15.6" 2.8K 120Hz - Ryzen 5 7535U - 16GB - 512GB - 2+ év garancia
Állásajánlatok
Cég: FOTC
Város: Budapest