Wie kann ich die Dateigröße einlesen
-
@mady
Kannst du bitte mal posten was da steht? Ich habe nämlich nur den C99 Final Draft und da steht in Fußnote 225: "See ‘‘future library directions’’(7.26.9)."
Und das hilft einem nicht weiterIn C++ weiß ich, dass
ifstream in; in.open(fileNane, ios::binary); in.seekg(0, ios::end); // move to the end unsigned long int fileSize = std::streamoff(in.tellg()); ifs.seekg(0, ios::beg); // go back to the beginning
korrekt ist für Dateien die mit dem C-locale und ios::binary geöffnet wurden.
Hätte also auch gedacht, dass dies für C ok ist.
-
In N869 ist es Fussnote 211:
Setting the file position indicator to end-of-file, as with fseek(file, 0, SEEK_END), has undefined behavior for a binary stream (because of possible trailing null characters) or for any stream with state-dependent encoding that does not assuredly end in the initial shift state.
-
Original erstellt von entelechie:
ich habe ein bisschen rum-ge-googled und mir mal die ersten
10 - 15 seiten angeschaut; alle sagen, dass es mit seek_end moeglich
ist an das ende der datei zu springen, egal ob sie im binaeren oder
im text modus geoeffnet wurde.Es ist egal was google sagt! Es zählt _nur_ was der Standard sagt!
-
@SG1
Danke fein
-
@entelchien
unter Linux kann dir das eh egal sein, da Unices keinen Binären Dateimodus kennen, da wird alles gleich behandelt (zum Glück!)
-
Original erstellt von Shade Of Mine:
Es ist egal was google sagt! Es zählt _nur_ was der Standard sagt!rofl
also ist ja schoen und gut was da (im Standard) steht...
nur wenn sich keiner daran haelt...
(kann ja ein gutes oder positives daran halten sein)
:p
-
Original erstellt von entelechie:
**nur wenn sich keiner daran haelt...
**Achja? Es haelt sich keiner daran? Die Programmierer halten sich nicht daran, deshalb ist es auch so schwer Programme zu portieren!
Ein SEEK_END ist unsicher, es kann dir mal um die Ohren fliegen, muss aber nicht!
Das selbe ist bei einem
char* p;
*p=3;Es muss nichts passieren, aber es kann! Nur weil bei deinem Compiler dann nichts passiert, heisst es noch lange nicht, dass es bei einem anderen Compiler nicht anders sein kann.
SEEK_END haengt eben vom OS ab. Unter Windows und Unix wirst du keine Probleme haben, was aber wenn jemand mal dein Programm auf sein selbstgeschriebenes OS bringen will? Der arme Typ wird sich wundern warum nichts laeuft...
Naja, zugegeben bloedes Beispiel, aber dennoch... der Standard ist nicht zum Spass da, damit sich Leute wie du darueber lustig machen, sondern er ist sehr wichtig um die Plattformuabhaengigkeit von C zu erhalten!
-
@shade:
hae?ich hab mich nicht ueber den standard lustig gemacht.
ich halte es fuer sehr sinnvoll, dass es klare definitionen
fuer die sprache c gibt.es ist aber auch zu sagen, wenn eine funktion fseek(..) gibt,
die sich einmal so und einmal so verhalten kann, dann ist das
schwachsinnig! das makro "seek_end" suggeriert, dass man sich
zum dateiende bewegt. ich bin immer davon ausgegagen, dass
es das auch tut.
ich halte diese definition fuer sehr schwammig.
-
Original erstellt von entelechie:
...
es ist aber auch zu sagen, wenn eine funktion fseek(..) gibt,
die sich einmal so und einmal so verhalten kann, dann ist das
schwachsinnig! das makro "seek_end" suggeriert, dass man sich
zum dateiende bewegt. ich bin immer davon ausgegagen, dass
es das auch tut.
ich halte diese definition fuer sehr schwammig.So stimmt das nicht! Der Standard gibt klare Regeln vor, wie fseek() zu verwenden ist. Weicht ein Programmierer vom Standard ab, dann verlässt er sich auf systemspezifische Dinge oder eben auf undefiniertes Verhalten.
-
"The nice thing about standards is that there are so many to choose from." -- unbekannter Autor
Als da wären z.B. POSIX, worin fseek(x, SEEK_END) natürlich definiert ist.
-
naja ... mir ging's um den aktuellen ISO-C Standard ... :))
-
ich habe nie etwas anderes behauptet mady.
aber, fuer jemanden der den standard nicht so gut in
allen einzelheiten kennt (wie z.B. ich :)) ist ein
fseek( f, 0, SEEK_END ) sehr irrefuehrend.
-
Original erstellt von entelechie:
**ich habe nie etwas anderes behauptet mady.aber, fuer jemanden der den standard nicht so gut in
allen einzelheiten kennt (wie z.B. ich :)) ist ein
fseek( f, 0, SEEK_END ) sehr irrefuehrend.**Da muss ich Dir recht geben. Ich selbst hab' den Befehl längere Zeit verwendet ....
Viele meiner (älteren) C-Bücher und Nachschlagewerke vermitteln die Sprache C 'am Standard vorbei'. Da sind z.T. falsche Formulierungen oder Sachverhalte nachzulesen. Schlechte Tut's (z.B. pronix.de) tun dann noch ihr übriges.
-
Schlechte Tut's (z.B. pronix.de) tun dann noch ihr übriges.
Kannst du das mal genauer erläutern. Was ist an diesem Tutorial so schlecht. Hab es vor einiger Zeit komplett durchgearbeitet und fand es total genial gemacht von der Aufmachung und den Informationen. Und jetzt erfahre ich das Tutorial sei schlecht?
-
BOOL GetFindData(LPSTR ss, WIN32_FIND_DATA *lpwinfd) { WIN32_FIND_DATA w32ffd; HANDLE a; if (lpwinfd) memset(lpwinfd, 0, sizeof(WIN32_FIND_DATA)); if ((a = FindFirstFile(ss, &w32ffd))!=INVALID_HANDLE_VALUE) { do { if (!(w32ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)) { FindClose(a); if (lpwinfd) memcpy(lpwinfd, &w32ffd, sizeof(WIN32_FIND_DATA)); return TRUE; } } while (FindNextFile(a, &w32ffd)); FindClose(a); } return FALSE; } DWORD GetFileSize(LPSTR ss) { WIN32_FIND_DATA w32ffd; if (!GetFindData(ss, &w32ffd)) return 0; if (w32ffd.nFileSizeHigh) return 0xffffffff; return w32ffd.nFileSizeLow; }
-
int_esskar: Deine Funktion ist ja schrecklich vom Programmierstil her.
-
Original erstellt von <Edgar>:
int_esskar: Deine Funktion ist ja schrecklich vom Programmierstil her.stimmt...vorallem weil sie gar nicht zu ANSI C passt... hab mich verschaut... sorry...
-
Sind wir hier in der Uni oder warum nennst du ein Handle einfach nur "a"? Übelst.
-
war nur ein bsp, wusst nicht ihr schönheiten sucht...dachte ihr sucht lösungen
-
Wir suchen nach schönen Lösungen.