- Samsung Galaxy A56 - megbízható középszerűség
- Samsung Galaxy A54 - türelemjáték
- Xiaomi Smart Band 8 - folyamatosan
- Szerkesztett és makrofotók mobillal
- Ingyen beszerezhető pár SEGA klasszikus mielőtt lekerülnek a Play Áruházból
- Motorola Moto Tag - nyomom, követ
- Magisk
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- További kavarás a Pixel 10-ek körül
- Android szakmai topik
Ú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.
-
dabadab
titán
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.
-
dabadab
titán
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
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!
- Samsung Galaxy A56 - megbízható középszerűség
- Autós topik látogatók beszélgetős, offolós topikja
- TCL LCD és LED TV-k
- Samsung Galaxy A54 - türelemjáték
- Hővezető paszták
- Luck Dragon: Asszociációs játék. :)
- PlayStation 5
- Nyaralás topik
- Kormányok / autós szimulátorok topikja
- Revolut
- További aktív témák...
- Lenovo Legion 5 Gaming. Az ár irányár, komoly érdeklődés esetén van lehetőség egyeztetésre
- Csere-Beszámítás! AMD Számítógép PC Játékra! R5 5500 / RX 5700XT / 32GB DDR4 / 256SSD+1TB HDD
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude E5570 - i5-6300U I 8GB I 256GB SSD I 15,6" FHD I HDMI I CAM I W10 I Gari!
- BESZÁMÍTÁS! Gigabyte B650M R7 7700 32GB DDR5 1TB SSD RTX 5070 12GB BE QUIET! Pure Base 500DX 650W
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged