Archief - [PROG][C++] Inlezen van txtfile

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
d

dobber_1987

Legacy Member
Functie toArt:
Code: 
void toArt(string woord){
         int lengte = woord.length();
         ifstream lettersFile;
         lettersFile.open ("letters.txt");
         const char *cp = woord.c_str();  //Zet string om naar chars
         for (int i = 0; i<lengte; i++){
             string lijn;
             lettersFile.seekg((int (*(cp+i)) - 97) * 60);
             for (int j=0; j<5; j++){
                 cout << "positie1:" << lettersFile.tellg() <<endl;
                 getline (lettersFile,lijn);
                 cout << "positie2:" << lettersFile.tellg() <<endl;
                 cout << lijn << endl;
             }
         }
         lettersFile.close();        
    }]

letters.txt (de letters zijn 5 op 11):
Code: 
    ___    
   /   |   
  / /| |   
 / ___ |   
/_/  |_|   
    ____   
   / __ )  
  / __  |  
 / /_/ /   
/_____/

Als uitvoer krijg ik dan dat mn letters er niet goed opkomen. Ook de posities vind ik zo raar. Ik krijg bv een goede A, maar dan bij de B is er het laatste lijntje niet bij en de C daar valt ook een beetje af enzovoort. De posities, daar kan ik niet aan uit.
Code: 
positie1:0 --> begint bij positie 0
positie2:51 --> vanwaar komt ditineens? Dit moet toch 12 zijn...?
    ___
positie1:51
positie2:91

positie1:91
positie2:142
  / __  |
positie1:142
positie2:182

positie1:182
positie2:233
\____/
positie1:60 -->dit klopt dus weer wel
positie2:104

positie1:104
positie2:155
 / /_/ /
positie1:155
positie2:195

positie1:195
positie2:246
    ____
positie1:246
positie2:286
d

dobber_1987

Legacy Member
mss iets met de buffer dacht ik, maar dat werkt niet...
k

killgore

Legacy Member
lettersFile.seekg((int (*(cp+i)) - 97) * 60);

:wtf:?

Doe gewoon nen readline elke keer :x.
d

dobber_1987

Legacy Member
Maar ze geven dus een char in en als die char bv 'g' is, dan wordt dat omgezet naar een int, naar 104 dus. 104 - 97 = 7. 60 is de plaats die 1 char inneemt in de letters.txt file (soort ascii art). Dus 7*60 = 420. Dan gaat de cursor naar plaats 420 en moet hij die getline(). Snap je?
Wat is dat met readline?
k

killgore

Legacy Member
srry, ik bedoelde getline.

Zal vanavond nog eens kijken als ik tijd heb, begreep u code niet onmiddellijk.
d

dobber_1987

Legacy Member
seekg(int positie) zet u cursor aan de juiste positie. Ik moet dus eerst die seekg doen en dan getline()...
d

dobber_1987

Legacy Member
Zelfs mijn leraar informatica kan mij niet helpen, want bij hem werkt mij code wel :oink:
w

wlibaers

Legacy Member
Toevallig op verschillende besturingssystemen? Windows/Mac/Linux? Want de conventies voor het einde van een lijn verschillen op die systemen. (ook de reden waarom seek in tekstbestanden een beetje riskant kan zijn)

Misschien kunnen de API functies er niet goed tegen als er dergelijke verschillen zijn.
k

killgore

Legacy Member
aha, kbegin eindelijk door te hebben wat je bedoelt :p.

lettersFile.seekg((int (*(cp+i)) - 97) * 60);

maak hier eens van:


lettersFile.seekg((int (cp)|32 - 'a') * 60,ios_base::cur);

Werkt wel alleen als er geen leestekens instaan, gebruik anders maar een uppercase functie ipv die | :p (of maak je string ineens volledig lowercase nadat je hem hebt omgezet).

fout zelf ben ik nog aan op het zoeken :).

edit: @wlibraers: getline leest tot de \n, wat enkel op mac NIET als newline wordt gebruikt (in UNIX en windows zou het \r\n of een omgekeerde moeten zijn, maar ik heb nog nooit geweten dat \n alleen NIET werkt daar :)).

edit2: tellg en seekg gebruiken zonder binary mode vind ik nogal gevaarlijk tbh, je zou je nogal eens snel kunnen misrekenen.

edit3: zou ik eens gehele app + da txt bestand mogen, het is altijd makkelijker als ik zelf kan testen ipv op 1 deeltje code te kijken ;).
w

wlibaers

Legacy Member
killgore zei:
(*(cp|32+i)) - 'a')
Klik om te vergroten...

Die bitwise or met 32 staat daar nogal raar vind ik (bitwise or op een pointer? Ik ben C gewoon, niet C++, maar ik dacht dat dat in C++ ook niet OK was). Misschien beter (en in de meer gebruikelijke arrayindex schrijfwijze):
((cp | 32) - 'a')

(je zou ook dit kunnen doen: ((i[cp] | 32) - 'a')
maar dat zou pas echt verwarrend zijn ;) )
k

killgore

Legacy Member
woops:

(*(cp+i))|32 - 'a')

:$

edit, of duidelijker:

(cp|32)-'a'

en wat jij zegt (i[cp]) kan niet zonder casten hoor :p
w

wlibaers

Legacy Member
killgore zei:
woops:
en wat jij zegt (i[cp]) kan niet zonder casten hoor :p
Klik om te vergroten...

Ah ja, weer zo'n C++ ding zeker? (het werkt wel in C, maar C++ doet daar soms moeilijker over).
k

killgore

Legacy Member
huh, zou in C toch niet mogen werken?

edit: hoewel, nvm, effe misinterpretatie, zal wel werken, in c++ ook prolly. De meeste compilers gaan daar gewoon warning op geven gezien i nen int is (wat logisch is, wie gaat er nu array-acces op int doen).
w

wlibaers

Legacy Member
gcc -Wall -pedantic geeft in elk geval geen kik. Dat compileert foutloos. i[cp] is trouwens perfect conform de C standaard, en gelijk aan cp.
k

killgore

Legacy Member
hah, net gelijk
if(a=b) conform standaard is en toch warnings geeft bij genoeg compilers ;).

dat bedoelde ik in laatste reply.
w

wlibaers

Legacy Member
Ja, inderdaad. Al zou je wel kunnen argumenteren dat een array-access op een int wel normaal is, zolang de index maar een pointer is. ;)

Sterker, in de documentatie bij de standaard kan je lezen dat het comitee voor de C98 standaard geen enkele reden zag om de symmetrie van array-subscripting af te schaffen... Allemaal fans van de IOCCC denk ik :D
k

killgore

Legacy Member
wlibaers zei:
Ja, inderdaad. Al zou je wel kunnen argumenteren dat een array-access op een int wel normaal is, zolang de index maar een pointer is. ;)
Klik om te vergroten...
In dat geval zou je moeten casten ipc, vandaar dat ik effe in de war was en de [] niet echt zag als alt voor + :), gebruik dat nu ook niet echt vaak :p.

edit: maar daarmee is die jongen zijn probleem nog niet opgelost he :).
w

wlibaers

Legacy Member
killgore zei:
In dat geval zou je moeten casten ipc, vandaar dat ik effe in de war was en de [] niet echt zag als alt voor + :), gebruik dat nu ook niet echt vaak :p.
Klik om te vergroten...

Tja, de definitie van a is nu eenmaal (*((a)+(b))), wat zich leent tot deze nogal ongebruikelijke manier van indexering.

edit: maar daarmee is die jongen zijn probleem nog niet opgelost he :).
Klik om te vergroten...

Dan moet hij maar een compileerbaar stuk code en het volledige gegevensbestand posten in plaats van fragmentjes :)
k

killgore

Legacy Member
wlibaers zei:
Tja, de definitie van a is nu eenmaal (*((a)+(b))), wat zich leent tot deze nogal ongebruikelijke manier van indexering.
Klik om te vergroten...


had het ondertussen al door hoor :).

Zo zie je maar dat je nog altijd dingen kan tegenkomen waar je eerst 2x moet bij nadenken :p.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan