Használsz programozáskor goto-t?

Programozás

Használok rendszeresen
3% (18 szavazat)
Használok, de csak akkor, ha tényleg azzal a legszebb (pl. legolvashatóbb) a megoldás
18% (114 szavazat)
Nem használok
62% (397 szavazat)
Nem programozok / nem tudok róla hogy az általam használt nyelvekben lenne goto
17% (112 szavazat)
Összes szavazat: 641

Egyébként a kettő között van az igazság: megfelelő méretű jól átlátható függvényekben a goto nem feltétlen ártalmas, van, hogy anélkül csak rondán lehetne valamit megcsinálni. Viszont sok problémát is be tud hozni. A continue, break, return egy elég kulturált megoldás az esetek nagy részére (kivéve a php-ben).

Ezt én is így gondolom. Continue és break-kel semmi gond sincs. Goto-t rendkívül ritkán használok. Ma már szinte csak C-ben dolgozom de régebben Asmban is toltam. Ott tele volt minden Jmp-vel. Én nem félek a goto-tól. Féljenek azok akik bizonytalanok a tudásukban. 97-es kódot is karban tartok, ami a mai napig használatba van és faszán üzemel.

--
GPLv3-as hozzászólás.

Nem tud label(l)ed break/continue-t a PHP, a többi nyelv (legalábbis Java biztosan) tud. Helyette ha kap egy számot maga után, akkor annyi vezérlési szerkezettel kijjebb szakít meg, végülis hasonló működés, meg minden megvalósítható így is, de miért pont ebben kell másképp csinálni ezt is? Meg a kód olvashatóságán se segít sokat, főleg egy nemPHP expert számára, de amúgy is olvashatóbb egy label szöveg, mint egy szám, hogy hánnyal kijjebbi vezérlési szerkezetet szakítson meg.

Abbol kod reszletbol nem latszik, de goto a kernelben indokaltan van alkalmazva.

Meg ha az idezett kod reszletben pont van goto nelkuli ekvivalens olvashato megoldas, minden esetben nem lene. Olvashatobb a kod, ha goto stilusu a legtobb helyen, es nem hol van hol nincs.

Tanulmany arrol, hova kene meg goto a kernelben:
http://pagesperso-systeme.lip6.fr/Julia.Lawall/lctes11.pdf

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( lberes (nem ellenőrzött) | 2012. 12. 12., sze – 09:20 )

Persze, goto lunch.

--
L

Ezt kifejtenéd?

Szerény véleményem szerint a goto olvashatatlanná, és karbantarthatatlanná teszi a kódot, eddigi munkahelyeimen a coding convention explicit tiltotta/tiltja is mindenhol.

A break és a continue ellenben teljesen legális vezérlő szerkezet.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

A goto szinte akárhova ugrik. A break, continue két jól meghatározott helyre. Aztán azt is tegyük hozzá, hogy az if nagyon jól helyettesíthető goto-val, csak meg kell fordítani a feltételt. A ciklusok meg egy if-goto párossal. Így nem is értem, miről beszélsz.
----
India delenda est.
Hülye pelikán

A goto szinte akárhova ugrik. A break, continue két jól meghatározott helyre.

Ebbol az kovetkezik, h nem epithetem be azt a goto-t ugy, h az egy break/continue "jol meghatarozott helyere" mutasson?

Aztán azt is tegyük hozzá, hogy az if nagyon jól helyettesíthető goto-val

Egy feltetel kiertekeles hogyan helyettesitheto egy feltetel nelkuli ugrassal?

A ciklusok meg egy if-goto párossal.

Ebben speciel igazad van, de ez nem egy darab goto, mint a break/continue eseteben, hanem egy komplexebb kifejezesrol van szo. De a return is lecserelheto egy megfelelo long jump-ra. :)

Így nem is értem, miről beszélsz.

Nembaj.

---
pontscho / fresh!mindworkz

Hehe! szerintem van itt pár ember, aki túl fiatal ahhoz, hogy ismerje, értse a strukturált programozást alapjait. ;)

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

Jaja! Korábban én is be akartam dobni a társalgás közepén, hogy még senki nem írt olyan, hello worldnél bonyolultabb kódot, amiben nincs goto (jump), de gondoltam nem hergelem a társaságot. :P

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

Aztán azt is tegyük hozzá, hogy az if nagyon jól helyettesíthető goto-val

Egy feltetel kiertekeles hogyan helyettesitheto egy feltetel nelkuli ugrassal?

fogalmam nincs mire gondolt nagyon jól helyettesítés alatt, de zB egy rosszul helyettesítés:

if feltetel akkor haigaz kulonben hahamis
ből lehet csinálni egy

:label blabla0
hahamis;
goto tovabb;

:label blabla1
haigaz;
goto tovabb;

bulen=feltetel;
goto blabla+bulentosztring(bulen);
:label tovabb

szvsz undorító dolog a két ágat kiszervezni, még akkor is ha... igazából fogalmam sincs mikor lehet ez jó.

Miért használnál goto-t, ha használhatsz break-et és continue-t? Goto-ra egyetlen egy esetben van bocsánat: assemblyben. Ott is csak azért, mert nincs más lehetőség. Mindenhol máshol valóságos horrorrá válik a karbantartás tőle. Tudom, miről beszélek! Lásd még az aláírásom - nem véletlen! Takarítottam goto-b*zi indiánok után.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

ha-ha-ha Az idő SI-alapegysége az SI-másodperc ja és az atomóra a cézium-133 atom rezgési tulajdonságára épül, s 1967 óta a SI mértékegységrendszer a másodpercet a 133Cs atom 9 192 631 770 rezgéseként határozza meg. Én tudok faktorizálni bármilyen életkorokat kötözködés ide vagy oda :) !

igen ! Mint ahogyan egészeken is alkalmaztad!
amúgy nem tudom mi bajod van az mp^5-el mikor négyzetre is tudod emelni amikor gyorsulásról beszélsz sőt elosztod vele a métert XD persze itt pont nem azt a tagot használjuk fel.
Egyébiránt a fakt(világegyetem életkora másodpercben) darab másodpercre gondoltam de aki goto-zik annak év. persze ezt még én is nehezen képzelem el mekkora büntetés de hát aki megérdemli az megérdemli

igen ! Mint ahogyan egészeken is alkalmaztad!
amúgy nem tudom mi bajod van az mp^5-el mikor négyzetre is tudod emelni amikor gyorsulásról beszélsz sőt elosztod vele a métert XD persze itt pont nem azt a tagot használjuk fel.
Egyébiránt a fakt(világegyetem életkora másodpercben) darab másodpercre gondoltam de aki goto-zik annak év. persze ezt még én is nehezen képzelem el mekkora büntetés de hát aki megérdemli az megérdemli

igen ! Mint ahogyan egészeken is alkalmaztad!
amúgy nem tudom mi bajod van az mp^5-el mikor négyzetre is tudod emelni amikor gyorsulásról beszélsz sőt elosztod vele a métert XD persze itt pont nem azt a tagot használjuk fel.
Egyébiránt a fakt(világegyetem életkora másodpercben) darab másodpercre gondoltam de aki goto-zik annak év. persze ezt még én is nehezen képzelem el mekkora büntetés de hát aki megérdemli az megérdemli

"továbbra is csak egész számok körében tudom elképzelni a faktoriálist"
Azokról az f valós-valós függvényekről mi a véleményed, amelyekre igaz, hogy bármely n természetes szám esetén f(n) = (n-1)!, de amúgy minden valós számra értelmezve van, és még teljesít nagyon szép analitikus tulajdonságokat is, például pozitív valós számokra minden pontban differenciálható (és ami ebből következik, folytonos is).
Azaz a függvény egész helyeken faktoriális értékű, egyébként pedig analízis szempontjából "szép".
Na, a gamma függvény ilyen, nézz utána.

Mondjuk mi az analízist úgy kezdtük, hogy felírtuk a valós számok 10 axiómáját, és ez volt az alap. Bevmatból mentünk el halmazelmélet -> természetes számok -> ... -> valós számok útvonalon. Ha a lebegőpontos számokra gondolsz, az igaz, numerikus módszerek előtt azt nagyon át kell venni.
----
India delenda est.
Hülye pelikán

Nem, nem numerikus matematikára gondolok, valós számokra. Valós számok nélkül nincs analízis és fordítva: valós számok nincsenek analízis nélkül. A felsőhatár-tulajdonság tipikus analízisbeli fogalom, ugyanúgy, mint a zárt és nyílt halmaz, belső pont és hasonlók. Ezek a topológiai fogalmak megértése elengedhetetlen a valós számok rendes megértéséhez, a valós számok nem csak sűrűen elhelyezkedő számok, mert hát bármely két racionális szám között is van racionális szám, de a valósok még ennél is "durvábbak". Valós számok nélkül nincs folytonosság, azaz nincs differenciálhatóság sem, és határérték sem.

Ez rendben is van, de a valós számok axiomatikus tárgyalásához (gondolom úgy definiáltátok, mint egy felsőhatár-tulajdonságú rendezett test, amiből valójában egy van, mert bármely kettő ilyen test izomorf) kellenek analízisbeli fogalmak, a felsőhatár-tulajdonság ilyen, ez már analízis.
Az axiomatikus bevezetés tényleg nagyon jó, én is ez alapján tanultam a valós számokat, azonban ez magáról a számtestről egy csomó mindent nem mond el, legalábbis sokan nem gondolnak bele, hogy egy csomó analízisbeli fogalom nem működik a felsőhatár-tulajdonság nélkül, és tényleg nem látják a különbséget a valósok és a racionálisok között a definíción kívül. A definíciót persze bárki meg tudja tanulni, de érteni is kell, miért fontos belőle mindegyik tulajdonság.

A különféle archimedeszi axióma, felsőhatár-axióma már felhasználja a valós szám fogalmát.

Igen, valóban nagyon tisztán le lehet vezetni halmazelméleti alapokból a valós számok definícióját, de a mondanivaló lényege: az analízis és a valós számok fogalma egymás nélkül nem létezik.

Ugyanarról beszélünk, a valós számok axiomatikus bevezetése (mint említettem, nálunk ez az volt, hogy itt van ez a halmaz ezzel a két művelettel, és ez a 10 tulajdonsága van) jó, de nem kielégítő, mi valahogy mégis mindent alapoktól tanultunk ezzel a bevezetéssel együtt is. Ami valahogy fura. Az más kérdés, hogy egy másik tárgyból felépítettük 0-ról (szinte), lehet erre alapoztak analízisből. Már nem emlékszem pontosan hogy volt, régen volt.
----
India delenda est.
Hülye pelikán

,, valós számok nem csak sűrűen elhelyezkedő számok, mert hát bármely két racionális szám között is van racionális szám, de a valósok még ennél is "durvábbak"."

azt hiszem a racionális és az irracionális számok megkülönböztetése általános iskola 6. osztályos tananyag (bár kitudja. Egyrészt rég volt, másrészt a NAT lassan egy havilap lesz, nem pedig alaptanterv)

nem az hogy léteznek, hanem a legtöbb tulajdonságuk. Belátni hogy 10-es számrendszerben periodikus <=> racionális. gyök nemnégyzetekről belátni, hogy irracionálisak (tehát hogy léteznek egyáltalán irracionálisak!), belátni, hogy a rac számok (vagy az algebraiak ) annyian vannak, mint az oroszok, az irracionálisak meg többen. Sok-sok tulajdonságukat be lehet (sőt, kell is szegény törpéknek) látni; amik megkülönböztetik a racionálisakat az irracionálisoktól.

Egyébként meg ne ferdíts, a valós számok nem egyetemi tananyag. Van hozzá kapcsolódó egyetemi tananyag, igen. Ennek az állításnak annyi az informácitartalma mint hog a hó esik vagy a fű zöld. A pithagorhasz-tételhez is kapcsolódik egyetemi tananyag, mégis, valamilyen szinten oktatják általános iskolában is. Azzal, ha azt mondod, hogy van a valós számokhoz kapcsolódó tananyag egyetemen is, amely az éppen aktuálisan tanult analízis/axiómatika etc témakör eszközeivel vezeti be őket, mutatva az analízis vagy az axiómatika erejére példákat, nem jelenti azt, hogy kizárólag egyetemi tananyag, hogy kizárólag így lehetne őket értelmezni. (sőt!, az irrac számok felfedezése egészen véletlenül geometriai megfontolások alapján történt, bele is bukott az egész görög matematika a pitagóraszi iskola)

"Belátni hogy 10-es számrendszerben periodikus <=> racionális."
Ez egyáltalán nem a valós számok tulajdonsága, hanem bizonyos irracionálisoké is. De a valós számokat nem ez különbözteti meg a racionálisoktól.
"Sok-sok tulajdonságukat be lehet (sőt, kell is szegény törpéknek) látni; amik megkülönböztetik a racionálisakat az irracionálisoktól."
Pontosan egy olyan tulajdonság van, ami a valósakat megkülönbözteti a racionálisoktól, ez a felsőhatár-tulajdonság.
Nem sok-sok tulajdonság, hanem pontosan 1. Amiket te felsorolsz, azok csak példák az irracionális számok halmazaira, de nem írják le az irracionális számokat magukat.
"hogy kizárólag egyetemi tananyag, hogy kizárólag így lehetne őket értelmezni."
Dehogynem. Pont az is egy fontos tétel, hogy minden olyan halmaz, ami rendelkezik a felsőhatár-tulajdonsággal, izomorf a valós számtesttel.
" az irrac számok felfedezése"
Ez így azért túlzó kijelentés, azt kell mondani, hogy azt fedezték fel, hogy vannak irracionális számok, meg azt, hogy bizonyos számok irracionálisak. De attól még nem tudták azt, hogy valójában a valósakat mi különbözteti meg a racionálisoktól.

,,Ez egyáltalán nem a valós számok tulajdonsága, hanem bizonyos irracionálisoké is. De a valós számokat nem ez különbözteti meg a racionálisoktól."

nem vagyok biztos abban, hogy úgy nevezed a különböző halmazokat ahogy kéne
// of korsz nem szólnék, ha érteném mit akarsz írni

,,Pontosan egy olyan tulajdonság van, ami a valósakat megkülönbözteti a racionálisoktól, ez a felsőhatár-tulajdonság."

borzasztóan örülök, hogy analízis közben rátértek az egyetemen a valós számokra. Annak mondjuk kevésbé, hogy nem tanítottak szemléletet (esetleg ellenszemléletet tanítottak, hogy ez meg az rossz, hogy az equivalens tulajdonságait ki ne ejtsd a szádon mert ez vagy az)

wikipédia: ,,Irracionális számnak nevezzük az olyan valós számokat, melyek nem racionálisak, vagyis amelyek nem írhatók fel két egész szám hányadosaként. Az ilyen számok mindig végtelen, nem szakaszos tizedes törtek."

ez teljesen korrekt definíció ami egész mellesleg equiv a te felsőhatár axiómáddal. És egy hatodikos is egyrészt elhiszi, másrészt pedig le tudja vezetni, hogy ami periodikus az racionális, továbbá nem létezik olyan szám ami sehogy nem írható fel tizes számrendszerbeli alakban :) Az összes többi definíció ezzel equivalens, és a többi tulajdonság csak analízishez kell de köze nincs ahhoz, hogy mik is lennének az irracionális számok.

Amúgy az idézett definíciód nem jó, mert benne van a valós számok definíciója, hiszen ezzel keződik. Azaz ahhoz, hogy így tudnánk definiálni az irracionális számokat, kellene a valósak definíciója.

Ponthogy szemléletet nem oktatunk azzal, ha azt mondjuk, hogy valósak = irracionálisak + racionálisak, mert ezzel csak megtanultak egy definíciót, de nem tudják használni, nem tudják mire jó. Olyan ismeretanyag, mint történelemből az évszámok.
"továbbá nem létezik olyan szám ami sehogy nem írható fel tizes számrendszerbeli alakban"
Mivel komplexekről még nem hallott akkor, de ez nem is baj.

A számfogalom kialakítása nagyon bonyolult dolog, épp ezért kell nagyon vigyázni, amikor oktatjuk azokat.

Bebifláztatni nem szabadna ilyen definíciókat, persze a tanár számára könnyebb, mert tanítani egyszerűbb (le van írva egy mondat, amit érteni nem kell, csak visszaadni), és tanulni is egyszerűbb (hiszen nincs mögötte igazi gondolat). Akkor van bajban a tanár, amikor 1-1 tehetséges diák rákérdez, hogy de tanárnő kérem, van-e olyan szám, ami nem valós szám, akkor mit mondasz?

Aztán később, amikor középiskolában szeretnének alapozni valóban a normális definíciókra mondjuk fakultáción, akkor sok diák már el van rontva.

Ez mondjuk igaz, az altsuliban meg en sem eroltetnem a szamelmeletet, az onnet kikerulok nagy tobbsege a bolti vasarlason meg a billentyuzeten kivul nem kerul komolyabban szamok kozelebe. Oda teljesen jo a fenti definicio, csak valahogy bele kell venni, hogy vannak meg ezen kivul is szamok - csak azokkal nem foglalkozunk e helyt. Tehat emlites szintjen mar elo kellene jonni a komplex szamoknak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

én általános iskolásról beszéltem, nem középiskolásról; és persicsbbel valós és racionális számok fogalmáról beszéltem, ami neki valamiért problémát okozott.

ami még egy általános iskolásnak is mennie kell: összes valós szám felírható tízes számrendszerbeli alakban - ez evidencia (de be is tudja látni a nebuló) racionális az, ami periodikus. az, hogy neki nem sikerült egyszerűen, kizárólag annak köszönhető, hogy ő az analízis eszközeivel próbálta megfogni a racionálisakat. naná, hogy nehéz lesz, ha szándékosan az éppen tárgyalt téma eszközeire korlátozza magát.

,,Miért érzem azt, hogy te nem vagy tisztában a valós számokkal úgy általában? "

mert valószínűleg te nem vagy tisztában a valós számokkal úgy általában :p

na jó: ha valaki a fejemhez tart egy pisztolyt, és azt mondja: most azonnal adjál egy definíciót arra, hogy mik a valós számok (definíciót, azaz csak egyféle valós számok létezzenek, és ne létezzenek olyanok, amik még eleget tesznek a definícióimnak), akkor valószínűleg vagy gyorsan megalkotom a matematika néhány új ágát (még fiatal vagyok, tervezhetek ilyet, nem?) vagy aszondom, hogy valós számok halmaza az egyetlen olyan halmaz, amelyre igazak a testaxiómák, a rendezési axiómák, és az oroszlánfogás.

egyébiránt a valós számok az összes szám amiknek létezik tízes számrendszerbeli alakja (még ha néhány számhoz több alak is társulhat)

viszont ha legközelebb találkozom hatodikosokkal majd megkérdezem őket, hogy bonyolult volt-e megérteniük, hogy nem racionális az összes szám, vagy hogy az összes számok halmaza sokkal durvább, mint a racionálisaké.

"de be is tudja látni a nebuló"
Ezt ketlem. Bizonyitsd be, hogy akarhogyan valasztok ki egy valos szamot, mindig lesz neki tizes szamrendszerbeli reprezentacioja. Egyaltalan nem trivialis bizonyitani ezt, ugyanis a helyiertekes tizes szamrendszerbeli abrazolas sorosszegeket jelent. Peldaul bizonyitsd be, hogy a sqrt(2) mindenkeppen felirhato tizes szamrendszerben, azaz van olyan tizes szamrendszerben is abrazolhato szam, aminek a negyzete 2. Lassuk, altalanos iskolai eszkozokkel a bizonyitast.
Ne feledd a tizes alapu helyiertekes szamrendszer csak egy abrazolas, a szamuk maguk leteznek az abrazolastol fuggetlenul :)

,,Ezt ketlem. Bizonyitsd be, hogy akarhogyan valasztok ki egy valos szamot, mindig lesz neki tizes szamrendszerbeli reprezentacioja. Egyaltalan nem trivialis bizonyitani ezt, ugyanis a helyiertekes tizes szamrendszerbeli abrazolas sorosszegeket jelent"

inkább úgy vélem, hogy neked van igazad :S egy ilyet semmiképp sem tud belátni, meg sem fogja érteni a problémát ha felteszem neki hogy léteznek olyan számok amik nem összegei végtelen sok 1/10 hatványnak :S (ebben a megfogalmazásban elég nehéz belátni. de máshogy is)

ha előtte tanítom is, minthogy neked megmutatnám, hogy nézd már egy átlag hatodikus milyeneket tud, akkor néhány megadott algebrai számra beláthatja neked, hogy létezik egy olyan karaktersorozat ami által reprezentált szám semmiképp nem lehet nagyobb, és semmiképp nem lehet kisebb, mint mondjuk gyök2, de hogy nem algebraiakra :S esélytelen

milyen buták is a hatodikosok :((

Belegondoltál-e már abba, hogy az, hogy minden egyes tízes számrendszerbeli kifejezés meghatároz egy létező számot equivalens azzal, hogy végtelen sok egymásba ágyazott skatulyának létezik metszete? A tízesz számrendszer igazából végtelen sok skatulyát határoz meg, az meg, hogy a tanárúr kimondja: létezik olyan szám, ami megfeleltethető a diák által leírt számrendszer alaknak equivalens azzal, hogy Cantor bácsi kimondja hogy létezik ilyen szám :S

Azt hittem én egy icipicit mást csinálok amikor ezt a számrendszert erőltetem, de nem :S Hjah, nincs új a nap alatt, ha pisztolyt tartanának a fejemhez két darab tökugyanolyan megfogalmazásából választhatnék a valós számoknak :(

igazából a hatodikosok a valós számok összes axiómáját vették már, mint axiómát, illetve elfogadják hogy az igaz. A dolog a másik irányba problémás, amikor csak racionális számkörben vagyunk, akkor nincsen minden egyes stringnek megfeleltethető racionális szám. (hisz belátta már a kölök, hogy a racionális szám periodikus, tehát egy nem periodikus string - soksok halmaz metszete - nem jelöl létező számot).

Ha igazak az rendezési axiómák (hatodikos vagyok, tehát igen). Adok neki egy tau számot, amiről nem mondom meg, hogy tau^2 = 2, csak azt, hogy tau egy szám.
Definiálok egy S stringet úgy, hogy S[0] (S nulladik karakterei) = legnagyobb taunál kisebb egész szám, tau1=10*(tau-S[0])
S[1] = legnagyobb tau1-nél kisebb egész szám (tau1 0 és tíz között van, de ez most mindegy) tau2=10*(tau1-S[1])

satöbbi. Ily módon definiálta(m) (ő vagy én) egy S string minden számjegyét. Azt meg be tudjuk látni, hogy az S string által meghatározott szám (van ilyen, igaz a Cantor axióma, meg amit a tanárúr mondott, hogy egy tízes számrendszer beli szám egy létező számot jelöl) nem lehet nagyobb, kisebb mint tau, tehát pontosan egyenlő vele. Így S lesz tau tízes számrendszerbeli alakja.

Furcsa, mikor elkezdtem ezt a szálat még egyáltalán nem tudtam, hogy amit én mondok, hogy egyszerűbb így szemlélni a dolgokat, ugyanaz, mint axiomatikusan. Egy kicsit szomorkás ez. :(

Kezdjük ott, hogy egyáltalán nem is tudják, hogy létezik olyan szám, amire igaz, hogy tau^2=2, szóval először azt kellene ismerniük, hogy létezik ilyen.
A hatodikas tananyagban merül fel először egyáltalán a racionális számok fogalma, a törtekkel való számolás fogalma, ekkor veszik a racionális számok körében a négy alapműveletet, a hatványozással csak ismerkednek, annak inverzével (létezik-e olyan szám, aminek a négyzete 2) egyáltalán nem foglalkoznak, sőt a negatív számok is ebben az évfolyamban kerülnek bevezetésre.
Hatodikasként nem tudod levezetni ezeket a dolgokat, a végtelen fogalma sincs még kialakultan meg bennük.

Itt a kerettanterv: http://www.nefmi.gov.hu/letolt/kozokt/kerettanterv/korrekturas/alapfok/…

Az irracionális számok létezése, a négyzetgyök nyolcadikas tananyag.

Hatodik osztályban nincs még gyökvonás, így nem tanulnak irracionális számokat sem.
Másrészt az, hogy tudják, hogy vannak ilyen számok, még semmit nem jeletn, nem értik azt, hogy valóban mi különbözteti meg a valós számokat a racionálisoktól.
Nem csak azok a számok irracionálisak, amik bizonyos számok gyökei, sőt az algebrai számok is relatíve kevesen vannak a valós számok halmazán belül, szóval amit mondasz, az csak arra való, hogy lássák az emberek, hogy van a racionális halmaznál bővebb számhalmaz is, de azt nem tanulják meg, valójában milyen számok ezek, mi az a tulajdonság, ami megkülönbözteti a valósakat (ez a felsőhatár-tulajdonság).

Ez analóg azzal, hogy oké, tudunk adni egzisztencia-bizonyítást tételekre, de mégis teljesebb dolog egy konstruktív bizonyítás. Nem elég tudni azt, hogy valamik léteznek, jó tudni a tulajdonságaikat is.

,,Hatodik osztályban nincs még gyökvonás, így nem tanulnak irracionális számokat sem."

ah, ezt a szép következtetést :P

,, Másrészt az, hogy tudják, hogy vannak ilyen számok, még semmit nem jeletn, nem értik azt, hogy valóban mi különbözteti meg a valós számokat a racionálisoktól."

De igen, értik. Pontosan az, hogy periodikusak vagy nem periodikusak. Ez egy equivalens definíció a többivel, és egy hatodikos is érti. (sőt, vannak olyan helyzetek, ahol ezzel a definícióval sokkal egyszerűbb kezelni a problémát, mint egy másikkal (nem írható fel két szám osztataként, igaz rá a Cantor, etc))

Sőt, ha a tanárnak kedve van le is rajzolhatja a táblára a számot tízedestört alakban, mint végtelen sok halmazt, és el is mondhatja, hogy milyen érdekes, itt van ez a periodtalan szám, ami végtelen sok nem üres halmazt határoz meg (minden halmazban van racionális szám), de oh, periodtalan, tehát az összes metszete mégis üres. Kellemetlen.

,,valójában milyen számok ezek, mi az a tulajdonság, ami megkülönbözteti a valósakat (ez a felsőhatár-tulajdonság)."
Ha analízist tanulsz, akkor az analízis feladatokban a felsőhatár-tulajdonságát nézed az irracionális számoknak. Ha mindent tanulsz, akkor látod, hogy egy valami nem azonos az equivalens definícióinak az egyikével.

,,Ez analóg azzal, hogy oké, tudunk adni egzisztencia-bizonyítást tételekre, de mégis teljesebb dolog egy konstruktív bizonyítás. Nem elég tudni azt, hogy valamik léteznek, jó tudni a tulajdonságaikat is."
Akkor kérd azt számon, hogy a hatodikosok nem tudják a valós számok analízisbeli tulajdonságait, ha már ezt kéred számon. Pontosan elég tulajdonságát tudják a valós számoknak. Léteznek, hogy sokan vannak, hogy több nincs, néhányról eldönteni hogy racionális-e.

(úgy vélem csak magamat ismétlem)

Anno sokat gondolkodtam a megfelelő képleten erre, még középiskolában, mindig is akartam valós -> valós függvényt illeszteni a faktoriálisra, próbálkoztam interpolációs módszerekkel is, de aztán valszámból bejött a gamma függvény... mondjuk nem szégyelltem magam, mert nem hiszem, hogy sok ember kitalálta volna magától :)
----
India delenda est.
Hülye pelikán

( utpKabel | 2012. 12. 12., sze – 09:57 )

Rendszeresen használok C-ben. Néha C++-ban is.

Nem másolnám be, inkább csak elmondom, hogy formfeldolgozásnál rendszeresen goto-zok a hiba és a hiba kiíratása után a vezérlési szerkezet utánra, ezzel több csúnyább else ágat megspórolva. Ugyanezt megtehetném egy labeles while(true) ciklussal, mindig break-elem azt, amikor a vezérlési szerkezet utánra akarok ugrani, vagy az egészet rakhatnám egy try-catch blokkba, és dobathatnám a kivételt, hogy a végére ugorjon (tán még szebb is lenne ott kiíratni a hibaüzeneteket), vagy csinálhatnék több metódsut return-ökkel. Szóval meg lehetne csinálni másképp is, igen, de így a leggyorsabb, és mivel csak egy nagyobb vezérlési szerkezet utáni részre ugrok közvetlenül a közepéből kifele, meggyőződésem, hogy ennél olvashatóbb nehezen lehetne a kód, max ugyanilyen olvasható lehetne.

Ezzel nem teljesen értek egyet, webfejleszteni azért kényelmesebb vele, amikor egyszerűbb feladatokról van szó, annak ellenére, hgoy én is kerülöm a PHP-t, ha nem az a legmegfelelőbb eszköz. Meg egy profi kódernek is van hogy PHPistikékkel kell együttdolgoznia PHP kódon, ott is jó lesz neki, még akkor is, ha csak ő tudja közülük, mi az a finally

( zoli78 | 2012. 12. 12., sze – 10:07 )

Egyrészt a programozási nyelv, amiben dolgozom (java, php) nem támogatja a goto-t, másrészt az alkalmazott módszertanok amúgy sem engedik a használatát.
Kérdés viszont, hogy a rejtett goto is számít-e (break, continue, return sűrű használata)?

Sokat dolgoztam indiánokkal, és a helyzet az, hogy van egy-két nagyon penge köztük, de a többsége olyan undorító kódot tud összehozni, hogy ember legyen a talpán, aki nem hányja el magát tőle.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

sok-sok év programozás után mondom, hogy csak ritkán engedhető meg az, hogy több return van egy függvényben. Ilyen esetek:
- ha a függvény kb. egy switch/case-ből vagy if else-kből áll és csak az érték változik. Erre amúgy sok esetben van szebb megoldás!
- ha nagyon rövid a függvény (pl. egyetlen if else) és csak rondább lenne tőle ha emiatt be kéne vezetni pl. egy $retVal-t valami hasonló gusztustalanságot. Bár ez már határeset!

"sok-sok év programozás után mondom, hogy csak ritkán engedhető meg az, hogy több return van egy függvényben. Ilyen esetek:"

Na nehogy már... 

int foo(....)
{
  if (ezszar) return ERROR_FOO;
  if (azszar) return ERROR_BAR;
  if (amaz) return ERROR_BAZ;
  ...
  return ERROR_OK;
}

vagy: 

public Foo FindFoo(IEnumerable<Foo> foos)
{
  foreach (var foo in foos)
  {
    if (foo.Valami()) retrun foo;
  }

  return null;
}

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1 Elképesztő, hogy több év programozás után ekkora marhaságot ki bírt jelenteni az úr. Az ilyen mégis mit csinál helyette? Még csak nem is kellett neked se messzire menned példákért, és igen, aki ezt if-else dzsungellel csinálná meg, mert "csúnya" a több return, az hagyja ott a szakmát sürgősen.

Csak három okból:
1. mindenképpen végignézi a többi hibalehetőséget ami teljesen felesleges és időbe telik
2. megbonyolíthatja a többi hiba ellenőrzését. Egyszerű példa (de lehet sokkal bonyolultabb is ennél): az első if azt nézi, hogy valid pointer-t kapott-e a függvény, a többi meg már az adattal dolgozna. Ha az első után nem tér vissza a program, akkor a többi segmentation fault-ba futhat. Ki lehet persze kerülni még egy if-fel, de az rondább mint a return.
3. Elfelejted, hogy a ... helyén is folytatódik a program. Ami ott van annak nem kéne lefutnia hiba esetén. Megintcsak lehet if-ezni, de sokkal csúnyább mint a korai return.

Például helyből +1 változó és a ... helyére +1 feltétel kiértékelés. Na meg több kód, többet kell átnézni és karbantartani, valamint kevésbé tiszta vezérlési szerkezet: példádban végig kell követni a result életútját, ahelyett, hogy ott, ahol hiba van befejeznéd a további működést.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( TheImmortal | 2012. 12. 12., sze – 10:13 )

Sokáig el sem tudtam képzelni olyan helyzetet, hogy goto használatára kényszerüljek, főleg nem c++-ban, de nem régen egy visszalépéses algoritmus implementálásánál ez tűnt a legoptimálisabb megoldásnak. Az iroda szkeptikus része átnézte és sikerült őket is meggyőzni, azóta másképp viszonyulok hozzá és látom gyakorlati hasznát is.

( kisg v | 2012. 12. 12., sze – 10:16 )

Igen, használok, ha az a megfelelő. Pl. C-ben az egyik elfogadott exception kezelési / resource management megoldás. C++-ban már a RAII minta használata az esetek többségében ki tudja váltani.

Javaban vagy más nyelveken még nem éreztem úgy, hogy szükségem lenne rá.

Sajnálatosnak tartom, hogy az oktatásban a legtöbb helyen még mindig nem a tananyag része a goto helyes használata.

Üdv,
Gergely

,,Sajnálatosnak tartom, hogy az oktatásban a legtöbb helyen még mindig nem a tananyag része a goto helyes használata. ''

Dehogynem része az, csak -- ahol esetleg van -- az assembly oktatásnak...

Gábor
============================================
"Share what you know. Learn what you don't."

( mikcsabee | 2012. 12. 12., sze – 10:27 )

http://xkcd.com/292/

"Van egy teória, miszerint ha egymillió majomnak adsz egy-egy írógépet, amit elkezdenek össze-vissza véletlenszeruen püfölni, akkor elobb-utóbb megírják Shakespeare összes muvét. Az Internetnek hála, ma már tudjuk, hogy ez nem igaz.,, -

( wachag | 2012. 12. 12., sze – 10:39 )

Többszörösen egymásba ágyazott ciklus megszakítására tisztább megoldásnak tartom, mint a flag-ek bevezetését. Persze ilyenkor el lehet gondolkodni, hogy nem tervezési hibáról van-e szó.

C++ alatt már nem használnám.

( pityulaman1983 v | 2012. 12. 12., sze – 10:42 )

Nem hinnem, hogy van olyan problema, amit nem lehet elegansan, szepen, goto nelkul megoldani. Valaki irna ilyen peldat (akar PM-ben is)?

-----------
"640GB sokmindenre elég"

Azert van jo par helyzet, mikor ez nem hatekony es/vagy a korites leprogramozasa jol meg is tudja bonyolitani a szitut. Deklarativan kijelenteni azt, h a tobbszoros ciklus tervezesi hiba nem erdemes, maximum azoknak a hatulgombolosoknak akik most jonnek ki az iskolapadbol. Nekik meg a goto is ordogtol valo.

---
pontscho / fresh!mindworkz

Érdekelne a jópár helyzetből egy. Pastebin ott van, belinkelsz egy konkrétumot, és hajrá, próbáljuk meg mi okosok goto nélkül megoldani, vagy mutasd meg, hogy nem alapvető tervezési hibáról van szó! Máskülönben csak elméletileg passzolgatjuk a labdát egymásnak, és mindenki megmarad a saját kis világában.

Én még nem voltam code review-n, ahol átcsúszott volna akár egyetlen goto is.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

Én még nem voltam code review-n, ahol átcsúszott volna akár egyetlen goto is

Ennek tobb oka is lehet, itt van pl. harom:
1. A vak vezet vilagtalant esete, amikor is a ceges bibliaban eleve benne van, hogy mindenki, aki goto-t hasznal a kodjaban, a purgatorium orok tuzere lesz karhoztatva. Nem beszelve a premium megvonasrol.
2. A review-n resztvevoknek fogalmuk sem volt, hogy "azmiaz".
3. Indokolatlanul volt hasznalva, esetleg olvashatatlan kodot eredmenyezve. Ez egy ertheto ok lenne.

De kar ezen rugozni, ha nem akarod ne hasznald. Viszont ha peldakra vagysz, akkor javaslom a klasszikusok egyiket forgatni, pl. az Advanced Programming in the UNIX Environment W. Richard Stevens-tol hemzseg az olyan kodreszletektol, ahol a goto is szerepet kap. Es "hihetetlen", de az o peldai egyszeruen megerthetok. Erdekes, nem? :p

De, hogy legyen itt kodreszlet is, mivel kerted (a peldat megtalalod az emlitett konyvben is): 


again:
    if (system_call() < 0) {
        if (errno == EINTR)
            goto again; // interrupt utan ujrakezdeni
        // egyeb hibak kezelese
    }

Ird meg ezt _olvashatobban_ goto nelkul! ;)

Sajnalatos, hogy manapsag mar nem meno a klasszikusok olvasasa, en csak ajanlani tudom oket...

Most nehogy már az legyen az érv a goto mellett, hogy a C-ben milyen hülyeségek vannak (globális errno (meg ha csak thread global), exception mint olyan nincs).

De ha már mindenképp C: 

while (system_call() < 0)
{
   if (errno == ENTR) continue;

   // egyéb hibák
}

Lehet, bennem van a gond, de nekem ez átláthatóbb. 4 helyett 2 sor. (3, ha nagyon feszegetjük).

És mielőtt: igen, tisztában vagyok vele, hogy a continue is egy goto, csak mondjuk jelen esetben jóval specifikusabban megmondja, hogy mit akarok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

En ertelek, ezzel nincs is problema. Viszont hogy mondhatod, hogy az egyik olvashatobb, mint a masik, ha nem veszed eszre olvasas kozben, hogy a ketto nem ugyanaz? ;) Es most egy 4(!) soros kodrol beszelunk. Mindegy, mar korabban is irtam, hogy aki nem akarja, ne hasznalja. Viszont azert nem hasznalni, mert az "bun", egy eleg sovanyka erveles szerintem. Ezert jott ez a pelda.

a continue azert jobb, mint a goto, mert legalabb az editor find parancsaval sem lehet megtalalni, hogy hova ugrik, mig a goto cimkejet igen. (Sheldon: szarkazmus)

Ezeket a break, continue, goto dolgokat nagyjabol ugyanolyan nyelvi kenyszernek tartom. Ahol break/continue -t hasznalok, az altalaban kap egy jol lathato commentet: 


while (system_call() < 0)
{
   if (errno == ENTR) continue;  // ********** C O N T I N U E **************

   // egyéb hibák
}

mert ugye eleve a tabulalast azert hasznaljuk, hogy konnyebb legyen olvasni. Akkor mar ne maszkaljon a vezerles maskepp, mint ahogy a tabulalas alapjan sejteni lehet.

Aha, hasznalok exit(); -et meg return; -t is, es ADA-ban az exception handling laza hasznalata ugyanolyan atlathatatlan kodot eredmenyez, mint a C-ben a goto: ha jol hasznalod, akkor egyertelmu, ha hulyen, akkor olvashatatlan.

A continue pont hogy kitalalhatova teszi - az ot megelozo for vagy while blokk elejeig kell visszamaszni. Nem tovabb, nem elobb. A goto meg gyakorlatilag akarhova ugorhat, ha az editor pont nem tamogatja a goto koveteset (vagy nem talalja a cimket), akkor keresheted, hogy hol van az a cimke. Arrol nem is beszelve, hogy egy cimket konnyebb elutni, mint egy kulcsszot.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

a) emlekeztetnelek az sh nevu nyelvre, amelynel a break es continue kaphat szam parametert, igy rohadtul nem igaz, hogy "az ot megelozo for vagy while blokk elejeig kell visszamaszni"

b) ne syntax highlighting-ban gondolkodj, hanem abban, hogy a szovegszerkeszto keresni es elore-hatra lepkedni tud

c) egy cimket es egy kulcsszot realisan pont ugyanolyan konnyeden lehet elutni. en ha tippelnek, pont forditva mondanam mint te

- nem sh nyelvrol volt szo, igy nem is felteteleztem, hogy szamolnom kell ezzel a nyelvvel, ezen felul ezt a feature-t meg sosem hasznaltam - koszonom hogy felhivtad a figyelmemet
- amelyik szovegszerkeszto nem tud syntax highlightingot, abban en nem nyitok meg forraskodot. Meg szerveren is fenn szokott lenni valami (legrosszabb esetben mcedit) ami tud kiemelest. Tul sok hiba forrasa lehet, ha nincs kiemeles, amit nem biztos, hogy onkent bevallalok.
- ha van syntax highlighting, a kulcsszo elutese nagyon szepen latszik, egy cimkee viszont...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, benned van a hiba, legalabbis, ha ugy gondolod, hogy a ket kodreszlet egyenerteku. Ez egy felveteli beszelgetesen egy beugro kerdes lenne, maximum 1 perces gondolkodasi idoven: "Adjon egy ekvivalens megoldast a kovetkezo kodreszletre, goto hasznalata nelkul ... Kesz? Ertem, koszonjuk, hogy jelentkezett."

Mig a goto elleni leggyakoribb erv, hogy spagetti kodot eredmenyezhet es ezert eleve szamuzni kell, most akaratlanul bar, de bebizonyitottad, hogy bizonyos esetekben, nem is olyan egyszeru "kivaltani". Na de mi a baj te megoldasoddal? Az, hogy nem lepsz ki a ciklusbol, ha mas a hibakod. Igy a ket kod nem egyenerteku. Az elsoben egyetlen egy esetben van "ciklus", nevezetesen, ha a rendszerhivast egy interrupt megszakitja. A masodikban viszont egeszen addig, amig a fuggveny hibaval ter vissza, a ciklus lefut. Ha viszont teletuzdeled break-ekkel a kododat, nyomban nem 2-3 sornal jarunk, hanem x-nel, a hibakezeles bonyolultsagatol fuggoen (egyebkent, egy kod olvashatosaga nem a tomorsegetol fugg, ezt talan nem kell reszleteznem). Persze, berakhatsz egy break-et a ciklus vegere, bizonytalansagban tartva a kod olvasojat, hogy mi is tortenik majd meg, ez kulonosen akkor megteveszto, ha kozben mar a hibakezeles reszekent felszabaditasz eroforrasokat, amik a rendszerhivas elofelteteleinek szamitanak. Hat ettol aztan nem lesz olvashatobb a kod, de meg csak rovidebb sem. A ciklus utolso soraig ott marad a bizonytalansag, hogy a ciklus megint lefut.

De most oszinten, miert logikusabb azt irni, hogy:
- ezt a fuggvenyt addig hivom, amig hibaval ter vissza, ha ezzel a hibaval, akkor tenyleg hivom, minden mas esetben viszont tulajdonkeppen nem is.
mint:
- ezt a fuggvenyt addig hivom, amig ezzel a hibaval ter vissza, minden mas esetben megyek tovabb.

ui:
1. A pelda nem az errno-val bizonyitja a goto letjogosultsagat, pusztan egy valos pelda, az errno helyen allhatna mas is. Mar az is elgondolkoztato, hogy ezt egyaltalan ide kell irnom.
2. a C-re vonatkozo megjegyzesed nem lehet komolyan venni, sajnalom. A C-nek nincsennek hulyesegei. A kepzetlen es trehany C programozoknak vannak hulyesegei. A nyelv erejet pont az egyszerusege adja, arra es ott kell hasznalni, amire valo.

Egyfelől fájdalmas volt olvasni, hogy valaki elront valamit, te meg egyből levonod a következtetést, hogy akkor az ő módszerével LEHETETLEN jobban megcsinálni, pedig teljese egyértelmű, miről beszélt, de akkor segítek, hogy felfogd te is:
do
{
//...
} while (errno == xy);

Másfelől az is fájdalmas volt, hogy "A C-nek nincsennek hulyesegei."
Süt belőled, hogy fogalmad sincs, miről beszélsz, de NAGYON szereted a C-t, és valaki megtámadta és úristen.
----
India delenda est.
Hülye pelikán

A bacsi analfabeta, vagy mi? Egyreszt egy szoval sem irtam, hogy _lehetetlen_, meg veletlenul sem. Masreszt egy 4 soros kodot kellett volna olvashatobb formaba onteni, ugy, hogy a funkcionalitas nem valtozik. Erre egesz eddig nem jott meg korrekt valasz, bar a tiedben van potencial, csak hat eppen ezzel is elvereznel egy interjun, mivel nem teljes. Tenyleg nem megy ennel jobban? ;)

A tobbire meg csak: ROFL!

"A kepzetlen es trehany C programozoknak vannak hulyesegei. A nyelv erejet pont az egyszerusege adja, arra es ott kell hasznalni, amire valo."

+1

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

1) Ahhoz, hogy ekvivalens kódot lehessen írni, tudni kellene, hogy mi van tovább.

2) Egy szóval nem mondtam, hogy profi C programozó lennék.

3) "De most oszinten, miert logikusabb azt irni, hogy:". Ha már logika... számomra logikusabb lenne az, hogy lefuttatom a kódot, ha valami hiba keletkezik arról egy kivételt kapok és nem különböző visszatérési értékeket/globális változókat ellenőrizgetek orrba-szájba. A felszabadításhoz meg nem goto-zok össze-vissza, hanem egy jól definiált szakaszba beleírom, amit kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

C programozáshoz hidegvér és gondos odafigyelés kell. Vagyis tartania kell magát az embernek néhány gyakorlathoz, amire nem különösebben szórakoztató odafigyelni. (Pl. ha erőforrást foglal le az ember, akkor rögtön a lefoglalás után ellenőrzi a sikerességet, majd rögtön beírja a cleanup címke után a felszabadítást is. Tudom, hogy ez nem valami szórakoztató, de ha ennyi önkontrollt képes gyakorolni az ember, akkor nem lesz gond a C programozás.)

1. A profi programozó ritka. A legtöbb programozó a balfasz és a profi között van valahol, és bizony követ el hibákat.
2. Ha ingyen ki lehet szűrni hibákat, miért hagynánk meg a lehetőséget? Persze nincs ingyen, mert a begyöpösödött C kóderedet nem fogod tudni rávenni, hogy haladjon egy kicsit a korral, de a nyelvi lehetőségek megvannak rá, hogy költség nélkül szűrjünk típushibákat. Ha úgy programozol C-s hatékonysággal, hogy soha nem találkozol pointerekkel, már a hibák felét elfelejtheted.
----
India delenda est.
Hülye pelikán

1. Egyáltalán nem ritka. Aki programozásból él, az profi, hiszen ez a szó jelentése. Legfeljebb nem jó programozó. Ez pedig azért van, mert akkora nagy az igény a programozókra, hogy "everything goes", még a leghülyébbek is megtalálják a helyüket. Olyan programozó pedig nem lesz soha, aki nem hibázik.

1. Ahogy mondtam, a balfasz programozónak se C, se C++ nem való.

2. Az a baj, hogy nincs ingyen, és a legtöbb ilyen megoldás még csak nem is teljes. A C++ által C-hez hozzáadott feature-ök többsége csak az esetek többségében véd, a hézagok viszont olyan bonyolult esetekben jönnek elő, amikor a bonyolultság miatt a javítás költsége már sokszorosa az egyszerű C-s hiba javítási költségének.

Példák:
- Type safety nem garantálható memory safety nélkül. A C++ típusellenőrzése bizonyos hibákat kiszűr, de mivel nyersen hozzáférsz a memóriához, ezért tulajdonképpen semmi garancia nincs. Sőt, direkt eszközöket kapsz ahhoz, hogy a típusrendszert megkerüld (const_cast, reinterpret_cast).
- Konstruktor. Elvileg arra jó, hogy ne lehessen egy objektumot használni az inicializálása előtt. Ha nagyon vágod a C++-t, biztos tudsz olyan példát mutatni, ahol egy objektumot naivan használsz az inicializálása előtt (és valószínűleg el is száll tőle a program).
- A kivételek bizonyos esetekben hasznos feature, azonban a hozzáadása a nyelvhez nem csak hozzátesz, hanem el is vesz egyúttal. Még pedig azt, hogy ránézésre megmond a kódról, hogyan fog alakulni a vezérlés a kódban. Ez problémákat okozhat, és exception safe kód írása ugyanolyan önfegyelmet és odafigyelést igényel, mint az, hogy C-ben mindig felszabadítsa az ember az erőforrásokat.

A RAII-t hasznos feature-nek tartom, bár nekem a Go defer statementje jobban tetszik.

Az is dob egy picit a kényelmen, hogy a C++ maga generálja le a virtuálismetódus-táblákat, míg C-ben ezeket kézzel kell megírni.

Igazán a template-ek az a feature, ami bizonyos esetekben nagyon hasznos tud lenni, és C-ben nem igazán oldható meg jól.

"A C++ által C-hez hozzáadott feature-ök többsége csak az esetek többségében véd"
Mar az is rengeteget szamit am...

Az exceptionokre: erdekes, a java fejlesztok sosem panaszkodnak arra, hogy nem tudjak kiszamolni a vezerlest. Mert nem is kell, ha jol van dokumentalva az adott metodus, es lehet tudni, hogy milyen exceptionoket dobhat. Javaban ezert resze a metodus definiciojanak a dobhato exceptionok listaja, es ezert ordibal a javac is, ha nem listazott exceptiont dobsz. C++ -ban meg le kell rendesen dokumentalni a metodust.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Azert ez igy nem igaz.
Vannak az un. checked es unchecked Exceptionok, az utobbiak a RuntimeException-bol szarmaznak.
Ez uttobiakat nem kell feltuntetni a metodus szignaturajaban, es elkapasukat sem kenyszeriti ki senki, ilyen peldaul a NullPointerException, a NumberFormatException meg meg sok minden mas.

A checked exception mas tema, azokat valoban fel kell tuntetni a szignaturaban.

"1. Ahogy mondtam, a balfasz programozónak se C, se C++ nem való."

Ahogy mondtam, nem mindenki profi, aki használja a nyelvet, a valóságban kell élni, nem egy ideálban. Ráadásul a profi is hibázik.

"2. Az a baj, hogy nincs ingyen, és a legtöbb ilyen megoldás még csak nem is teljes."

De, a legtöbb ingyen van (kivételek: kivételek és RTTI). És persze, mindent meg lehet kerülni, ettől alkalmas a nyelv rendszerprogramozásra, viszont könnyebben betartatható. Nagyon jó nyelvi eszközök vannak a biztonságosabb kezelésre, és statikus ellenőrzővel ezek kikényszeríthetők.

Az meg, hogy pl a virtuális táblát generálja neked nem pusztán kényelem, hanem bugprevenció. Mert előbb-utóbb el fogod cseszni.
----
India delenda est.
Hülye pelikán

Na most ki a C kóder, aki szokott C-ben gányolni valamit, vagy aki tényleg tudja, hogyan kell C-ben programozni?

Ha a C++-t azért találták ki, hogy a gányolóknak kevesebb hibalehetőségük legyen, akkor valamit kurvára elcsesztek, mert "handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."

Aki nem tud programozni, az használjon Javát, PHP-t, vagy bármi biztonságosabb nyelvet. Azoknak nem való sem a C, sem a C++.

Legtobb C koder nem is akkarja ellenorizni, amikor nem teszi.
Majd dob egy SIG11 -et, es megsporoltak egy draga if -et.

Ha kod jelege olyan, hogy ellenorzni szeretne, akkor van egy fugvenye vagy makroja, ami megteszi es azt hivja malloc helyett.

Ha olyan alkalmazast szeretni, ami nem doglik meg memoria hiany miatt varatlanul, akkor initcilizalas, utan az allocallas tilos.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

rendszergazdai szempontbol hozzaszolnek ehhez a mallcohoz.

legalabb az elereheto forraskodu programoknal jo lenne, ha ilyen esetekben legalabb a __FILE__, __LINE__ ertekeket kiirna a sor. Okes, core-bol visszaallithato, de az meglehetosen sok macera.

Altalaban egy eredmenytelen malloc nem a memoriaelfogyasra utal, hanem
- programhibara
- konfiguracios (rendszergazdai) hibara
- dokumentacios hibara
- kernelhibara

Ugyan programozi szempontbol a SIGSEGV ugyan olyannak tünik, mint if() exit; azonban uzemeltetoi szempontbol van ertelme ezeket kulon kezelni.

Ja, ha uzemeltetesi szempontok elokerulnek, en is olyan makrot hasznalok ami legalabb ezeket kiirja, foleg, ha lusta vagyok minden egyes lehetoseghez hiba uzenetet firkalni :)

De pl. egy jateknal gyakran fontosabb a 20ns faster, reges regen lattam olyan eseteket, hogy out of memory mondott a jatek, pedig nem is az volt a hiba :)

Servicnel, neha alkalmazok olyan technikat, hogy nem nezem mindig a visszateresi erteket, csak a legutolso helynel, es ott koveteztetek vissza hol tortent hiba, es jelentem azt, hiba eseten ez sokkal dragabb megoldas, de hibatlan esetben olcsobb.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem hiszem, hogy ez így lenne, egyszerűen van olyan, amikor egy probléma egymásba ágyazott ciklusokat kíván meg, tipikusan ilyen, amikor mátrixokkal dolgozol. Persze lehet mindenre külön függvényt csinálni, és elrejteni az egymásba ágyazottságot, de sokszor pont az bonyolítaná el a kódot.

csak példa, hibát tartalmazhat, fejből irom, nem is ez a lényeg. 


handle_t* archive_open(char* filename)
{
   handle_t* handle = NULL;
   FILE* file = NULL;
   header_t* header = NULL;
   lofasz_t* lofasz = NULL;

   handle = malloc(sizeof(handle_t));
   if (!handle) {
      global_error=E_NOMEM;
      goto error;
   }

   file = fopen(filename, ... );
   if (!file) {
      global_error=E_FILEERROR;
      goto error;
   }

   header = malloc(sizeof(header_t));
   if (!header) {
      global_error=E_NOMEM;
      goto error;
   }

   if (fread((void*)header,sizeof(header_t),1,file) < sizeof(header_t))  {
      global_error=E_FILEERROR;
      goto error;
   }

   lofasz = malloc(sizeof(lofasz_t)); 
   if (!lofasz) {
      global_error=E_NOMEM
      goto error;
   }

   blablabla
   ....
   ....

   global_error=E_OK;
   return handle;

  error:
   if (lofasz) free(lofasz);
   if (header) free(header);
   if (file) fclose(file);
   if (handle) free(handle);
   return NULL;
}



handle_t *archive_open(char* filename)
{
   handle_t *handle = NULL;
   FILE* file = NULL;
   header_t *header = NULL;
   lofasz_t *lofasz = NULL;

   global_error = E_NOMEM;
   if ((handle = malloc(sizeof(handle_t))) == NULL)
      return NULL;
   if ((header = malloc(sizeof(header_t))) == NULL)
      goto error1;
   if ((lofasz = malloc(sizeof(lofasz_t))) == NULL)
      goto error2;

   global_error = E_FILEERROR;
   if ((file = fopen(filename, ... )) == NULL)
      goto error3;
   if (fread((void*)header,sizeof(header_t),1,file) < sizeof(header_t))
      goto error4;

   blablabla
   ....
   ....

   global_error = E_OK;
   return handle;

error4:  fclose(file);
error3:  free(lofasz);
error2:  free(header);
error1:  free(handle);
         return NULL;
}

---
pontscho / fresh!mindworkz

Nekem így valahogy jobban tetszene.
Szerk: és ez így mondjuk nem is túl logikus, jobb lenne rögtön a struktúrának lefoglalni a memóriát, azt ellenőrizni, majd a fájl megnyitást is. 


typedef struct {
   handle_t* handle
   FILE* file;
   header_t* header;
   lofasz_t* lofasz;
   char* filename;
} ARCHIVE_FILE;

int archive_open(ARCHIVE_FILE* afile)
{
   afile->handle = NULL;
   afile->file = NULL;
   afile->header = NULL;
   afile->lofasz = NULL;

   afile->handle = malloc(sizeof(handle_t));
   if (!afile->handle) return E_NOMEM;

   afile->file = fopen(afile->filename, ... );
   if (!afile->file) return E_FILEERROR;

   afile->header = malloc(sizeof(header_t));
   if (!afile->header) return E_NOMEM;

   if (fread((void*)afile->header,sizeof(header_t),1,file) < sizeof(header_t)) 
      return E_FILEERROR;

   afile->lofasz = malloc(sizeof(lofasz_t)); 
   if (!afile->lofasz) return E_NOMEM

   blablabla
   ....
   ....

   return E_OK;

}

void archive_close(ARCHIVE_FILE* afile)
{
   if (afile->lofasz) free(afile->lofasz);
   if (afile->header) free(afile->header);
   if (afile->file) fclose(afile->file);
   if (afile->handle) free(afile->handle);
}


...

if (archive_open(afile) != E_OK) {
   archive_close(afile);
}

Ez eszembe jutott nekem is, de mivel a goto volt a lenyeg az a resze nem erdekelt. Amugy ha mar, pl. akkor nem malloc()-kal foglalunk ilyen strukturakat, mint pl. a handle, hanem calloc()-kal. Nem (! afile->header), hanem (afile->header == NULL), a tobbi oke, de az mar izles kerdese. Fokent attol fugg, h az ARCHIVE_FILE allokacioja hol es ki altal tortenik. :)

---
pontscho / fresh!mindworkz

Én ezzel egyáltalán nem értek egyet. A calloc-os inicializálás abszolút nem sztenderd. Egyrészt átláthatatlanná teszi a kódot (most hol is inicializáltam a tagokat? Jaaa, hogy memóriafoglalással együtt?), másrészt elfed magasabb szintű inicializálási problémákat. Szerintem egy calloc-cal inicializált struktúra sohasem vezet jóra, akkor már inkább legyen init függvény vagy explicit memset.

Nem allitottam, h standard (c-ben legalabbis, mas nyelveken de), viszont nagyon kellemes tud lenni, ha legalabb a sajat szabalyaid kovetkezetesen betartod, h az altalad allokalt struktura tartalma nem random, hanem kovetkezetesen nulla. Az h legyen egy kulon init fuggveny, ez senkit nem tart vissza, ahogy semmilyen magasabb szintu inicializalasi problemat sem fed el, mert senki nem mondta, h utana nem toltheted fel az adott adathalmazt akar kezdo adatokkal. :) Az meg, h calloc() vagy malloc()+memset() (de akkor mar inkabb bzero()), mocskosul mindegy. Ez pont olyan eszkoz, mint a goto, tudni kell hasznalni.

---
pontscho / fresh!mindworkz

Végül is ez is egy elfogadható szemléletmód amit ha egymagad tartod karban a kódot a legtöbb esetben el is lehet fogadni. Viszont ezt nem hinném, hogy lehetne policy-ként alkalmazni, hiszen nagy struktúrák esetén bizony overhead-el jár, ha először mindent lenullázol és utána egy init függvénnyel a nem nullára inicializálandó tagokat beállítod. Sőt, elképzelhető olyan eset is, hogy bizony egyes nagy struktúra tagok csak később lesznek beállítva, így ezeknél végképp overhead-es a dolog (főleg sok foglalás esetén). Azt viszont, hogy legyen egy init függvény ami minden inicializálást igénylő tagot a megfelelő (ha kell memset-tel 0) értékre állít már minden esetben lehet alkalmazni, magyarán policy-ként lehet rögzíteni ennek a kötelező implementálását. Ez nagyobb, több emberes projektek esetében már inkább alkalmazható séma. A másik dolog, ami miatt ellene vagyok a 0-ra inicializálásnak az az, hogy nem véletlen, hogy maga a c szabvány ezt nem definiálja. Ugyanis fölösleges ezt ökölszabályként megfogalmazni, mivel azért van a programozó, hogy ezekre a dolgokra figyeljen. Persze nem kötekedni akarok, mint ahogy mondtam a te szemléletmódod is elfogadható, viszont policy-ként nem rögzíthető, a nagy projektek pedig megkövetelik az ilyen szabályokat.

Elkoveted azt a hibat, hogy folyamatosan strukturakrol beszelsz, ahol a meret adott. A nullara (vagy amire eppen akarod) inicializalas maris ertelmet kap, mihelyt buffert allokalsz, aminek a hasznos adattartalma valtozo. Ebben az esetben a calloc() hasznalata maris indokoltta valhat, tekintve, hogy rendszertol fuggoen lenyegesen gyorsabb lehet, mint egy malloc()+memset() paros. Viszont a calloc() hasznalatanak a letjogusultsaga is megkerdojelezheto, ha nem csak az adat, hanem a buffer merete is dinamikusan valtozik, mert ebben az esetben pl. a realloc() nem fogja az ujonnan foglalt teruleteket inicalizalni (feltetelezve, hogy a buffer novekszik), tehat szukseg lesz a memset()-re, azaz a calloc() "gyorsasagabol" csak az elso foglalaskor profitalsz esetleg. Szoval szerintem nincs egyseges recept (ahogy a goto hasznalatara sincs), meg persze, az ember lehet bator es nem fontos azt a buffert inicializalni ;) Gondolom, "nagy projektekben" egyebkent sem hasznal senki ilyen ordogi talalmanyt :P

Én nem a calloc létjogosultságát kérdőjeleztem meg, természetesen van értelme bizonyos esetekben, csak nem hinném, hogy az eredetileg írt Amugy ha mar, pl. akkor nem malloc()-kal foglalunk ilyen strukturakat, mint pl. a handle, hanem calloc()-kal. általános elv megalapozott. Viszont az általad leírtakat nem egészen értem. Kezdve azzal, hogy miben különbözik egy bármilyen memória foglalás egy másiktól, szerintem tök mindegy, hogy mi lesz benne, struktúra, tömb, egyszerű int, bármi. A másik amit nem tudok, hogy mit értesz "buffer allokálás" alatt? A malloc + memset páros tudtommal semmi, jobban mondva nagyon elhanyagolható overhead-el rendelkezik a calloc-hoz képest. A malloc ugye jelzi a futtató rendszer felé, hogy ennyi vagy annyi memóriára van szükségem. A rendszer jobb esetben visszajelez, hogy tessék, itt van a memória. Ez a rész közös a malloc-ban és a calloc-ban is. A malloc itt visszatér, míg a calloc végigmegy a területen és lenullázza. A memset pedig ugyan ezt végzi el a malloc után, így a függvényhívás overhead-e az, amivel számolni kell.

A különbség a két elv között:
Pontscho módszere: memóriafoglalás + nullázás + nem nulla tagok inicializálása
Én módszerem: memóriafoglalás + összes tag inicializálása a megfelelő értékekre
Pontscho módszere lehet, hogy kényelmesebb, de a nem nullára inicializálandó tagok kezdeti 0-ra állítása fölösleges overhead.

Valoban overhead, de az inicializalas jobbara olyan musor, ahol ez a plusz teljesitmenyigeny elhanyagolhato ahhoz kepest, h biztosan tudom mi az egyes valtozok kezdeti erteke es erre szamithatok is. Nem veletlen kezdett ez a modszer terjedni az "ujabb" nyelvekben.

---
pontscho / fresh!mindworkz

Na jó, szerintem zárjuk le a vitát, mert nem tudunk dűlőre jutni. A c mindig is arról szólt, hogy a lehető legnagyobb szabadságot, és ezzel együtt a lehető legnagyobb felelősséget nyújtja a programozók számára. Az új nyelvekben sok minden elterjedt, viszont egy új nyelv sem tudta elfoglalni a c helyét pont amiatt, ami: a leghatékonyabb magas szintű programnyelv. Ha olyan lenne, mint más nyelvek már nem lenne hatékony -> elveszne a legnagyobb előnye. Annyit kell észben tartani, hogy a tagokat és a változókat bizony inicializálni kell. Ezt szerintem fölösleges elfedni a calloc-cal, mert sok esetben overhead és számomra nem túlságosan c-s. Az újabb nyelvekben amúgy éppen hogy nem a te szemléletmódod terjedt el, hanem az inicializáló függvény, amit ott konstruktornak hívnak. Nem véletlen, hogy egy-egy osztályt nem lehet konstruktor nélkül példányosítani. Ez egyrészt végzi a dolgát, inicializál, másrészt kötelezősége miatt örök mementóként áll a programozók előtt: Itt vagyok, én vagyok a konstruktor, tedd meg azt a szívességet, hogy arra használsz, ami a hivatásom: az inicializálandó tagokat állítsd be velem! Ha 0-ra, akkor 0-ra, ha másra, akkor másra! A c++ new operátor sem calloc-ot aztán konstruktort hív :)

A c++ new operátor sem calloc-ot aztán konstruktort hív :) 


aeryn:Downloads pontscho$ gdb main
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug 15 16:03:10 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
No registers.
Reading symbols for shared libraries ... done

(gdb) break 4
Breakpoint 1 at 0x100000f04: file main.cpp, line 4.
(gdb) r
Starting program: /Volumes/pontscho/Downloads/main 
Reading symbols for shared libraries ++. done

Breakpoint 1, main () at main.cpp:4
4		char *tmp = new char[128];
(gdb) n
5		return 0;
(gdb) dump memory main.dta tmp tmp+128
(gdb) q
The program is running.  Exit anyway? (y or n) y
aeryn:Downloads pontscho$ hexdump -n 128 -C main.dta
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080
aeryn:Downloads pontscho$

Biztos?

---
pontscho / fresh!mindworkz

Mármint hogy értve nem hiszel a debug/release módban? A debug mód debugolásra használható, a release meg kiadásra :) Értelem szerűen szükség van mindkettőre: release-ban a compiler rengeteg dolgot átszab a kódodban, ezért nincs lehetőséged egy ciklus nyomkövetésére, mivel az a ciklus abban a formában, ahogy leírtad már nem létezik, gépi kódon egész más történik, ezért nem jeleníthető meg a kódodra illesztve. A debug mód pedig arra való, hogy mindennemű optimalizálás nélkül az a kód hajtódjon végre, amit te leírtál, ezért bármikor bele tudsz tekinteni, hogy az adott ponton mi az újság. Ez nem hit kérdése, minden c compiler így működik. Persze megteheted, hogy nem használod a debug módot, de úgy csak black box módszerrel tudsz bármit is kipróbálni a kódodban, beleőszülsz, mire egy egyszerű ++val <-> val++ hibát felfedezel :)

Mármint hogy értve nem hiszel a debug/release módban? A debug mód debugolásra használható, a release meg kiadásra :) Értelem szerűen szükség van mindkettőre: release-ban a compiler rengeteg dolgot átszab a kódodban, ezért nincs lehetőséged egy ciklus nyomkövetésére,

Pont ezert nem hiszek a debug modban, en azt akarom debuggolni majdan, ami elesben fog futni, nem egy kvazi pszeudo kodot.

mivel az a ciklus abban a formában, ahogy leírtad már nem létezik, gépi kódon egész más történik, ezért nem jeleníthető meg a kódodra illesztve.

Eleg csunya lenne ha gepikodra forditva vegeredmenyben nem az tortenne amit en mondtam neki. :) Egyebkent ha nem jelent problemat az asm, akkor ennek a problemanak minden maradeka eltunik, de egy jobb compiler/debugger nem ijed meg attol ha a kod le van mar optimalizalva, akkor is elbir vele.

Nem egyszer debuggoltam mar binarist forras es debug infok nelkul, nem egy nagy ordongosseg.

Ez nem hit kérdése, minden c compiler így működik.

Bizony nem. Alapvetoen egy compiler nem kulonbozteti meg a ket modot, ez egy felette megvalositott szeparacio ahol csak a forditasi/debug/optimalizacios parameterekkel jatszanak.

Persze megteheted, hogy nem használod a debug módot, de úgy csak black box módszerrel tudsz bármit is kipróbálni a kódodban, beleőszülsz, mire egy egyszerű ++val <-> val++ hibát felfedezel :)

Ez bizony netto marhasag. :)

---
pontscho / fresh!mindworkz

"Eleg csunya lenne ha gepikodra forditva vegeredmenyben nem az tortenne amit en mondtam neki."

Hát pedig, hallottál már az observable behaviorról? Amíg úgy tűnik, mintha azt csinálná, bármit csinálhat.
Sőt, még azt is megsértheti a fordító a return value optimizationnel.
----
India delenda est.
Hülye pelikán

Nem az történik, amit te leírsz. Van egy ciklusod, aminek a belében te használsz egy tmp változót, pl. sorösszeg, amit csak azért deklarálsz, hogy debugban megnézhesd az értékét és hozzáadod egy másik változóhoz. Release-ben ennek a tmp változódnak nyoma sem lesz, mert a fordító látja, hogy más egyébre nem használod, így közvetlen hozzáadja ahhoz a változóhoz, amihez szummázni akarod és primitív esetben nem hoz létre tmp lokális változót. Tehát nem az a kód, amit te leírtál.

Ebben a formaban meg igazad is lehet, csakhogy ez nem debug/release mod, hanem szimpla kodoptimalizalas. Viszont az teljesen mindegy, h a stacken elhelyezett valtozorol beszelunk, vagy ha ez a vegen ki van fejtve egy konstansra (mint pl. a htonl() "fuggveny" ami glibc-ben valojaban egy makro ami csekkolja, h konstansrol vagy valtozorol van szo es ennek megfeleloen fordul le, mondjuk ezt is utalom, mert gcc4.2-ig konzekvensen el tudta kurni a kifejteset a compiler), vagy szimplan egy regisztert hasznal erre.

Ha az algoritmus mukodeset akarom ellenorizni, akkor - legfeljebb az elso korben - kikapcsolom, de utana mar nem. Mert nem azt akarom ellenorizni, h milyen jol tud O0-nal a stacken osszeadni, hanem vegeredmenyben azt muveli-e amit akarok. Ehhez, ha indokolt, akkor a leforditott asm kodjat szedem elo ellenorzesre.

Tehat vegeredmenyben a kod ugyanaz amit leirok, csak - ha akarom - szet optimalizalja a fordito, de ugyanazt fogja csinalni amit leirtam neki. (Es itt jon kepbe tetra altal is emlitett observable behavior, amit azert odafigyelessel meg lehet oldani).

---
pontscho / fresh!mindworkz

Most az lenne a bizonyítok a calloc-ra, hogy 0 a memóriaterület? A karakter alapértéke, a char() épp 0. Simán lehet, hogy végigment rajta, és inicializálta 0-ra, nyílván nem ez történt, de szemantikailag igen. Az, hogy beépített típusokra optimálisabb megoldás is van, az más kérdés.
----
India delenda est.
Hülye pelikán

Ez egy tipikus problémaforrás: debugban jól fut a kód, release-ben miért nem? Hányszor elő jött már. Tipikus inicializálási probléma: nem inicializálsz le mondjuk egy bool-t. Debugban false-ra inicializálódik, mert álalában a debug módú fordításkor megteszi ezt a szívességet a compiler. Aztán elindítod release-ben és csodák csodája valami elbarmolódik, mivel NEM calloc hívódik, hanem malloc és így memóriaszemét van a területen. Az ilyen hibákra már csukott szemmel rámondom, hogy inicializálatlan változó.

Na most a dinamikus tömböket mindig inicializálja a fordító, a default konstruktorral, ami beépített típusoknál mindig az adott típus 0-ja. Szóval ez nem debug-release különbség. Az, hogy pontosan hogyan inicializálja (végigmegy ciklussal az elejétől, hátha kivételt vált ki a char() (lol), vagy memset, esetleg egyből calloc), már változhat, de egy charnál ennek nincs jelentősége: a szemantika az, hogy 0-nak KELL lennie, akár debug, akár release.
----
India delenda est.
Hülye pelikán

Nem. Az egyszerű típusoknak nincs konstruktoruk. Tehát ha leírod, hogy bool b; az undefined. Ugyan úgy, mintha leírod, hogy char c; az nem 0, hanem 0..255 memóriaszemét. Primitív típusoknak nincs konstruktoruk. A c++ ezért nem teljes oo nyelv, mivel a primitív típusok nem osztályok. Így release-ban meghatározhatatlan egy primitív tag vagy változó értéke ha nincs inicializálva. Amúgy eredetileg c-ről beszéltünk, nem? :)

Ezt rosszul tudod. Ha leírod, hogy bool() az false lesz, ha leírod, hogy char() az 0. VAN konstruktoruk, épp úgy, mint egy POD osztálynak. Max nem tartozik hozzá függvény. Szemantikailag van konstruktor.
Ha AUTOMATIKUS storage classban egy beépített típust hozol létre, az valóban nem fog inicializálódni, ha nem inicializálod explicit, ez performance optimalizálás. Tehát, mint említettem, C++-ban pontosan meg van mondva, mikor garantált az inicializálás, és hogy akkor mire. Ebben az esetben nincs inicializálás, ugyanúgy ha konstans méretű tömböt hozol létre a stacken akkor sincs, de pl dinamikus tömbnél már van, és az adott típus alapértéke, default konstruált értéke, ami 0 beépített típusoknál.
----
India delenda est.
Hülye pelikán

Jaja, mea culpa, most olvastam vegig a szalat, valoban en ertettelek felre. Az en olvasatomban a calloc() "hirneve" forgott kockan es nem vettem figyelembe, hogy mar eredetileg is strukturak inicializilasarol szolt a tortenet. Tegyuk hozza, kevesebb mint 5 orat aludtam, igy nem meglepo, hogy az en keszulekemben volt/van a hiba ;) Viszont a calloc() = malloc()+memset() feltetelezes egy tevedes, errol konnyen meggyozodhetsz egy par soros kod segitsegevel is, persze nem 1 byte-os bufferek hasznalataval kell kiprobalni, hanem mondjuk X * PAGESIZE. Egyebkent feltehetoen a Sun-nal tudtak volna neked meselni a malloc() vs. calloc() hasznalatarol (tar), igaz nem a sebesseg, hanem az inicializalas tenye miatt. No mindegy, engem aztan nem erdekel ki mit hasznal, en hasznalok goto-t, calloc()-ot es irok assembly kodot is, lehet kovet dobalni, majd visszadobalok, csak elobb elugrok a pekhez ;)

Amire én a labeles megoldást találtam a leghatékonyabbnak: Egy rekurzió nélküli fill-ező algoritmus. Adott egy kezdő koordináta és négy kiterjesztési irány sorrendben: fel ( 0 ), jobbra ( 1 ), le ( 2 ) és balra ( 3 ). Veszem a kezdő koordinátát és vizsgálom a kiterjeszthetőséget az adott irányokba, ha kiterjeszthető akkor egy listába felveszem az épp vizsgált elem koordinátáját és kiterjesztem az újat. Hogyha egy adott koordináta nem terjeszthető ki kiveszem a listából az előzőleg félbehagyott elemet és attól az iránytól szeretném folytatni, ahol előzőleg abbahagytam. Ha nincs lehetséges kiterjesztés és vissza kell lépni tárolom 'zsákutca' elem koordinátáját, és a listából kivett folytatandó koordináta, a 'zsákutca' elem koordinátája és a kötött kiterjesztési sorrendből tudom, hogy melyik irányban kell folytatni a kiterjesztést.

Ez kódban így néz ki:

if( back == false ) { //Ha nem vagyunk backtrack-ben, a 0. kiterjesztési iránnyal kezdünk
goto LABEL_EXPANDSTATUS_0;
} else {
//Ha épp backtrack-ben vagyunk meg kell vizsgálni, hogy milyen koordinátáról léptünk vissza és aszerint kell folytatni a kiértékelést
if( _x == prevX ) { // X == PREVX
if( _y < prevY ) { // Y < PREVY
goto LABEL_EXPANDSTATUS_3;
} else { // Y > PREVY
goto LABEL_EXPANDSTATUS_1;
}
} else {
if( _x < prevX ) { // X < PREVX
if( _y == prevY ) { // Y == PREVY
goto LABEL_EXPANDSTATUS_2;
}
} else { // X >PREVX
if( _y == prevY ) { // Y == PREVY
goto LABEL_EXPANDSTATUS_4;
}
}
}

LABEL_EXPANDSTATUS_0:
if( FELFELEkiterjesztheto ) {
backTrack_->push_back( _y * _map->width_ + _x );
[...]
expandStatus = 0;
goto LABEL_EXPANDSTATUS_ENDEXPAND;
}
LABEL_EXPANDSTATUS_1:
if( JOBBRAkiterjesztheto ) {
backTrack_->push_back( _y * _map->width_ + _x );
[...]
expandStatus = 1;
goto LABEL_EXPANDSTATUS_ENDEXPAND;
}
LABEL_EXPANDSTATUS_2:
if( LEFELEkiterjesztheto ) {
backTrack_->push_back( _y * _map->width_ + _x );
[...]
expandStatus = 2;
goto LABEL_EXPANDSTATUS_ENDEXPAND;
}
LABEL_EXPANDSTATUS_3:
if( BALRAkiterjesztheto ) {
backTrack_->push_back( _y * _map->width_ + _x );
[...]
expandStatus = 3;
goto LABEL_EXPANDSTATUS_ENDEXPAND;
}

LABEL_EXPANDSTATUS_4:
expandStatus = 4;

LABEL_EXPANDSTATUS_ENDEXPAND:
if( expandStatus == 4 ) {
//BACK, nincs kiterjesztheto irany
} else {
//VAN kiterjesztheto irany, ennek a lemanagelese
}

Persze meg lehet írni goto nélkül, de akkor ciklus iterációnként kell bele egy switch, vagy egy függvény pointer tömbből való hívás - és ez sajnos egy nagyon kritikus függvény, sokszor fut le így a performance volt az elsődleges. Szerintem ez egy jó példa a goto indokolt használatára.

SZERK.: Sajnos a behúzásaim eltűntek így nagyon csúnya a kód, nem értem, a < c o d e > blokkon belül miért nem maradnak meg a whitespace karakterek....

ha olyan nagyon optimalizalni akarok, akkor _asm aztan adj neki.

vagy csinaltam mar olyat, hogy a kesz kitesztelt kodbol a c forditoval asm outputot generaltam, aztan abban kitomboltam magam. // igaz lehetett utana ujra tesztelni, de amikor tenyleg valami sokmillioszor lefuto ciklus kozepen lehet sporolni, mert mondjuk meg az adott c altal kikopott asm-en is lehet huzni erosen, akkor tenyleg megeri //

Az optimalizációnak is vannak fokai. Ez egy desktop képfeldolgozó engine egyik nagyon sokszor lefutó művelete. Nem mindegy, hogy 40 msec a fillezés vagy 25, ezért optimalizáltam sztenderd c++ nyelvi eszközökkel ami nem hinném, hogy indiai kódot eredményezett volna :) Viszont az mindegy, hogy 20, vagy 19 msec, ezért mélyebben nem volt szükség, hogy belemenjek. Van embedded DSP-n futó kódunk is, ott elő kellett venni a generált assembly-t, mivel rengeteg dolgot tud párhuzamosítani a cucc, ha jól sáfárkodunk a ciklusszervezésekkel. Ott abszolút érthető és indokolt volt a lépés.

Hát ha a Studio 2012 compilere jó fordítónak minősül, akkor nem tudja. Természetesen az ilyen kulcsfüggvényeknél nem maradhat el a profilozás és ha nem lenne kézzel fogható előnye, nem trükköznék. Tisztában vagyok a modern fordítók képességeivel, de ez a verzió egy olyan logikai heurisztikát használ ki, amit pusztán a fordító gépi kód elemzése és optimalizálása nem képes felismerni, hiszen iterációnként egy előző iteráció eredményei alapján lehet csak futásidőt nyerni. A switch ugrótábláját kihasználva hasonló logikával hasonló performance lenne elérhető, de az a megoldás ugyanez pepitában, így inkább szemmel látható explicit módszerrel trükközök erősen kommentelve. Ha bízol egy tetszőlegesen választott fordító optimalizáló képességében szívesen vállalom a megmérettetést :)

