Datei dynamisch einlesen -> leider lahm
-
SeppJ schrieb:
exilcubaner schrieb:
SeppJ schrieb:
Eine gute Strategie ist, den reservierten Block jedes Mal um einen Faktor 2 zu vergrößern. Das verschwendet nicht viel Platz und benötigt im Mittel konstante Zeit (anstatt wie jetzt mit der Dateigröße linear viel Zeit) für das reservieren.
ich hör schon meine festplatte swappen
Hörst du sie auch, wenn du irgendwelche anderen Programme benutzt?
ja, kann schon mal vorkommen! besonders bei solchen, die immer die ganze datei einlesen müssen, noch dazu, wenn sie vorher nicht wissen wie groß das teil eig. ist, welches gewuppt werden soll.
also für mich ist das kind eig. schon an dem punkt in den brunnen gefallen, wo man anfängt, date(n|ien) zu verarbeiten, deren größe man nicht kennt. es dann mit iwelchen techniken zu kompensieren, wiederspricht meiner arbeitsweise!
-
Die Größenbestimmung ist kein Einlesevorgang.
Gut zu wissen. Ich bin bisher immer vom Gegenteil ausgegangen.
Dann schonmal Danke für eure Mithilfe. Wieder was dazugelernt
-
exilcubaner schrieb:
also für mich ist das kind eig. schon an dem punkt in den brunnen gefallen, wo man anfängt, date(n|ien) zu verarbeiten, deren größe man nicht kennt. es dann mit iwelchen techniken zu kompensieren, wiederspricht meiner arbeitsweise!
Man kann seinen Horizont auch künstlich einschränken.
Viele Befehle der *ix-Shells arbeiten so. Denn sonst könnten sie nicht als Filter arbeiten.
-
Pyro Phoenix schrieb:
Weil ich mich gefragt habe, ob es eine (mehr oder weniger) praktikable Lösung gibt, die Größenbestimmung und den Einleseprozess in einem Rutsch zu erledigen.
ja, eine praktikable lösung gibt es, indem du die dateigröße vorher bestimmst
(stat, fstat), fseek ist aus mehreren gründen nicht zu empfehlen.
-
DirkB schrieb:
exilcubaner schrieb:
also für mich ist das kind eig. schon an dem punkt in den brunnen gefallen, wo man anfängt, date(n|ien) zu verarbeiten, deren größe man nicht kennt. es dann mit iwelchen techniken zu kompensieren, wiederspricht meiner arbeitsweise!
Man kann seinen Horizont auch künstlich einschränken.
Viele Befehle der *ix-Shells arbeiten so. Denn sonst könnten sie nicht als Filter arbeiten.so, dann bau mir doch mal schnell einen filter, der alle groß in kleinbuchstaben wandelt. ist eig. ein einzeiler, ohne header und main gedöns. ich würde sagen, wir schauen uns dann deine lösung gemeinsam an und reden über filter
-
exilcubaner schrieb:
DirkB schrieb:
exilcubaner schrieb:
also für mich ist das kind eig. schon an dem punkt in den brunnen gefallen, wo man anfängt, date(n|ien) zu verarbeiten, deren größe man nicht kennt. es dann mit iwelchen techniken zu kompensieren, wiederspricht meiner arbeitsweise!
Man kann seinen Horizont auch künstlich einschränken.
Viele Befehle der *ix-Shells arbeiten so. Denn sonst könnten sie nicht als Filter arbeiten.so, dann bau mir doch mal schnell einen filter, der alle groß in kleinbuchstaben wandelt. ist eig. ein einzeiler, ohne header und main gedöns. ich würde sagen, wir schauen uns dann deine lösung gemeinsam an und reden über filter
cat | tr [:upper:] [:lower:]
-
na super, ich wollte eine c implementation, so dass wir mal sehen, wieviel speicher das tool verbraucht.
-
also bei mir reicht für so einen 'filter' ein char auf dem stack...
if [ ! -e a.out ] ; then echo -e "#include <stdio.h>\n#include <ctype.h>\nint main(){char c;while((c=getchar())!=EOF){putchar(tolower(c));}return 0;}" | gcc -xc - && echo "asdASDasd" | ./a.out && rm a.out; else echo "error a.out file exist"; fi
-
so ists besser
exilcubaner schrieb:
also bei mir reicht für so einen 'filter' ein char auf dem stack...
if [ ! -e a.out ] ; then echo -e "#include <stdio.h>\n#include <ctype.h>\nint main(){char c;while((c=getchar())!=EOF){if(putchar(tolower(c))==EOF)return 1;}return 0;}" | gcc -xc - && echo "asdASDasd" | ./a.out && rm a.out; else echo "error a.out file exist"; fi
-
uiuiui, 'char c' sollte eher ein 'int c' sein... tja, das kommt davon, wenn man die funktionen schon ewig hat ruhen lassen :p