Hirdetés
Köszönjük a sok biztatást, támogatást! Utolsó pillanat a féláras hirdetésfeladásra, előfizetésre!
Új hozzászólás Aktív témák
-
FehérHolló
veterán
Nem tudom megnézni azóta sehol. Magamtól szerettem volna látni, mert úgy az igazi, de akkor most már inkább kérdezek.
Az eof flag akkor állítódik, amikor a beolvasott cucc után vége van a file-nak (de eof-et még nem olvasott be), vagy akkor, ha magát az eof-et olvasta be a file-ból?
A te mondandód alapján utóbbi az igaz, de én eddig az előbbit hittem. Most akkor mi a helyzet?
Remélem érted, amit kérdezni szeretnék.
[Szerkesztve] -
FehérHolló
veterán
Így már értem, hogy mit szeretnél kifejezni, köszi!
Nincs semmiféle rekurzió.
String egy saját stringosztály, aminek a megírása egy másik házi volt. Kiegészítettem néhány dologgal, ami kellett ehhez a feladathoz. Lényegében ugyanazt csinálja, mint a beépített string osztály (konverzió tekintetében is), de ennek tudom a pontos felépítését, így inkább ezt használtam fel újra.
[Szerkesztve] -
FehérHolló
veterán
Szerintem meg úgy van, hogy:
1. file megnyit
3. megnyitás ellenőriz
2. eof ellenőriz
3. olvas
4. eof ellenőriz
5. olvas
...
Az a String::restore(ifstream&) hívása. De a restore-okkal nincs gond, mert ha többet kell restore-olni egymás után, akkor nem kerül egyikbe sem hülyeség. Csak mint mondtam, a végén ráolvas mégegyszer, amikor már EOF volt.
[Szerkesztve] -
FehérHolló
veterán
Már igazából tök mindegy, mert elfogadták a házit, csak engem piszkál a dolog:
Adott ez a kódrészlet, biztos, hogy ebben van a hiba:
ifstream if2(costfile,ios::binary | ios::in);
if(if2){
while(!if2.eof()){
tmpc.restore(if2);
C.insert(C.size(),tmpc);
}
if2.close();
}
Ez eggyel többször olvas be, mint kellene. Tehát EOF után még beolvassa a semmit, és nem nagyon értem, hogy miért. Biztos tök egyszerű a válasz, csak én vagyok a buta.
a restore(ifstream&) tagfüggvény így néz ki:
void restore(ifstream& f){
String tmpstr;
f.read((char*) &costumer_id,sizeof(unsigned));
tmpstr.restore(f);
f.read((char*) &to_pay,sizeof(unsigned));
f.read((char*) &paid,sizeof(unsigned));
f.read((char*) &item_out,sizeof(unsigned));
this->set_name(tmpstr);
}
[Szerkesztve] -
FehérHolló
veterán
Erről rögtön levágta volna a gyakvezér, hogy nem én csináltam.
Két sima time()-al megoldottam a problémát.
Köszi szépen a segítséget! Ezt elrakom későbbre emésztgetni (2 órát aludtam, és most nem jön össze semmi...).
Csak eléggé rámijesztettek, amikor elkezdtek mellettem 300soros időkezelésről beszélgetni a többiek.
A union nem struktúra.
[Szerkesztve] -
FehérHolló
veterán
Itt is feltenném a kérdést.
Ennek a második bekezdésében van leírva: [link]
A kivételi és visszahozatali időt time()-al tárolnám, majd ctime()-al hasonlítanám őket.
[Szerkesztve] -
FehérHolló
veterán
Tudtommal ha nullpointerre hívod meg a delete-et vagy a delete[]-t, akkor nem csinál semmit. Rosszul gondolom ezek szerint? Órai anyagban, és netes forrásokban is mindenhol ezt írják, hogy nem csinál semmit. Sőt, a tapasztalat is ezt mutatja, amikor másolókonstruktorban felhasználom az operátor egyenlőt, és előtte törlöm, ami ott volt.
-
FehérHolló
veterán
válasz
norbiphu #102 üzenetére
Kicímzel a tömbből a '\0' berakásánál. A legnagyobb index strlen(z).
Másrészt ezzel egy nagyobb baj is van. Ha z alapból nem nullterminált, akkor nem működik rá a strlen() függvény. Ha pedig z nullterminált, akkor szükségtelen a t végére berakni egy '\0'-t.
A harmadik gond pedig a main()-en belül az A objektum inicializálásánál van. A () zárójelbe nem két ''-t (shift+1) kell rakni, hanem egy ''-t (shift+2). De ha így adod be neki a stringet, akkor zárd le '\0'-al, és nem lesz baja a konstruktornak sem. (A két első hibát kiküszöbölöd.)
Szerk: Jé, most látom, hogy két shift+1 egymás mellett ugyanúgy néz ki, mint a shift+2, ha code blokkba rakom.
[Szerkesztve] -
FehérHolló
veterán
Bocs, most látom, hogy közben szerkesztetted az előzőt.
A destruktor jó, valamit közben szúrtál el. A két legvalószínűbb dolog a te esetedben, ami heap corruptiont okozhat:
- valahol közben már kitörölted a tort tömböt, a destruktor is törölni szeretné és ez nem tetszik az oprendszernek
- zárójeles a new, delete pedig zárójel nélküli (ez az esetedben fenn áll) -
FehérHolló
veterán
Ha Visual Studioban programozik (amiben elvileg kötelező lenne BME-s létére - a világ legnagyobb baromsága), akkor emlékeim szerint fordítási hibát kap, de figyelmeztetést biztosan.
Nem ártana egy pontos hibaüzenet.
Szerk: Neked van igazad, ''elszáll a progim'' - tehát futási idejű hiba (=lefordul).
Szerk 2: Tömbös megoldás a javallott a feladatához, onnét gondolom, hogy tömb kell neki.
[Szerkesztve]
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Autós kamerák
- Gaming notebook topik
- exHWSW - Értünk mindenhez IS
- Azonnali fotós kérdések órája
- Októberben kerülnek legacy státuszba a régebbi GeForce VGA-k
- Azonnali mobilos kérdések órája
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Anglia - élmények, tapasztalatok
- TCL LCD és LED TV-k
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- Samsung Galaxy A52s 5G 128GB 6GB RAM Dual (A528) Mobiltelefon
- Ohh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 32/1TB RTX A2000 4GB /1 Millió/
- Uhh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 16/1TB RTX A2000 4GB /1 Millió/
- Call of Duty WW2 PS4 játék
- Eladó Konfig I5-10400F 32GB DDR4 256GB SSD 1TB HDD RX6600 8GB!
- Nvidia Quadro M2000/ P2000/ P4000/ RTX 4000/ RTX 5000/ RTX A2000
- BESZÁMÍTÁS! GIGABYTE B550M R5 5600 32GB DDR4 512GB SSD RTX 2070 SUPER 8GB ZALMAN I3 NEO Enermax 650W
- Fujitsu LIFEBOOK E449 i5-8250U 8GB 256GB 14" FHD 1 év garancia
- GYÖNYÖRŰ iPhone 11 Pro 256GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS2048, 96% Akksi
- GYÖNYÖRŰ iPhone 13 mini 256GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3039, 94% Akkumulátor
Állásajánlatok
Cég: FOTC
Város: Budapest