- Google Pixel topik
- Magisk
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
- Android alkalmazások - szoftver kibeszélő topik
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
Új hozzászólás Aktív témák
-
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.
-
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.
-
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.
-
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. -
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. -
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. -
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.
-
sztanozs
veterán
-
dabadab
titán
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.
-
dabadab
titán
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.
-
-
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.
-
#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 
) -
#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.
-
#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.
-
sztanozs
veterán
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é. -
jattila48
aktív tag
-
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. -
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. -
sztanozs
veterán
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?
-
sztanozs
veterán
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...) -
sztanozs
veterán
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 -
-
-
-
dabadab
titán
válasz
pmonitor
#6168
üzenetére
Akkor tessék, demonstráld:
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
{
int ret = -EINTR;
int idx = srcu_read_lock(&vcpu->kvm->srcu);
if (kvm_arch_vcpu_runnable(vcpu)) {
kvm_make_request(KVM_REQ_UNHALT, vcpu);
goto out;
}
if (kvm_cpu_has_pending_timer(vcpu))
goto out;
if (signal_pending(current))
goto out;
ret = 0;
out:
srcu_read_unlock(&vcpu->kvm->srcu, idx);
return ret;
}
![;]](http://cdn.rios.hu/dl/s/v1.gif)
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.
(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!
- PlayStation 5
- Autós topik
- Ubiquiti hálózati eszközök
- Az áremelések és a GTA VI késése miatt nem költekeznek a játékosok?
- Autóápolás, karbantartás, fényezés
- Google Pixel topik
- Hálózati / IP kamera
- Bluetooth hangszórók
- Megjelent a Red Magic kompakt OLED kijelzős gaming táblagépe
- Honda topik
- További aktív témák...
- Latitude 5550 15.6" FHD IPS Ultra 5 135U 16GB 512GB NVMe magyar vbill ujjolv IR kam gar
- Gamer PC , i7 10700 , RX 6700 XT 12GB , 32GB 3200MHz , 512GB NVME , 1TB HDD
- Eladó Konfig Ryzen 7 9700X 32GB DDR5 1TB SSD RX6900XT 16GB!
- Eladó Gamer PC i7 14700, RTX 5070, 32 GB 6000mhz RAM, Vizhűtés, 850W 80+ Táp, 2 év Garanciával
- Google Pixel 9 Pro 5G 16/256GB Szürke Színben Bontatlan 12 Hó Garanciával
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB DDR4 1TB SSD Radeon Pro 5500M garanciával
- Lenovo Legion Pro 5 16IRX9
- Bomba ár! Dell Latitude E7240 - i7-4GEN I 16GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Ultimate előfizetés új fiókra akár 2105 Ft/hó áron! Azonnali, automatizált aktiválással, csak Nálam!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged