3. std::streampos vorzeichenbehaftet?

std::streampos vorzeichenbehaftet?

  • B

    Natürlich kann meine Lösung nicht mit mehr als 4GB funktionieren. Kann ich überhaupt eine größere Datei auf meinem 32bit - Windows haben?

    0

  • Klar, kannst sie nur nicht komplett im Speicher halten. Und natürlich brauchst du das passende Dateisystem (z.B. NTFS).

    0
  • B

    Okay ... sollte ich tatsächlich auf größere Dateien stoßen, würde ich dann auf WinAPI (GetFileSizeEx) umsteigen.

    0
  • C

    Warum willst du die Datei zerlegen? Damit du sie in kleinen Stücken einlesen kannst? Wozu brauchst du dann die Größe?

    0
  • N

    DocShoe schrieb:

    Klar, kannst [eine Datei grösser als 4GB] nur nicht komplett im Speicher halten.

    Davon abgesehen, dass das normalerweise nicht sinnvoll ist: Warum nicht? Prinzipbedingt oder weil aktuelle Standardbibliotheks-Implementierungen nicht damit klarkommen?

    0
  • B

    cooky451 schrieb:

    Warum willst du die Datei zerlegen? Damit du sie in kleinen Stücken einlesen kannst? Wozu brauchst du dann die Größe?

    Es handelt sich um große Logdateien, die ein Kollege prüfen muss. Wenn er die in den Editor seiner Wahl laden will, dauert das ewig lange, bis er was zu sehen kriegt. Deswegen möchte er sie in etwas handlichere Größen zerlegt haben.

    0
  • C

    Wenn's eine Textdatei ist mal ganz simpel gedacht: Immer x (z.B. 10k) Zeilen einlesen (getline) und wieder in eine Datei schreiben? Da brauchste die Größe nie abzufragen.

    0
  • B

    Das war auch mein Vorschlag. Mein (etwas sturer) Kollege befürchtete unkontrollierte Größen der Zieldateien (die Zeilen sind teilweise schon ziemlich lang), und wollte unbedingt eine Aufteilung in 10 Teildateien gleicher Größe, obwohl ich ihn darauf hingewiesen habe, dass die jeweils letzte Zeile dann unvollständig ist, bzw. die nächsten Dateien mitten in einer Zeile beginnen ...
    des Menschen Wille ist sein Himmelreich ...

    0

  • Dann limitiere halt nicht auf Zeilen-Anzahl, sondern zähl beim Zeilen Rausschreiben mit wie gross die aktuelle Ausgabe-Datei schon ist.
    Dann kann die Grösse der generierten Output-Files maximal um die grösstmögliche Zeilenlänge vom konfigurierten Wert abweichen.
    (Maximal könnte es sich pro Zeile noch um je ein Byte zusätzlich reissen, nämlich wenn Newline-Konvertierung ala \n -> \r\n gemacht wird.)

    Das wäre mMn. nicht nur ein akzeptabler Kompromiss, sondern sogar wirklich die bessere Lösung als stur eine fixe Zeilen-Anzahl in ein File zu packen.

    Und auf jeden Fall viel schlauer als stur immer 10 Files zu erzeugen. Weil's halt keinen Sinn macht 10 Files zu erstellen wenns auf 5 tun, und genau so wenig Sinn macht nur 10 Files zu erstellen wenn eigentlich 50 praktischer wären.

    Und aufs Byte genau gleich gross ist sowieso plem. Also ganz speziell wenn es nur darum geht die Files in einem Editor aufzumachen.
    Wenn da eine eigene Applikation wäre die das konsumieren soll, die nur mit gleich grossen Files klarkommt, und die - aus was für Gründen auch immer - keiner angreifen (ändern) will, dann wäre das noch irgendwie ein verständlicher Grund.

    Aber einfach nur weil dein Kollege stur ist... neh. Ich würd dem sagen er soll mir nen Schuh aufblasen.
    Oder steht der Kollege in der Hierarchie über dir, so dass er dir diesbezüglich Arbeitsanweisungen erteilen/Vorschriften machen kann?
    Dann wäre das ein Problem. Aber auch kein unlösbares. In so einem Fall kann man ja auch mal ne Ebene höher gehen. Bevor man Stunden oder gar Tage an Arbeitszeit vernichtet... die Schlippsträger hat man oft schnell auf seiner Seite wenn man argumentieren kann dass etwas nur Kosten verursacht aber genau nix bringt.

    ps:

    die Zeilen sind teilweise schon ziemlich lang

    Naja, die Zeilen werden ja wohl nicht im multi-megabyte Bereich liegen, oder?

    0
  • B

    hustbaer schrieb:

    Dann limitiere halt nicht auf Zeilen-Anzahl, sondern zähl beim Zeilen Rausschreiben mit wie gross die aktuelle Ausgabe-Datei schon ist.
    Dann kann die Grösse der generierten Output-Files maximal um die grösstmögliche Zeilenlänge vom konfigurierten Wert abweichen.

    Eine gute Idee. Allerdings gibt es ja keinen konfigurierten Wert ... er möchte einfach nur 10 Dateien haben. Er kriegt von mir sowieso jetzt schon elf, weil die Ganzzahldivision Dateilänge / 10 ja in der Regel nicht aufgeht.en.

    hustbaer schrieb:

    Und auf jeden Fall viel schlauer als stur immer 10 Files zu erzeugen. Weil's halt keinen Sinn macht 10 Files zu erstellen wenns auf 5 tun, und genau so wenig Sinn macht nur 10 Files zu erstellen wenn eigentlich 50 praktischer wären.

    Auf jeden Fall! Deshalb hatte ich ja angeboten, die gewünschte Größe, oder von mir aus auch die gewünschte Anzahl an Files, die hinten rausfallen soll, als Parameter mitgeben zu können ...

    hustbaer schrieb:

    Aber einfach nur weil dein Kollege stur ist... neh. Ich würd dem sagen er soll mir nen Schuh aufblasen.
    Oder steht der Kollege in der Hierarchie über dir, so dass er dir diesbezüglich Arbeitsanweisungen erteilen/Vorschriften machen kann?

    Hehe, ne, das ist es nicht. Aber es kostet mich ja nix, es ist ja nun kein Mehraufwand für mich, einfach 10 gleich große Files und ein 11tes mit dem Rest zu schreiben. Er ist glücklich, mir ist es egal ...

    hustbaer schrieb:

    ps:

    die Zeilen sind teilweise schon ziemlich lang

    Naja, die Zeilen werden ja wohl nicht im multi-megabyte Bereich liegen, oder?

    Ne, so schlimm ist es nicht, ich wollte damit nur sagen, dass es sich nicht um eine einfache 80stellige Datei handelt, ich würde jetzt mal aus dem Gedächtnis grob schätzen, dass die Zeilenlänge zwischen einer Handvoll Bytes und einem Kilobyte betragen kann.

    0

  • Belli schrieb:

    Aber es kostet mich ja nix, es ist ja nun kein Mehraufwand für mich, einfach 10 gleich große Files und ein 11tes mit dem Rest zu schreiben. Er ist glücklich, mir ist es egal ...

    Schön dass du es so sehen kannst, mir wäre es nicht egal.
    Aber überleg' dir mal wie viel Zeit du alleine schon damit verbracht hast

    * Mit ihm zu diskutieren
    * Hier im Forum diesen Beitrag zu schreiben
    * Dir die streampos Geschichte anzusehen
    etc.

    Ich kenne solche sturen Kollegen, ich hatte selbst ein paar. Machen nix als Ärger.

    ps:
    Wenn er irgendwelche "normalen" Anforderungen gehabt hätte (wie eben nach File-Grösse splitten), dann hätte vermutlich niemand etwas programmieren müssen, denn fertige Text-File-Splitter Tools sollte es einige geben.

    0
  • B

    Naja ... den Beitrag hier habe ich in erster Linie verfasst, weil ich mich gewundert habe, dass streampos kein vorzeichenloser Typ zu sein scheint. Es ist soweit ich weiß, auch ein gängiges Verfahren, den Dateizeiger ans Dateiende zu verschieben und mittels tellg() die Dateigröße zu ermitteln.
    Es wird ja wohl Anwendungsfälle geben, wo das Wissen um die Dateigröße wirklich Sinn macht.

    Und zu 'schön, dass Du das so sehen kannst':
    Diese Eigenschaft hab ich mir in über 20 Jahren hier - quasi als Selbstschutz - aneignen müssen. 😉

    0

  • Naja, streampos ist gar kein integraler Typ, sondern eine Klasse.
    Bzw. genauer: ein typedef auf fpos<mbstate_t> .
    fpos Objekte sind dann in int oder streamoff Werte konvertierbar.

    Und streamoff muss ein Vorzeichen haben, da es für (möglicherweise negative) Distanzen/Offsets innerhalb von Streams verwendet wird.

    Das ist also nicht weiter verwunderlich.

    Was dagegen sehr verwunderlich ist, ist dass streamoff nur 32 Bit hat. War aber anscheinend selbst bei VC6 noch so (hab grad keinen VC6 hier um es zu checken).

    0
  • D

    siehe auch http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573

    0
Anmelden zum Antworten