- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy S24 - nos, Exynos
- iPhone topik
- Huawei Mate X6 - keleti oldal, nyugati oldal
- Honor Magic6 Pro - kör közepén számok
- Google Pixel topik
- Samsung Galaxy Watch7 - kötelező kör
- One mobilszolgáltatások
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
Új hozzászólás Aktív témák
-
dabadab
titán
Én a magam részéről a struktúrás függvénypointeres megoldást csinálnám (csináltam).
Ami nagyobb C projekteket láttam, ott is ez köszönt vissza, kicsit úgy nézetek ki, mintha egy régi g++ kimenetét láttam volna, ami még a C++ kódból C-t generált és a függvények első paramétere tulajdonképpen a this volt. -
cog777
senior tag
Mint c++ fejleszto, lenne par kerdesem c-vel kapcsolatban. Eleg regen foglalkoztam c-vel, most kaptam par feladatot, kapasbol a c++-os mintak jutottak eszembe, de aztan felvetodott bennem, hogyan oldanam meg a feladataimat c-ben?
Egyik feladat igenyli a dependency injection-t, amikor egy kliens kod hasznalni akar valamilyen implementaciot, pl driver-t.
Ekkor c++-ban csinalok egy interface osztalyt, majd abbol orokoltetem. Az interface osztalyon keresztul at lehet adni a driverA-t es a driverB-t is. Helyzettol fuggoen.
Na most, c-ben ezt hogy lehetne megoldani?
Alap esetben csinalnek egy csomo fuggvenyt ami a driver-t elinditja, es ezek a fuggvenyek ertelemszeruen elerhetok lennenek. De ilyenkor nem tudom barmikor kicserelni a driver funkcioit a kliensben hacsak at nem irom...
Esetleg atadok egy strukturat, amiben fuggvenyre mutato pointerek vannak es azt meg a kliens inicializalasa elott feltoltom annak megfeleloen hogy vagy a driverA, vagy driverB-nek a funkcioit akarom hasznalni a kliensben?
Remelem ertheto a problemam... szoval mi lehet a "dependency injection" c-ben? -
btraven
őstag
válasz
sztanozs
#6388
üzenetére
A térkép külön adatfájlban van. A térképeket sikerült is kirajzolnom programmal, csak a rajta levő speciális helyeket nem. Mint üzenetek, teleportok, fel/lejárat stb. Pedig az is fontos lett volna.
De mindegy is mert a játék közben olyan bugos lett hogy elfogyott a türelmem és feladtam. -
Köszönöm a válaszokat, így már világos.
-
-
Elkezdtem belekontárkodni a C nyelv tanulásába és van valami, amit nem értek a bitwise complementer operatornál:
int a = 10; /* 10 = 1010 */int c = 0;c = ~(a);printf(c);Output:-11Namost, ha jól értem, a fenti operator a biteket flippeli, vagyis a 0-ból 1, az 1-ből 0 lesz, azaz a fenti 10-es decimális értékből nem -11-nek kellene lennie, hanem 5-nek. Ebből számomra az következik, hogy van itt még valami, amiről nem tudok.
Mi az, hogy jön ki a -11? Forrás
-
-
buherton
őstag
válasz
kovisoft
#6373
üzenetére
Úgy érzem, hogy ezt nem fogom megérteni soha. Évek óta nem nyúltam C kódhoz csak C++-hoz, de annak is már 2 éve. Bár ezekkel akkor sem voltam tisztában.
Ráadásul rettenetesen bosszant az, hogy több C kvízes oldalon vannak hibás feladványok. Az egyik típus hiba az volt, hogy a függvény int-t várt és rendbe ott volt az if, hogy csak 0-nál nagyobb számokkal foglalkozzon. Negálás sehol nem volt, vagyis negatív számokra nem működik jól a függvény. A másik típus hiba az, hogy a két sequence point között csak egyszer lehet az értéket módosítani. Illetve volt még olyan is, hogy singed negatív számot akart shiftelni, ami undefined.
struct player
{
char pname[20];
}pl;
char* play(struct player *temp_pl)
{
strcpy(temp_pl->pname, "kohli");
return temp_pl->pname;
}
int main()
{
strcpy(pl.pname, "dhoni");
printf("%s %s", pl.pname, play(&pl));
return 0;
}Ez is egy kvíz, ahol nincs olyan opció, hogy undefined. Undefined-nak gondolom, mert a függvény paraméter kiértékelés sorrendje nincs leírva a szabványban.
-
kovisoft
őstag
válasz
buherton
#6372
üzenetére
Az általad korábban linkelt szövegrészben is ez van:
"The result of the postfix ++ operator is the value of the operand. After the result is obtained, the value of the operand is incremented."
Nyilván a -- operátorra ugyanez igaz. Azaz teljesen egyértelmű a dolog: először kiolvassa num értékét (ezt fogja átadni a printf-nek), és csak ezután fogja csökkenteni num-ot. Ezért először 6-ot fog kiírni.
-
-
buherton
őstag
Lenne egy számomra fogós kérdés.
Az alábbi kódrészletben miért biztos mindenki, hogy a pointer majd az inkrementált címre fog mutatni az értékadáskor az alábbi kódrészletben?
*p++ = 1;Keresem az okot a miértre, de őszintén nem találom. Annyit sikerült kideríteni, hogy nem a precedencia az ok.
A C99 szabványban (alább a részletek) úgy értelmezem, hogy ténylegesen bármikor megtörténhet két sequence point között.
Ráadásul ez a leírás is csak ráerősít arra, hogy az order unspecified: [cpp reference - Order of evaluation]
Segítene valaki felhomályosítani ebben az ügyben?
-
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. -
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.
-
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.
-
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.
-
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
-
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.
-
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”
![;]](//cdn.rios.hu/dl/s/v1.gif)
.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.
-
kovisoft
őstag
-
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 -
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.
-
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.
-
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?
-
#6306
Silεncε
őstag
Ereshkigal
#6304
Silεncε
őstag
válasz
Ereshkigal
#6304
üzenetére
goto end_of_discussion;
-
#6305
pmonitor
aktív tag
Ereshkigal
#6304
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.
-
#6304
Ereshkigal
őstag
Ereshkigal
őstag
Két hete megy ez a goto, lassan elengedhetnétek.
-
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://cdn.rios.hu/dl/s/v1.gif)
Köszi!
.
Ú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!
- HP Elitebook 840 G3 laptop (15,6FHD/I5-G8/8GB/256SSD/Magyar/Win11)
- AMD Ryzen 5 5500 - GTX 1080Ti 11Gb - MSI B450 Max
- HP Zbook 15 G3 laptop (15,6FHD/I7-G6/16GB/256SSD/AMD2GB/MagyarVilágítós/Win11)
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új és régi konzolok Okosítása/Softmodoloása, és Szoftveres szintű javítása - RÉSZLETEK A LEÍRÁSBAN
- Bomba ár! HP EliteBook 830 G5 - i5-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- TAVASZI BOMBA AKCIÓK! STEAM, UBISOFT CONNECT, EA APP, XBOX EREDETI KULCSOK 100% GARANCIA
- BESZÁMÍTÁS! Logitech G923 kormány + Driving Force Shifter garanciával hibátlan működéssel
- HPE Apollo 4200 Gen9 2U rack szerver, 1x E5-2620v4, 64GB RAM, 24x3.5" 2U-ban! ÁFA-s számla, garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged