Új hozzászólás Aktív témák
-
pmonitor
aktív tag
válasz dabadab #6301 üzenetére
De pl. az egymásba ágyazott ciklusokból való kiugrást nem tudták goto nélkül megoldani. Pl. ez is változott, ha a nyelv jelentős mértékben nem is.
Meg nem véletlenül kezdi úgy a bevezetését, hogy a "sokat szidott goto utasítást". Már akkor sokat szidott volt. Még C-ben is!
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
Ereshkigal
őstag
Két hete megy ez a goto, lassan elengedhetnétek.
-
pmonitor
aktív tag
válasz Ereshkigal #6304 üzenetére
Szép lassan el. Csak még egy idézet a B. W. Kernighan - D. M. Ritchie: A C programozási nyelv című könyvből:
Bár nem kívánunk az ügyben dogmatikusak lenni, kimondjuk : minél kevesebbet használjuk a goto-t, annál jobb.
Mi lenne, ha dogmatikusak akarnának lenni?
Aztán én ezennel kijelentem: akármi is történik, a goto-val kapcsolatban ebben a topicban többet nem nyilvánulok meg.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
Silεncε
őstag
-
-
pmonitor
aktív tag
Miért van a Téma összefoglalóban a Prog.hu-s cikkek és a Prog.hu-s tudástár témák? Igaz, hogy én elfogult vagyok ezzel kapcsolatban, mert sztem csak az 1-2 nem beépített válaszadónak köszönhetünk hasznos megoldásokat(de kevés az ilyen). De ezen a fórumon is volt olyan, aki azt írta, hogy kb. azt sem tudja, hogy létezik a prog.hu. Na most ha rajtam kívül is van, aki ignorálja a prog.hu-t, akkor nem álszentség ez?
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
válasz Silεncε #6311 üzenetére
De tudomásom szerint, aki írta az összefoglalót, ő a fórumozók kérésére tette ezt. elég csak megnézni az első pár hozzászólást. Tökéletesen látszik már a #3 kicsitomi88 hsz-ében a "Majd a modiknak szólunk ha...". A modik bármit meg tudnak csinálni, de az ilyeneket sztem nem maguktól találják ki, hanem "közkívánatra". De azt is sztem. konzultáció előzte meg ebben a topic-ban. Nem tudom, hogy most is a többség ennyire reklámozná-e a prog.hu-t.
Őszintén szólva pontosan nem tudom, hogy mikor off egy hsz., de az egyik az, hogy nem a verdákról írtam, hanem a C topic-ról. A másik meg az, hogy semmi aktív magasabb rendű téma/kérdés nem volt(tehát semmilyen konzultációt nem szakítottam félbe vele.Úgyhogy attól függetlenül, hogy néha tényleg nem tudom, hogy mi off, és mi nem az, ebben az esetben mind1. De te is offoltál pl. a #6306-ban. Egyébként meg lehet ignorálni az adott kérdést/témafelvetést, ha nem tetszik.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
válasz sztanozs #6313 üzenetére
Tényleg, ezt nem is néztem, látod(csak kopiztam). A Wikipedia az első link, ami működik. Pont ezért is illene átnézni, és legalább a felülvizsgálatot elkövetni velük, mert a döglött linkek amúgy sem szépek egy oldalon.
De egyébként nem erre a problémára gondoltam, hanem hogy sztem. nem kéne 1 olyan oldalt reklámozni, mint a prog.hu. Ezzel kapcsolatban várom a véleményeket pro és kontra, hogy hánynak tetszik a prog.hu, és mennyinek nem. És főleg az indoko érdekelnének. Nekem pl. az említett dolgon kívül nagy problémám az oldallal, hogy csak úgy frissítgeti magát, önkéntesen.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
gregory91
senior tag
Az egészhez annyit hogy: a goto-t se véletlenül találták ki, van valami célja(hacsak aznap nem ittak-e többet a kelleténél).
De egy fontos,ahogy az összes többinél:meg kell tanulni megfelelően használni!Remélem itt elfér - https://sites.google.com/site/geriprojekt/ - https://github.com/kgregoryan - Az ember téved,a gép hibázik.
-
alapz@j
tag
Én magam is leadnék egy szavazatot a goto és az early return mellett :) közben pedig bedobok egy lehetséges megoldást a fentebb is vázolt hibakezelés közbeni erőforrás-deallokálási problémákra, sajnos csak a GCC fordítót használóknak:
void free_buffer(char ** buffer) {
free(*buffer);
}
...
char *buffer __attribute__ ((__cleanup__(free_buffer))) = malloc(20);
Amikor a buffer kimegy a scope-ból, auto meghívja a cleanup attribútumban megadott függvényt.
http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html -
buherton
őstag
válasz alapz@j #6326 üzenetére
Az első példában még NULL-znám a buffert, ha már a pointer pointerjét adtad át.
Kísérteties a hasonlóság a std::unique_ptr-el.
[ Szerkesztve ]
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
kovisoft
őstag
-
buherton
őstag
válasz kovisoft #6329 üzenetére
Hirtelen nem fogtam fel a kódot és azt hittem ez két külön megoldás. Igen, egyébként pont így van. Annyit tennék hozzá, óvatosan azzal, hogy “nem fog hivatkozni rá senki” .
Nem is olyan régen találtam egy elég nagy program részt ahol tömegével voltak ilyen már nem érvényes memóriára való hivatkozások. Megpróbáltam kijavítani, de csak több ilyen hibába futottam. Inkább gyorsan dobtam a módosításom és fütyürészve tovább álltam, mintha mi sem történt volna. Soha nem csináltam még ilyet, de az a katyvasz hetekre magával rántott volna. Köszöni szépen azóta is “jól” van.
Egy másik sztori. Kernel spaceben ügyködtek a “kompetens” kollegák. Egy függvény lokálban létrehozott egy struct-t, ami aztán meg is szűnt. Aztán jött egy másik függvény, ami szintén létrehozta a saját structját. Aztán jöttem én. Teljesen más helyen javítottam egy bugot, amire elkezdett a kernel pánikolni. Kiderült hogy a másik függvény structja a előző struct értékeit olvasta ki a stackről és a módosításom csúsztatott annyit a stacken, hogy pont ne passzoljanak.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
jattila48
aktív tag
válasz dabadab #6334 üzenetére
Az "illene", azt úgy értettem, hogy kötelező. Nem lehet idő- és erőforrás hiányra hivatkozni, mert később az ilyen hanyagság megbosszulja magát, ami majd többszörösen elpocsékolja a szűkös időt és erőforrást.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
buherton
őstag
válasz jattila48 #6331 üzenetére
A másik függvény a struktúrát nem inicializálta, hanem csak olvasta. Így történhetett meg ez a csodás hiba. Ez gyakorlatilag egy értékadás volt .
A többire. Amit nem javítottam ott tényleg sok mindent kellett volna átírni. Erre már nem volt idő. Egyébként igazad van elméletben. Én még ezzel a mentalitásommal - mármint hogy a feladathoz nem kapcsolódó hibákat javítsak - még ki is lógok a többiek közül. Ebbe és több más dologba is beleállok.
Nem tudok többet hozzáfűzni, mint amit dabadab írt.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
alapz@j
tag
válasz jattila48 #6331 üzenetére
Ezt írtam rá tegnap:
void t1(void) {
char msg[16];
strcpy(msg, "Hello!");
puts(msg);
}
void t2(void) {
char msg[16];
puts(msg);
}
int main(void) {
t1();
t2();
return EXIT_SUCCESS;
}Mivel a t1 és t2 függvényeknek ugyanolyan méretű a kezdeti stack frame-je, így a t2 hívásakor a char[16] ugyanarra a memóriaterületre esik és a puts szépen kiírja az előző függvényből ott maradt Hello!-t
-
pmonitor
aktív tag
válasz alapz@j #6339 üzenetére
Nem azért írja ki a Hellot!-t, mert ugyanolyan a kezdeti stack frame-je! Ha t2()-t így módosítod:
void t2(void) {
int err = 0;
char chrarr[256] = "Erik.";
char msg[32];
puts(chrarr);
puts(msg);
}akkor is a Hello!-t írja ki. Egyszerűen memóriaszemét lesz a t1() után. Ezért kell mindig feltölteni a tömböt allokálás után.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
jattila48
aktív tag
válasz alapz@j #6345 üzenetére
Ja, hagyhattad volna. Dabadabnak válaszolva le is írtam, hogy én is arra gondoltam, mint ő. Technikailag nagyon is tisztában vagyok vele, hogy lehet ilyen hibát elkövetni. Inkább azt nem értem, hogy (valószínűleg nem kezdő) programozók production kódban hogyan követhetnek el ilyet, és hogy maradhat benne egy code review során. Egyébként évekkel ezelőtt tettem szóvá ezt: [link] . Move szemantika, lap alja, visszatérés jobbérték referenciával. A hibát elismerték, azóta is hibásan van kint. Remélem a diákok nem veszik szentírásnak az ott leírtakat. Vagy mégis? Mert akkor már értem.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
sztanozs
veterán
válasz jattila48 #6347 üzenetére
Úgy maradhat benne, hogy ahhoz, pl hogy egy eljárásban keletkező átmeneti változót visszaadjon (mert pár év után valaki rájött, hogy az is milyen jól jöhet máshol), változtatni kell az eljárás szignatúráját, ami viszont a kód más részeiben igényel újraírást. Ezt megspórolandó az új kód inkább turkál a (memória-) szemétben. Time is money.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
jattila48
aktív tag
válasz sztanozs #6349 üzenetére
"az új kód inkább turkál a (memória-) szemétben"
Ja, aztán valakinek eszébe jut újra buildelni új fordítóval, vagy más opciókkal (optimalizálás, stack check, debug, ...), és szószerint szemétben túrkálás lesz belőle, aztán megy a fejvakarás, hogy eddig működött, most már nem, biztos a fordító szar. Láttam már ilyet. És valóban: Time is money.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest