[C++] integers uit file optellen gaat fout

[Snow_King]

Hallo,

Ik heb een stukje C++ code geschreven waarmee ik een bytes log van Apache kan optellen.

Zo'n log is simpelweg een file met op elke regel het aantal bytes van een requests.

Voorbeeldje:

code:

343
446
782
6843
947
1463

Mijn probleem is nu, als er te veel regels zijn in dat bestand wordt het totaal te groot voor mijn integer "total".

Mijn code

code:

#include <iostream>
#include <fstream>
using namespace std;

int main(int argc, char* argv[]) {
    
    /* Controleren of we wel genoeg input krijgen */
    if (argc < 2) {
        cout << "Usage: " << argv[0] << " FILE" << endl << "Returns a summary of a byteslog (in MegaBytes)" << endl;
        return 0;   
    }
    
    /* Enkele variabelen declareren */
    char line[256];
    int total = 0;
    int bytes = 0;
    
    /* File openen */
    fstream byteslog(argv[1], ios::in);
    
    /* Controleren of het bestand open is */
    if (!byteslog.is_open()) {
        cout << "Error opening file" << endl;
        return 0;
    }
    
    /* Regel voor regel door bestand heenlopen en optellen bij het totaal */
    while(byteslog >> line) {
        /* Regel casten naar een int */
        bytes = atoi(line);
        
        /* Regel delen tot een MegaByte en toevoegen aan het totaal */
        total += (bytes / 1024 / 1024);
    }
 
    /* Bestand sluiten */
    byteslog.close();
    
    /* Totaal weergeven (in MB's) */
    cout << total << endl;

    return 0;
}

Ik doe al expres het volgende:

code:

total += (bytes / 1024 / 1024);

Zo wilde ik de grootte van "total" tegen gaan, maar alsnog gaat het fout.

Bij te veel rijen komt er gewoon 0 als total uit.

Nu is mijn vraag, ligt dit probleem bij het feit dat ik een té groot getal in die integer wil stoppen? Of maak ik ergens anders een fout in mijn code?

[Opi]

Gezien de groottes van de waarden in je voorbeeld kan ik me goed voorstellen dat een overgroot deel naar 0 afgerond zal worden. Is het niet mogelijk om een tweetal counters te maken; eerst tot de 1024*1024 en op het moment dat die vol is een andere counter +1 doen?

[zwippie]

Ik ken eigenlijk geen C++ maar als een gewone int te klein is kun je misschien een unsigned long int gebruiken.

Nog iets: één byte is 8 bits, dus als er 800 bytes gelogd worden en je deelt dit twee maal door 1024, dan blijft er uiteraard weinig over (oftwel nul als het een int wordt). Dit delen kun je beter pas doen bij het weergeven van het totaal.

[NMe]

Je gebruikt een signed int, en die gaan maar tot 2¹⁵-1 = 32767^*. Waarom gebruik je geen unsigned (negatieve waarden komen niet voor) long? Of een unsigned long long zelfs.

* Op de meeste systemen is dit in elk geval zo geïmplementeerd, al schijnt er geloof ik geen zekerheid voor te zijn.

[ Voor 29% gewijzigd door NMe op 19-03-2006 16:52 ]

[CyBeR]

Of gebruik een van de vele math libraries die om kunnen gaan met grote getallen. Verder zie ik dat je om de een of andere reden standaard ints gebruikt. Wat is er mis met uint128? (Meestal getypedef'ed als unsigned long long int).

edit:
Wat NME zegt dus

[ Voor 8% gewijzigd door CyBeR op 19-03-2006 16:40 ]

[Snow_King]

Ik ben een "C++ noob"

Ik ben pas een paar dagen C++ code aan het maken.

Kan dus beter doen:

code:

unsigned int total = 0;

En voordat ik ga optellen eerst kijken of ik wel iets op te tellen heb bij total?

[Soultaker]

-NMe- schreef op zondag 19 maart 2006 @ 16:37:
Je gebruikt een signed int, en die gaan maar tot 2¹⁵-1 = 32767^*. Waarom gebruik je geen unsigned (negatieve waarden komen niet voor) long? Of een unsigned long long zelfs.

* Op de meeste systemen is dit in elk geval zo geïmplementeerd, al schijnt er geloof ik geen zekerheid voor te zijn.

De int is gegarandeerd 16 bits, maar op de meest gangbare systemen 32 bits. Hoogstwaarschijnlijk kan de TS dus gewoon tot ~2 miljard tellen (2³¹-1). Neemt niet weg dat het waarschijnlijk handig is om een long long of een unsigned long long te nemen, maar dat zal hier het probleem nog niet zijn.

Mocht je buiten het bereik komen, dan is de kans heel klein dat je op 0 uitkomt; er wordt namelijk gewoon doorgeteld. Voor een signed integer kom je eerst op een negatief getal uit (als je niet direct een heel groot getal optelt). Als je op 0 uitkomt is er dus waarschijnlijk iets anders aan de hand.

Ik denk dat Opi een goed punt heeft: zitten er überhaupt waarden groter dan 1024*1024 in de invoer? Anders rond je alles naar 0 af en komt het totaal natuurlijk ook nooit boven de 0 uit.

Sowieso is dit een typisch geval van simpelweg debuggen; zet eens een breakpoint in de lus en kijk wat je invoer is en wat er met total gebeurt. Bij gebrek aan een debugger kun je per iteratie de waarde van bytes en total printen. Je ziet dan snel genoeg waar het mis gaat.

[ Voor 12% gewijzigd door Soultaker op 19-03-2006 17:03 ]

[Snow_King]

Soultaker schreef op zondag 19 maart 2006 @ 17:00:
[...]

De int is gegarandeerd 16 bits, maar op de meest gangbare systemen 32 bits. Hoogstwaarschijnlijk kan de TS dus gewoon tot ~2 miljard tellen (2³¹-1). Neemt niet weg dat het waarschijnlijk handig is om een long long of een unsigned long long te nemen, maar dat zal hier het probleem nog niet zijn.

Mocht je buiten het bereik komen, dan is de kans heel klein dat je op 0 uitkomt; er wordt namelijk gewoon doorgeteld. Voor een signed integer kom je eerst op een negatief getal uit (als je niet direct een heel groot getal optelt). Als je op 0 uitkomt is er dus waarschijnlijk iets anders aan de hand.

Ik denk dat Opi een goed punt heeft: zitten er überhaupt waarden groter dan 1024*1024 in de invoer? Anders rond je alles naar 0 af en komt het totaal natuurlijk ook nooit boven de 0 uit.

Sowieso is dit een typisch geval van simpelweg debuggen; zet eens een breakpoint in de lus en kijk wat je invoer is en wat er met total gebeurt. Bij gebrek aan een debugger kun je per iteratie de waarde van bytes en total printen. Je ziet dan snel genoeg waar het mis gaat.

Goed punt, het zijn allemaal dingen die na de deling kleiner dan 0 worden.

Het is niet voor niets een byteslog

Hier had ik uiteraard ook zelf op kunnen komen.

[MrBucket]

Soultaker schreef op zondag 19 maart 2006 @ 17:00:
Ik denk dat Opi een goed punt heeft: zitten er überhaupt waarden groter dan 1024*1024 in de invoer? Anders rond je alles naar 0 af en komt het totaal natuurlijk ook nooit boven de 0 uit.

Wat je hier evt. tegen zou kunnen doen is om twee tellers bij te houden: een voor het aantal gehele MB's, en een voor alles onder de 1 MB. Op het moment dat die laatste waarde boven de 1 MB komt, dan heb je dus een of meer MB's erbij, en dus kan je het totaal aantal MB's verhogen en het aantal bytes verlagen:

(n.b. niet getest)

C++:

unsigned int iMegsRead = 0;
unsigned int iBytesRead = 0;
unsigned int iCount;

/* ...Lees nieuwe waarde in als iCount... */

//Voeg iCount toe aan het totaal
iBytesRead += iCount;

if(iBytesRead > 1024 * 1024){
  //Boven de 1 MB, tel het aantal hele MBs op bij het totaal aantal MB's...
  int iMegsAdded = iBytesRead / (1024 * 1024);
  iMegsRead += iMegsAdded;

  //...en verminder iBytesRead met hetzelfde aantal bytes, zodat het weer onder de 1MB komt
  iBytesRead -= iMegsAdded * (1024 * 1024)
}

Dit gaat goed zolang er geen waarde wordt ingelezen groter dan MAX_UINT - 1024*1024. Er vanuitgaande dat een unsigned int 32 bits is, ben je veilig met bestanden kleiner dan 4293 MB

[bobo1on1]

Je zou ook een unsigned long double kunnen gebruiken, dit type is wel minder nauwkeurig maar je kunt er wel veel grotere getallen in opslaan.

[Snow_King]

Ik heb het opgelost met een unsigned long.

Nu werkt het probleemloos.

[MSalters]

In elk geval werkt het nu twee keer zo lang, ja.

Unsigned long double bestaat niet. long double wel, maar dat heeft andere problemen. Er is namelijk een long double ld die zo groot is dat (ld + 343) == ld. long double heeft op sommige systemen bijvoorbeeld 12 significante cijfers. Als ld > 10¹⁵ dan is 343 kleiner dan het twaalfde significante cijfer.

[igmar]

Snow_King schreef op zondag 19 maart 2006 @ 16:23:

code:

    int total = 0;
    int bytes = 0;

int is een 32 bits integer op de meeste systemen, en over het algemeen een signed versie (al hangt dat af van je compiler).

Ik zou bovenstaande vervangen in unsigned long long, of een u_int64_t. Da's 2^64-1 voor de maximale waarde. Dat zou je probleem voor een groot gedeelte op moeten lossen.

[.oisyn]

int is altijd signed. typeid(int) == typeid(signed int). Dit itt char, die idd een ongedefinieerde signedness heeft (en daarom ook ongelijk is aan zowel signed char als unsigned char)

[Janoz]

bobo1on1 schreef op zondag 19 maart 2006 @ 21:44:
Je zou ook een unsigned long double kunnen gebruiken, dit type is wel minder nauwkeurig maar je kunt er wel veel grotere getallen in opslaan.

Dat werkt niet. Omdat je veel kleine getallen optelt zullen die waarden op een gegeven moment buiten de significantie gaan vallen waardoor het totaal niet meer wordt opgehoogd.

[splrf]

Met die int64 moet het toch wel lukken. Tenzij je over de.. ehm, wat komt er na petabyte?

[WormLord]

splrf schreef op maandag 20 maart 2006 @ 23:08:
Met die int64 moet het toch wel lukken. Tenzij je over de.. ehm, wat komt er na petabyte?

offtopic:
* Exabyte