Hirdetés
- Magisk
- Szívós, szép és kitartó az új OnePlus óra
- Azonnali navigációs kérdések órája
- Android alkalmazások - szoftver kibeszélő topik
- Poco F6 5G - Turbó Rudi
- Bluetooth hangszórót készít a HMD
- EarFun Air Pro 4+ – érdemi plusz
- Samsung Galaxy A56 - megbízható középszerűség
- OnePlus 15 - van plusz energia
- 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
-
kingabo
őstag
válasz
skylaner
#5252
üzenetére
Jaja. Nekem clipper kódot kellett portolnom igaz C#-ra. Fv első sora if akármi, az endif x ezer sorral lejjebb. Képtelenség volt átlátni, hogy mit csinál. Ha a működés fel lett volna osztva további fk-re, akkor szépen látszott volna minden lépés, hogy mit is csinál a cucc. (pl kérd le az adatokat, szűrd le, számolj velük, generálj exportokat, mentsd a változásokat)
Ráadásul, ha ügyesen bontad szét a működést és jó fv neket adsz igen nagy mértékben le lehet csökkenteni a kommentek mennyiségét. Nem kell kiírni, hogy most ezt csinálom azt csinálom, mert az fv nevéből látszik. A sokkal fontosabb, hogy miért csinálom kommentek (ami a sok komment között elveszik) pedig szem előtt lesznek, keresés nélkül is.
A C#-os region-okra egyre több helyen tekintenek rosszként. Github-on pl több helyen is írták, hogy egyáltalán ne legyen a kódban... Mellesleg amikor egy rakat kódot összefogsz egy régióba, azt akár ahogy van ki is rakhatod egy fv-be. És késöbb, ha bele kell nyúlnod könnyebben találod meg, könnyebb módosítani, sőt még a többi x helyre se kell a fixet copy-paste-elni, mert mindenhonnan fv-t hívsz.
Persze One-Man-Army esetén úgy dolgozol, ahogy jól esik, de ha másokkal kell együtt dolgozni, vagy más kódját kapod meg, amit először meg akarnál érteni, akkor (legalábbis számomra) mindenképpen hasznos, ha fv-kba szét van robbantva a kód és átlátható, mintha azt sem tudod az 1000 sorban hol is vagy éppen.
Sztem. -
Peter789
senior tag
válasz
skylaner
#4280
üzenetére
Köszi, ez volt amit kerestem...
Közben felmerült egy másik kérdés is: van elegánsabb/gyorsabb megoldás több fájl egyidejű törlésére, mint a system("rm valami*") ? Vagy ki kell listázni, szűrni és egyesével törölni? A platformfüggőség nem katasztrófa, lévén hogy ez a program kizárólag openwrt-n fog futni és a fejlesztés is ubuntun zajlik, viszont az erőforrásigényt jó lenne minimalizálni amennyire lehet...
-
0xmilan
addikt
válasz
skylaner
#4269
üzenetére
Köszi, jogos.
Megnéztem egy régebbi példát, és annak mintájára külön függvénnyel fűztem a lista elejére.
Most így néz ki a működő verzió:
...
while(!feof(fp)){
fgets(temp, 256, fp);
sscanf(temp, "%d %[^\t] %[^\t] %[^\t] %[^\t] %[^\t] %c", &szint, &tempk, &tempa, &tempb, &tempc, &tempd, &valasz);
lista=elejere(lista, szint, tempk, tempa, tempb, tempc, tempd, valasz);
}
}
...
Kerdes* elejere(Kerdes *lista, int szint, char* tempk, char* tempa, char* tempb, char* tempc, char* tempd, char valasz){
Kerdes *uj;
uj=(Kerdes*) malloc(sizeof(Kerdes));
uj->szint=szint;
uj->ker=(char*) malloc((strlen(tempk)+1)*sizeof(char));
strcpy(uj->ker,tempk);
uj->a=(char*) malloc((strlen(tempa)+1)*sizeof(char));
strcpy(uj->a,tempa);
uj->b=(char*) malloc((strlen(tempb)+1)*sizeof(char));
strcpy(uj->b,tempb);
uj->c=(char*) malloc((strlen(tempc)+1)*sizeof(char));
strcpy(uj->c,tempc);
uj->d=(char*) malloc((strlen(tempd)+1)*sizeof(char));
strcpy(uj->d,tempd);
uj->valasz=valasz;
uj->kov=lista;
return uj;
}Most fgets-szel beolvasok egy sort, aztán sscanf-fel meg tabulátoronként darabolom és aztán rakom új listaelembe.
A listának meg nem is kellett volna helyet foglalni, mert az csak egy pointer..
Még egyszer kösz a segítséget mindenkinek! -
buherton
őstag
válasz
skylaner
#4230
üzenetére
A fejlesztőt védeni kell az ilyenektől, mert ha meg van a lehetőség a bakira, akkor a fejlesztő élni fog vele, és fog ilyen hibát véteni. Ahogy lehet látni az error exceptionokon, és rengeteg memory leak-en, és nem véletlenül retteg mindenki az optimazációs szint lépéstől
, mert ilyenkor jobban összébb csúsznak a memóriában a dolgok, és igen hatékonyan eltudja rejteni a memória túl írásokat. A memcpy-nál meg tudod adni a méretet.Nálunk új függvényeket csináltak erre, amivel biztosítva van, hogy a string mindig nullával végződik, így egy rakat hiba lehetősétől mentjük meg magunkat, de ettől függetlenül a hossz miatt még mindig vannak elírások akaratlanul is. Egy ilyen memória elírásnak a megkeresési ideje lehet 5 perctől 1 hétig terjedő idő, mert nálunk az OS nem árul el sokat, arról hogy hol történt a probléma.
-
válasz
skylaner
#4230
üzenetére
"Dehát ez nem az strlen hibája."
De. Nem veletlenul talaltak ki az strnlen()-t.
"Most azért ne használjak egy már megírt fgv-t mert lehet, hogy hibás paraméterrel hívom meg?"
Igen, foleg ilyen esetekben, ahol a parameter jo esellyel nem magabol a programbol, hanem inputbol szarmazik, mivel ezzel hatalmas kaput nyitasz a buffer overflow exploitoknak.
"Tessék gondoskodni arról, hogy helyes paramétert adunk át a fgv-nek."
Hat, ha 100%-ra meg tudsz eskudni arra, hogy az strlen csak es kizarolag rendesen null-terminated stringet kap (es ha barhol, barmikor, barki megvaltoztat valamit a programban, ami miatt ez majd nem all fenn, akkor abban a pillanatban lecsereled), akkor csinald, de nekem joval egyszerubbnek tunik az strnlen() hasznalata.
-
válasz
skylaner
#4202
üzenetére
Mivel defaultban ugyis aligned az egesz, igy aztan abszolut semmit nem takaritasz meg azzal, hogy chart hasznalsz, csak egy plusz korlatot vezetsz be, ami aztan a kesobbiekben problemassa valhat (ugyanez vonatkozik az unsigned-ra is).
Es ha mar kapcsos zarojelek: igazabol erdemes mindig kirakni oket, szemleltetem.
Kiindulasi allapot:
for(i=0;i<n;i++)
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}Aztan az ember debuggol:
for(i=0;i<n;i++)
DEBUG("qweqwe");
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}Es maris kesz a katasztrofa, amihez raadasul az IDE-k boldogan asszisztalnak (true story
). -
-
Jester01
veterán
válasz
skylaner
#3972
üzenetére
A megjegyzéseket azért tettem, mert a topikot kezdők is olvassák akiknek esetleg hasznos lehet.
Amúgy mi a gond a printf("%c",c)-vel?
Működni működik, csak fölöslegesen küzd szegény gép a %c formátumstring feldolgozásával és még leírni is hosszabb
Egyébként gcc van annyira okos, hogy kicseréli putchar hívásra, tehát ezesetben futásidőben már nincs hátránya (azon túl, hogy esetleg meglepődsz, hová lett a printf hívás). -
Jester01
veterán
válasz
skylaner
#3958
üzenetére
1. A main visszatérési típusa int.
2. A string literálok típusa const char*.
3. Mivel a függvényed nem módosítja a stringet, oda is const char* ajánlott (különben az előző pont miatt nem tudod beadni a literált).
4. Karakterek kiírására putchar és társai valók.
5. Optimalizációs okokból az osztás általában kerülendő ha máshogy is meg lehet oldani.
6. Nyelveket nem keverjük (a függvényed szoveg_tordelo de a paraméter char_num), lehetőség szerint csak az angolt használjuk. -
-
Jester01
veterán
válasz
skylaner
#1165
üzenetére
A valgrindban van egy "massif" eszköz is, az nem jó?
#-----------
snapshot=64
#-----------
time=124348
mem_heap_B=8
mem_heap_extra_B=8
mem_stacks_B=1008
heap_tree=detailed
n1: 8 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n0: 8 in 1 place, below massif's threshold (01.00%) -
Jester01
veterán
válasz
skylaner
#1163
üzenetére
Hát a globális (illetve statikus) változók azok benne vannak a program fejlécében (objdump -h kimenetben data+bss). Lokális változók méreténél (ideértve a függvényargumentumokat is) nem tudom mit szeretnél tudni, esetleg a maximális verem méretet? Mivel ismereteim szerint linux alatt a verem nem csökken, ezért azt elvileg ki lehet nyomozni a futás végén. Például gdb-vel breakpoint az exit függvényre és a /proc/<pid>/maps fájlban a stack bejegyzésből.
-
Jester01
veterán
válasz
skylaner
#1161
üzenetére
Igen, a lezáró nulla csak akkor megy át, ha 14 byteot küldesz. Jelen esetben amúgy nem is kell lezárni: if (len == 13 && strncmp(msg, "download_over", 13) == 0) ....
Ja és a recv visszaadhat hibakódot (-1) vagy éppenséggel BUFF_SIZE értéket is és ezekben az esetekben a msg[len]='\0'; felettéb szerencsétlen lenne (de gondolom a hibakezelést csak innen a postból hagytad ki).
-
Gyuri16
senior tag
-
Jester01
veterán
válasz
skylaner
#1148
üzenetére
Viszont nincs benne hossz korlátozás ezért használata erősen ellenjavalt (buffer overrun). Helyette általában az fgets ajánlott, de vigyázat, az viszont eltárolja a sorvég jelet is. Jelen esetben azonban teljesen felesleges sorokat olvasni, mivel a feladat karakter-orientált.
, mert ilyenkor jobban összébb csúsznak a memóriában a dolgok, és igen hatékonyan eltudja rejteni a memória túl írásokat. A memcpy-nál meg tudod adni a méretet.
).
Egyébként gcc van annyira okos, hogy kicseréli putchar hívásra, tehát ezesetben futásidőben már nincs hátránya (azon túl, hogy esetleg meglepődsz, hová lett a printf hívás).
Ú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!
- Luck Dragon: Asszociációs játék. :)
- Gyúrósok ide!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Nintendo Switch 2
- GL.iNet Flint 2 (GL-MT6000) router
- Magisk
- Milyen házat vegyek?
- Battlefield 6
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Hobby elektronika
- További aktív témák...
- AKCIÓ! Apple Studio Display 27 5K Nanotexturált üveg monitor garanciával hibátlan működéssel
- BESZÁMÍTÁS! Sapphire B650M R7 8700F 32GB DDR5 1TB SSD RTX 3070 Ti 8GB Zalman S2 TG EVGA 850W
- Dell Latitude 7410 Intel I7-10810U Refurbished - Garancia - Akció!
- AKCIÓ! Törött Apple iMac 19.2 i5-8500 Radeon Pro 560X 4GB 16GB 256GB SSD 21.5" 4K Retina
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest