Hirdetés
- Bemutatkozott a Poco X7 és X7 Pro
- iPhone topik
- November 24-én jön a Honor 500, itt az első kép róla
- Fordulat: időben startol S26+, nézd meg, milyen lesz!
- Szakított a OnePlus és a Hasselblad
- Amazfit Helio Strap – képernyőmentesen
- Milyen hagyományos (nem okos-) telefont vegyek?
- Honor Magic6 Pro - kör közepén számok
- Apple iPhone 13 Pro Max - őnagysága
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
Ú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!
- Nyaralás topik
- Kuponkunyeráló
- A fociról könnyedén, egy baráti társaságban
- Milyen alaplapot vegyek?
- CASIO órák kedvelők topicja!
- One otthoni szolgáltatások (TV, internet, telefon)
- Soundbar, soundplate, hangprojektor
- Lexus, Toyota topik
- Milyen processzort vegyek?
- Kerékpárosok, bringások ide!
- További aktív témák...
- BESZÁMÍTÁS! Sony PlayStation 5 Slim 1TB SSD Lemezes konzol Elite kontrollerrel garanciával hibátlan
- BESZÁMÍTÁS! MSI H310M i5 9500 16GB DDR4 120GB SSD 2TB HDD RTX 2060 Super 8GB ÚJ Zalman T4 Plus 600W
- Samsung Galaxy A32 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! Acer KG241QSbiip 24 165Hz TN FHD 1ms monitor garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASRock B450M R5 3600 16GB DDR4 256GB SSD 2TB HDD RTX 2060 Super 8GB RAMPAGE Shiva 450W
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő