- Samsung Galaxy S25 - végre van kicsi!
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Android alkalmazások - szoftver kibeszélő topik
- One mobilszolgáltatások
- Xiaomi 17 - még mindig tart
- Fotók, videók mobillal
- Google Pixel topik
- Huawei Watch Fit 5 Pro - jó forma
- A Sony bemutatta eddigi legjobb és legdrágább zajszűrős fejhallgatóját
- Szívós, szép és kitartó az új OnePlus óra
-
Mobilarena
Mobilarena
Új hozzászólás Aktív témák
-
É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.Van más értelmes alternatíva erre? Szerintem nincs.
-
É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. -
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? -
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. -
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
-
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
-
-
A printf() a plname címét kapja meg, az meg nem változik. Ami változik, az a karaktertömb tartalma, de az meg csak a printf() függvénytörzsében lesz érdekes, de mire oda jut a végrehajtás, addigra már mindkét paraméter ki van értékelve.
És tényleg.
Köszi!Egyre inkább tartok a szerdai interjútól... Ha ilyeneket fognak kérdezni, akkor aligha hiszem, hogy felvesznek senior pozícióba.
-
Ú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.
-
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.
-
-
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?
-
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?
-
-
"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. -
Ú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.
-
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.
-
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
-
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.
-
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
-
Ezt nem nagyon értem. A másik fv. az első fv. megszűnt stack frame-jéből inicializálta a saját struktúráját? Az pazar!
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
-
Ezt nem nagyon értem. A másik fv. az első fv. megszűnt stack frame-jéből inicializálta a saját struktúráját? Az pazar!
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.
-
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.
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.
Isten hozott a nagyvállalatok világában!
-
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.
-
Elsőre én is ezt gondoltam, hogy nullázni kellene a buffert, de igazából csak akkor van erre szükség, ha alkalomadtán te is meg akarod hívni a free_buffer()-t. Máskülönben csak olyankor hívódik, amikor a pointer kimegy a scope-ból, és nem fog már hivatkozni rá senki.
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.
-
É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.htmlAz 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.
-
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.
-
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?
-
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?
-
Csak szólok, hogy ha most meg arról kezdesz írogatni, hogy mennyire nem nyilvánulsz meg ezentúl ebben a topikban goto témában, az is a goto témában való megnyilvánulás.
Nem nyilvánultam meg goto témában, mert semmi olyant nem írtam, hogy ami a goto használatára vonatkozik. Mint pl. ebben a post-ban sem nyilvánítok véleményt sem mellette, sem ellene.
-
Silεncε
őstag
Két hete megy ez a goto, lassan elengedhetnétek.
goto end_of_discussion;
-
pmonitor
aktív tag
Két hete megy ez a goto, lassan elengedhetnétek.
-
Ereshkigal
őstag
Két hete megy ez a goto, lassan elengedhetnétek.
-
-
Mi nem érthető azon, hogy "Elméletileg a goto-ra soha sincs szükség, és gyakorlatilag majdnem mindig egyszerűen programozhatunk nélküle is."
És mikor írta ezt a könyvet?
Egyébként a ciklust is meg lehet írni goto nélkül(bár az azért 1 kicsit bonyolultabb, de megoldható). Pl. ezt sem vették figyelembe. Azóta már sok minden változott, még ha alap könyvről is van szó.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Köszi!
.
Ú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!
- Kingston KC3000 PCIe 4.0 NVMe M.2 2TB-os, bontatlan SSD, 2 év garanciával eladó!
- Samsung 990 Pro 1TB-os PCIe 4.0 M.2 NVMe 2280 SSD, bontatlanul, 2 év garanciával eladó!
- ADATA Legend 900 Pro 2TB-os PCIe Gen4 M.2 NVMe 2280 SSD, bontatlanul, 5 év garanciával eladó!
- AMD R7 350X és RX550 VGA kártyák
- Megvigyázott, 3,5 éves, 128 Gb, iPhone 13, 81% akku
- 27% - DDR5 Notebook 16GB / 32GB / 48GB RAM
- ÚJ Lenovo IdeaPad Slim 3 - 15.3" WUXGA - Snapdragon X X1-26-100 - 24GB - 1TB - Win11 - Garancia
- 64GB DDR5 RAM Kit!
- HIBÁTLAN Apple Watch Series SE 2 Cellular Midnight-2 ÉV GARANCIA - MS5284, 100% AKKSI
- Lenovo ThinkPad T14s Gen 3 i5-1245U 14" FHD+ 16GB 1TB 1 év teljeskörű garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest