Hozzászólások
-
Bejegyzés
-
sipdav wrote:Eddig többnyire perlben dolgoztam ezért kissé még sokatlan ez a pointer-tömbös játék
Ez esetben könnyebb lehet a C++ használata (kivétel- és hibakezelés nélkül):
Code:#include
#include
#include
#include#define HOSSZ 255
void fileReader ();
void fileWriter (std::vectorint main (int argc, char *argv[])
{
fileReader ();
return 0;
}void fileReader () {
std::vectorstd::ifstream file („/home/cucc/szoveg.txt”);
char sor[HOSSZ];while(!file.eof()) {
file.getline (sor,HOSSZ);
tomb.push_back (sor);
}
fileWriter (tomb);
}void fileWriter (std::vector
for (int index = 0; index < tomb.size(); ++index) std::cout << tomb[i]; }zoltan22 wrote:Code:void takarit(void){
int memoria[1000]; // ez ugyebar helyi valtozo, a veremben tarolva
for(int i=0; i<1000; i++)
memoria[i] = 0;
i = 0; // i helyet is
}Elmeletileg ha ezt meghivjuk egy „problemas” fuggveny elott (mielott a valtozokat deklaraljuk), akkor minden helyi valtozo erteke 0 lesz. Gyakorlatilag ez mukodhet?
Nem biztos, a statikus paraméterek mindig a veremben tárlódnak (pl. „void func (char buf[200])”), de rémlik valami olyasmi, az újabb gcc esetén a lokális változók is egy ELF szekcióban tárolódnak (talán .tss), ami a program indulásakor a memóriába másolódik. Ez attól szálbiztos, hogy alapból használja a kernel TLS (thread-local storage) képességét. Ez okozhat olyan jelenséget, hogy a véletlenszerű érték nem véletlen, mert fordításkor kap egy értéket ami később nem változik meg. Ha ez így van, akkor egy -ftls-model=”local-dynamic” gcc paraméter után a progi vígan dobálja a sok NaN-t. Nektek melyik gcc van fent (nekem a 4.3.0)?
zoltan22 wrote:Code:void takarit(void){
int memoria[1000]; // ez ugyebar helyi valtozo, a veremben tarolva
for(int i=0; i<1000; i++)
memoria[i] = 0;
i = 0; // i helyet is
}Elmeletileg ha ezt meghivjuk egy „problemas” fuggveny elott (mielott a valtozokat deklaraljuk), akkor minden helyi valtozo erteke 0 lesz. Gyakorlatilag ez mukodhet?
Nem biztos, a statikus paraméterek mindig a veremben tárlódnak (pl. „void func (char buf[200])”), de rémlik valami olyasmi, az újabb gcc esetén a lokális változók is egy ELF szekcióban tárolódnak (talán .tss), ami a program indulásakor a memóriába másolódik. Ez attól szálbiztos, hogy alapból használja a kernel TLS (thread-local storage) képességét. Ez okozhat olyan jelenséget, hogy a véletlenszerű érték nem véletlen, mert fordításkor kap egy értéket ami később nem változik meg. Ha ez így van, akkor egy -ftls-model=”local-dynamic” gcc paraméter után a progi vígan dobálja a sok NaN-t. Nektek melyik gcc van fent (nekem a 4.3.0)?
zoltan22 wrote:Code:a += b; << b nem kapott kezdoerteket; emiatt az erteke veletlenszeruVS
uzsolt wrote:Ezerszer lefuttatva nekem nem hibázott, bár az a értéke 0.999970 körül van.Köszönöm a segítséget, most már az arány 2:1 kettő az egy ellen. Eddig 1:1 volt, az meg nem perdöntő. ;D Még valaki, aki szerint hibás a kód? 😉
zoltan22 wrote:Code:a += b; << b nem kapott kezdoerteket; emiatt az erteke veletlenszeruVS
uzsolt wrote:Ezerszer lefuttatva nekem nem hibázott, bár az a értéke 0.999970 körül van.Köszönöm a segítséget, most már az arány 2:1 kettő az egy ellen. Eddig 1:1 volt, az meg nem perdöntő. ;D Még valaki, aki szerint hibás a kód? 😉
uzsolt wrote:Akkor ez lehetett a rendszeres NaN ill. nem NaN oka?Kétszer már megerősítettem, de itt van harmadszorra is, a tudomány mai állása szerint nem hardveres, nem lebegőpontos, nem szoftveres, nem libc, hanem rossz index az oka, aminek nem lett kezdőérték megadva. 😮 A javított verzió minden gépen akárhányszor futtatva ugyanazt az eredményt fogja adni.
Érthetően valaki elmagyarázná, a következő kódban mi a hiba? Itt is az eredmény néha NaN, néha nem. Lehet még kernelhiba (bár lehet újból forgatni egyet), esetleg gonosz LinukszVírus is.
Code:float a, b;a = 1.0;
a += b;
b = 2.0;printf („a: %f, b: %fn, a, b);
uzsolt wrote:gabaman wrote:Az hogy valahol futott máshol meg nem, ne zavarjon meg, a memória hibák általában ilyenek, lappanganak és alattomosak, csak az a biztos hogy mindig kiszámíthatatlan a hatásuk.
Na, ennek roppant módon örülök 😉 Van valami fogás, amivel ezeknek elejét lehet venni? (Nem, nem akarok assemblyben programozni 🙂 )Igen, a megoldás az ha nem programkódok, hanem szándékok és gondolatok segítségével működjön a számítógép. ;D
uzsolt wrote:Akkor ez lehetett a rendszeres NaN ill. nem NaN oka?Kétszer már megerősítettem, de itt van harmadszorra is, a tudomány mai állása szerint nem hardveres, nem lebegőpontos, nem szoftveres, nem libc, hanem rossz index az oka, aminek nem lett kezdőérték megadva. 😮 A javított verzió minden gépen akárhányszor futtatva ugyanazt az eredményt fogja adni.
Érthetően valaki elmagyarázná, a következő kódban mi a hiba? Itt is az eredmény néha NaN, néha nem. Lehet még kernelhiba (bár lehet újból forgatni egyet), esetleg gonosz LinukszVírus is.
Code:float a, b;a = 1.0;
a += b;
b = 2.0;printf („a: %f, b: %fn, a, b);
uzsolt wrote:gabaman wrote:Az hogy valahol futott máshol meg nem, ne zavarjon meg, a memória hibák általában ilyenek, lappanganak és alattomosak, csak az a biztos hogy mindig kiszámíthatatlan a hatásuk.
Na, ennek roppant módon örülök 😉 Van valami fogás, amivel ezeknek elejét lehet venni? (Nem, nem akarok assemblyben programozni 🙂 )Igen, a megoldás az ha nem programkódok, hanem szándékok és gondolatok segítségével működjön a számítógép. ;D
uzsolt wrote:vizsla wrote:Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.Erre figyeltem, mindenhol sizeof van.
Nem erről van szó. A fordítónál beállítható például az egész (szó) címre igazítás is, ami azt jelenti, hogy a memória foglalás mindig néggyel osztható címre történjen 32 biten, nyolccal osztható címre 64 biten. Ezért egy
Code:for (int i=0;i<1024;i++)
array[i] = malloc (1);valójában nem 1KB mint ahogy sokan hiszik, hanem 8KB vagy 16KB (32/64 bit) foglalását eredményezi. Természetesen -Os esetén 5KB vagy 9KB lesz a lefoglalt méret a mutatótömb nélkül.
Mivel a gcc (statikus foglalás), glibc (dinamikus foglalás) és az OS hármas osztja ki a memória címeket, ezért életszerű az, hogy nálad nem volt NaN, másik gépeken igen mindenféle ellentmondás nélkül. Az is szerepet játszhat, hogy milyen szoftverek futottak előtte, az rk statikus tömb minek a helyét kapta meg.
Az hogy valahol futott máshol meg nem, ne zavarjon meg, a memória hibák általában ilyenek, lappanganak és alattomosak, csak az a biztos hogy mindig kiszámíthatatlan a hatásuk.
Ha valakinek még mindig nem lenne világos, most már szó sincs hardveres vagy lebegőpontos hibáról, az ilyesmi minden „Hello world!” kódnál bonyolultabb forráskóddal előfordul.
uzsolt wrote:vizsla wrote:Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.Erre figyeltem, mindenhol sizeof van.
Nem erről van szó. A fordítónál beállítható például az egész (szó) címre igazítás is, ami azt jelenti, hogy a memória foglalás mindig néggyel osztható címre történjen 32 biten, nyolccal osztható címre 64 biten. Ezért egy
Code:for (int i=0;i<1024;i++)
array[i] = malloc (1);valójában nem 1KB mint ahogy sokan hiszik, hanem 8KB vagy 16KB (32/64 bit) foglalását eredményezi. Természetesen -Os esetén 5KB vagy 9KB lesz a lefoglalt méret a mutatótömb nélkül.
Mivel a gcc (statikus foglalás), glibc (dinamikus foglalás) és az OS hármas osztja ki a memória címeket, ezért életszerű az, hogy nálad nem volt NaN, másik gépeken igen mindenféle ellentmondás nélkül. Az is szerepet játszhat, hogy milyen szoftverek futottak előtte, az rk statikus tömb minek a helyét kapta meg.
Az hogy valahol futott máshol meg nem, ne zavarjon meg, a memória hibák általában ilyenek, lappanganak és alattomosak, csak az a biztos hogy mindig kiszámíthatatlan a hatásuk.
Ha valakinek még mindig nem lenne világos, most már szó sincs hardveres vagy lebegőpontos hibáról, az ilyesmi minden „Hello world!” kódnál bonyolultabb forráskóddal előfordul.
uzsolt wrote:Valóban, oda a piros hármas helyett egy sima fekete kettes kell… A nan-ok megjelenését okozhatta ez?Egyértelműen. Simán túlcsordulna egy egész (pl. int) típusú mutató, lebegőpontosnál ez nem történhet meg, ezért a sok NaN. Mivel 10.000 egymásra épülő sor van, ezért ha egy ismeretlen értékű változót minden lépésnél hozzáadsz, akkor alap esetben szinte elkerülhetetlen a túlcsordulás (NaN). De ha az eredeti kód kimeneteit vizsgálod (./csillag &>outN), akkor ha különbséget vizsgálod (diff -u out1 out2) akkor láthatod, hogy mindig más kimenetet kapsz, még ha nem is jön elő a sok NaN (nekem sokszor előjött). Azt láttam, hogy a hármas rossz, de mivel nem ismerem a pontos feladatot nem akartam semmit sem javasolni. A gcc erőteljesen optimalizál, nem mindig ott jön ki a hiba, mint ahol valójában bekövetkezik.
uzsolt wrote:(Szoktál egyébként valamikor aludni?)Akkor nem, ha „lendületben” vagyok, aludni bármikor lehet (főleg hétvégén), problémát elhárítani nem mindig. ;D
legutóbbi hsz