Még mindig él a fejekben az az urban legend, hogy kézzel nem lehet jobb asm kódot írni, mint amit a fordítók csinálnak. Én elhiszem, hogy az optimalizációk sokat fejlődtek, és a többmagos processzorok megjelenésével a manuális optimalizálás is sokat vesztett a fényéből, de vannak olyan szituációk, amikor egy jól megírt asm kódrészletet meg sem tudnak közelíteni a jelenlegi fordítók.

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

( tetra | 2012. 12. 12., sze – 10:53 )

Sokáig gondolkodtam, mert alapvetően el tudok képzelni szükséges goto-t, meg az egyik kiskedvenc nyelvem, a DCL kötelezően használja is (nincs ciklus benne), de az utóbbi egy-másfél évben nem írtam le, és a legutóbbi használatomat is valakinek sikerült átfogalmaznia struktúrált kódra, szóval nemre szavaztam.
----
India delenda est.
Hülye pelikán

( traktor | 2012. 12. 12., sze – 11:10 )

Nem vagyok egy nagy programozo, ugyhogy cafoljon vagy erositsen meg aki jobban tudja: ugy tudom a UNIX shellscript a keves nyelvek egyike, amiben egyaltalan nem lehet goto-t csinalni.

#!/bin/sh
alias goto=break
TRAKTOR=1
SZERINT=1
while [ "TRAKTOR SZERINT" ] ; do
echo a UNIX shellscript a keves nyelvek egyike, amiben
goto $TRAKTOR
echo traktor szerint egyaltalan nem,
done
: TRAKTOR
echo egyesek szerint
echo lehet goto-t csinalni.

A fenti példa semmire sem jó csak arra, hogy jelezze a break és continue parancsokkal (vagy a nekik megfelelő vagy ehhez hasonló) konstrukciókkal meg lehet valósítani goto-szerűen működő (vagy esetleg csak annak látszó) rondaságokat.

Amúgy semmi baj a goto-val, csak ésszerűen kell használni. És mint feljebb valaki jelezte, az rosszabb, ha a nyelv elemeivel kell helyettesíteni (pl. Javaban try and catch-csel). És nem, a segédváltozók és az azzal bonyolított feltételek, vagy a mindent külön függvényben írunk dolgok nem javítják annyira az olvashatóságot - vagy annyit rontanak a sebességen -, hogy van amikor e helyett a goto jobb.

(Ja ez persze szigorúan az én véleményem.)

( r3flow | 2012. 12. 12., sze – 11:21 )

A procmailban is akad, biztos azért, hogy szebb legyen a kód. Biztosan csak én nem értem a művész úr(ak) önkifejezését. A kód egyébként nem azért ilyen, mert szétesik a böngészőben, hanem szándékosan így van formázva. És persze a goto-k...

( dacas | 2012. 12. 12., sze – 12:51 )

10 keresek más megoldást
20 goto 10

;-)

( bfoto | 2012. 12. 12., sze – 13:07 )

Legutóbb a '90-es évek közepe táján használtam általános iskolában (QuickBASIC)..
--
Direp

( NevemTeve | 2012. 12. 12., sze – 15:56 )

Épp most rakok debug-kiíratásokat egy programocskába (3700 sor). Nem bonyolítom túl, bekerül egy kiíratás a kritikus függvények elejére, egy a végére; továbbá az előbbi növeli az 'indent' értékét, az utóbbi csökkenti.

Gondolom, könnyű kitalálni, hogy mi okozza a gondot (igen, a függvények belsejében szétszórt return-ök), és azt is, hogy mi a megoldás (igen, a goto RETURN).

Mindegy, C-ben csinálsz egy wrapper függvényt és find/replace-szel kicseréled az összes függvényhívást. Még mindig egyszerűbb, mint minden returnt kicserélni egy goto-ra, főleg, ha visszatérési értéke is van.
szerk: Vagy az eredeti függvényből csinálsz wrapper függvényt, a belsejéből meg egy újat. Úgy még egyszerűbb.

( asch v | 2012. 12. 12., sze – 16:07 )

Assembler jmp és társai goto-nak számítanak? Mert ott használok.

( saxus | 2012. 12. 12., sze – 17:12 )

Ha azt nezzuk, rendszeresen hasznalok (break, continue, return). Ha maskepp nezzuk, akkor egyetlen egyszer kellett C#-ban, amikor szebb volt egy plusz flag bevezetese helyett egy gotot hasznalni. Aztan vegul at lett tervezve az a resz es az egesz nem kellett :)

Ettol fuggetlenul: nagyon ritka az az eset, amikor valoban indokolt, de mindenkep van letjogosultsaga. Persze, nem oldschool Basic mintajara.

Aki szerint azonban a break/continue/return irtando, mert rejtett goto, azokat surgosen el kell tiltani a szakmatol.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( suti | 2012. 12. 12., sze – 19:33 )

az nem programnyelv amiben van goto
_______
16,67 %

Akkor kezdjük a dolgok mélyén:

Bármely nyelven írt program végül gépi kódon fut.

A gépi kódú/assembly programokban az utasítások kb 10-20%-a "goto" = jmp (nézz utána és számold ki.)

Töröld ki az összes ilyen utasítást a világból és nem lesz egyetlen működő számítógép sem!!!

Mi az első utasítás egy PC bekapcsolásakor?

jmp .....

Ez érdekes, nem?

Minek kevered ide, hogy a magasszintű kódból mi lesz? Teljesen mindegy, mert az már a procitól függ és nem a nyelvtől. Amit a fordító generál ahhoz jó esetben már semmi közöd. Nem véletlenül nem programozunk mindent assembly-ben. Megvan annak is a helye (ahogy a goto-nak is C-ben), de amikor magasszintű nyelvekről van szó akkor az adott nyelv szabályait és megoldásait kell követni.

Nagyon is világos volt, hogy mit írtál. Az viszont nem, hogy ez miért releváns ha nem assembly-ben programozol. A magasszintű nyelvek lényege pont az, hogy ilyenekkel ne kelljen foglalkozni.
Amúgy meg kinek kéne magyaráznia?
A témában több helyre is leírtad ezt a marhaságot ami végülis igaz, csak semmi köze a témához. Nem az volt a kérdés, hogy jmp utasítás szokott-e lenni a programjaidban hanem, hogy goto-t (ami már magasabb szintű nyelvekben van) használsz-e.

+1

Az én tapasztalatom, hogy vannak olyan helyzetek (pl: összetettebb algoritmus) amikor a goto nélküli megoldás az átláthatatlanabb és/vagy lassabb kódot eredményez, illetve kódsorok/részletek fölösleges megismétlését kényszeríti ki.

Egyébként nincs olyan programozó aki nem használna goto-t!!!
Mivel végül minden program gépi kódban fut ott a goto = jmp, ha ezt eltávolítanánk egyetlen program se futna.
:-)

Én közvetlenül is használom az assembly nyelvet, ott egyáltalán nem kérdéses a "goto" használata.

Magasabb szintű nyelveken is lehet és néha érdemes is használni, természetesen ha indokolt, de ez minden utasításra evidensnek kellene lennie.

Átláthatatlan kódot ráadásul goto nélkül is lehet írni, akkor miért ez az utasítás a bűnbak?!

...hülye kérdés volt, mert az emberek bűnbak keresési reflexe miatt van ez...

( mzn v | 2012. 12. 12., sze – 22:37 )

Hol van NagyZ, amikor szükség lenne rá? :)

( rpsoft v | 2012. 12. 13., cs – 00:37 )

goto-t csak FORTRAN-ban, de olyat évek óta nem írtam. Viszont a try/catch/throw goto "felpántlikázott" goto-t igen.

Ez sajnos nem minden nyelvben adott lehetőség.

Tapasztalatom szerint ez csak az esetek kisebbik felében használható értelmesen, de abban a felében valóban ezt érdemesebb használni.

Itt meg lehet azon vitatkozni, hogy ezt inkább a hibakezelésre kellene használni.

Pl. én kimondottan nem szeretem azokat a "kőbe vésett" dolgokat, amik korlátozzák az eszközök hatékony kihasználását.

(try, goto, while, stb.)

( ace | 2012. 12. 13., cs – 11:46 )

Pont mostanában szerettem volna Bash-ban használni teszteléshez, jó jött volna :(
Egyéb esetekben nem szoktam használni.

---
Egy anlgaii etegyem ktuasátai szenirt nem szimát melyin serenrodbn vnanak a bteűk egy szbóan, az etegyeln ftonos dloog, hogy az eslő és az ultosó bteűk a hölyeükn lneegyek. A tböbi bteű lheet tljees össze-vabisszásagn, mgiés porbléma nlkéül oalvsahtó

( egeresz | 2012. 12. 13., cs – 12:23 )

C -ben, pascalban, ada-ban egyarant hasznaltam goto-t, csak ezekben mind mashogy hivjak.

2 specialis helyzetben van ra szukseg:

- helyben megoldhatatlan hibajelensegnel feladni a vezerlest sokkal magasabb szintre
- korutin implementacional

namarmost a korutin implementacio tuzzel-vassal irtando, mert a programozok igen tulnyomo tobbsege erre alkalmatlan, tehat a korutinos kod de facto karbantarthatatlan.
A hibajelenseg kezelesenel minden nyelvben van goto, csak altalaban mashogy hivjak.

Csak eppen eros a kisertes, hogy az adott hardverbol 30-szor nagyobb IO-t szedjek ki korutintechnikaval, mint amit 'szep, szokasos' szubrutintechnikaval ki lehet.

A hozzászólásom nem volt ezen a szinten korrekt.

A sima while(){ seek(random) read() } jellegű random olvasásnál egy kövér multithreades megoldás nagyobb raid alrendszerek esetén tud 30-szoros teljesítményszorzót adni.
A pthread megoldásnál valamennyivel (1%-2%) gyorsabb az aio() alapú megoldás.
Az aio() megoldás már nem tekinthető a feladat strukturált/szubrutin alapú megoldásának, lévén az események láncolata nem követi a C nyelv struktúráját. Hasznosabb a megoldást korutin technológiának elképzelni még akkor is, ha ez a nyelv erre sok lehetőséget nem ad.

( dejo v | 2012. 12. 13., cs – 16:01 )

Ez szerintem egészen nyelv specifikus!
Fortranban, BASIC-ben, PL/I-ben pl. igen, de Forth-ban, Pascalban, Pythonban ha akarnán sem menne! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Legtöbbet a BASH-t használom, belegondoltam.
Lusta lennék rá, van egyszerűbb és átláthatóbb annál a BASIC-ben megszokott gotonál.

Használ-e valaki a # után REM-et?
(fáradt kérdés, én is az vagyok, ne válaszoljatok rá, mert kiakadok, mint a rugó)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( GerzSonka | 2012. 12. 14., p – 20:03 )

Határozott véleményem, hogy kizárólag olyan embernek juthat eszébe goto-t használni, akinek még soha nem kellett más kódját karbantartani. Nem véletlen, hogy corporate környezetben a coding convention explicit tiltani szokta, és egy normális code officer amint meglát egy ilyet, azonnal revertálja a commitot..
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

Határozott véleményed tévedés: én akkor is szoktam goto-t rakni egy függvénybe, ha más kódját tartom karban.
Mégpediglen azért, hogy minden függvénynek csak egy kilépési pontja legyen, mégpedig az alábbiak egységes kezelése miatt: debuggolás, logolás, erőforrás-felszabadítás.