ein absolut "kranker" fehler

otze

ok nochmal ganz ganz langsam extra für dich-.-

//dies ist jetzt ein erklärendes beispiel
char bla[254]
//es werden 254 bytes auf dem stack reserviert,sagen wir von der
//datenposition 16 aus,der reserviertespeicher geht also von 16-259
cout<<bla//hier wird die datenposition also 16 ausgegeben
//so irgendwo später im code nachdem eine datei geöffnet wurde
data.read(bla,254);
//hier wird der zeiger auf die position 16 und die info über die anzahl der zu
//kopierenden daten(zufälligerweise die größe des vorher reservierten speichers)übergeben
//innerhalb der funktion
result Virtualfile::read(char* &buffer,unsigned int bytes){ 
//durch die übergabe des zeigers auf den speicherbereich 16 zeigt buffer nun auch auf 16(siehe funktionen und parameter)
buffer[1]//da der buffer den wert 16 hat zeigt buffer[1] 1 bit weiter->17->innerhalb des reservierten bereichs also ok
buffer=readpointer[position+i]//zulässig solange es im reservierten bereich bleibt
//das selbe gilt für readpointer->malloc
//usw usf

.

Mis2com

Ich bezog mich auf dieses Beispiel:

result Virtualfile::read(char* &buffer,unsigned int bytes){
    if(datapointer!=NULL){
        if(position+bytes<size){
            for(unsigned int i=0;i<bytes;++i){
                buffer[i]=readpointer[position+i];
            }
            position+=bytes;
            return ok;
        }
        return out_of_range;
    }
    return stream_not_open;
}

Außerdem klang es so, als wenn ein new außerhalb der Funktion ein Speicherleck produzieren würde, aber lass mal, ich versteh ja sowieso alles falsch.

Shade Of Mine

otze schrieb:

die read methode darf garkeinen speicher allokieren, das würde zu gigantischen speicherleaks führen.

Exakt.
Beachte aber mal dein ursprüngliches Beispiel:

int main(int argc, char* argv[])
{
    int blub;//ganz doll wundern^^
    int i;
    vfile::Virtualfile file;
    file.open("3DSINFO.TXT");//datei in speicher einlesen
    char* data;
    file.read(data,file.get_size());//inhalt des speichers in variable
    for(unsigned int i=0;i<file.get_size();++i){
        cout<<data[i];//ausgabe der datei,bei long double in der blub variable gibts access violation in module bla^^
    }
    file.close();
    cin>>i;
    return 0;
}

data hat keinen Speicher...

Warum nimmt read() denn dann eigentlich den Zeiger by Reference?

wenn ne datei geöffnet wird, wird entweder sofort oder mittels open

Und genau das ist der Designfehler. Lass das open weg.

zum thema open und ausmessen...seek wird andauernd durchgeführt read auch,open dagegen fast garnicht, also wieso testen? ist uninteressant,was nu länger braucht.

seek? Ich seeke Quasi nie, denn seek ist lahm. Wozu sollte ich das tun?
Wenn ich seeken will, mappe ich den Inhalt der Datei in den RAM und operiere nur auf ihm -> ohne kopien.

andererseits haben zb modeldaten die angewohnheit, dass man da wild rumseeken muss,und da hat so ein memorystream einen echten heimvorteil

Dann mach das ganze ohne Kopien. Du willst im Prinzip nur rum springen in der Datei -> wozu also Kopien erstellen?

Ich habe noch nie mit Models gearbeitet, aber ich würde es einfach in den RAM mappen und mir nur Zeiger auf die Interessanten stellen merken - uU lieber zuerst in ein parserfreundlicheres Format kompilieren.

otze

sorry, dass ich etwas azsgetickt bin,ich versuch jetzt nochmal in ruhe alles zu klären.

also,wenn ich in einen externen buffer schreiben will hab ich ein grundsätzliches problem:ich weis nicht,ob genügend speicher bzw ob überhaupt speicher freigegeben wurde.
nun gibt es 2 möglichkeiten:
1.ich allokiere immer innerhalb der funktion speicher.
da gibt es 2 probleme:
a) der user kann nur mit pointern arbeiten,bzw müsste den von mir allokierten speicherplatz in ein normales objekt kopieren.
b)wenn der user schon im vorfeld speicher allokiert hat, geht der natürlich verloren, und auf den stack kann man halt nur durch kopieren aus dem heap sachen ablegen
2.ich allokiere nur ausserhalb der funktion speicher
und wieder 2 probleme:
a) vergisst der user speicher zu allokieren lande ich im undefinierten bereich
b) der user muss immer genügend speicher im vorfeld freigeben
3.ich allokiere nur bei bedarf
1 grundsätzliches problem:
man kann nur schlecht die menge von mit new allokiertem speicher rausbekommen, bei normalen arrays funktioniert sizeof,ich müsste also immer 2 überprüfungen bei jedem read vorgang durchführen..

ich hab mich also für punkt 2 entschieden,und überlasse dem user die ganze arbeit.
new ausserhalb der funktion wirft nur ein speicherleck auf, wenn ich mich für punkt 1 entscheiden würde.

@shade den fehler am anfang hab ich jetzt hier in diesem thread 3 mal zugegeben, wieso merkt das eigentlich keiner und reitet weiter drauf rum?

zeiger bei reference? hast eigentlich recht, ich weis nur nicht genau wiesehr sich der overhead beim erstellen und zerstören der zeiger ist...

seek brauch ich vorallem dann,wenn ich die dateien in ein handliches format bringen will(zb wenn ich von d3ds zu einem eigenen format konverte und danach wieder abspeicher),ohne das mappen in den memory dauert die ganze prozedur einfach zu lange.
ausserdem ist mein seek wirklich schnell im gegensatz zu dem der streams

aber nochmal eine grundsätzliche frage zu der mir ans herz gelegten ausnahmebehandlung
wie soll ich auf den fehler reagieren, dass der user einen unbekannten namen eingegeben hat, bzw mittem im programm eine nicht existente datei aufgerufen wird?
oder wnen malloc den nicht genug memory fehler ausgibt(was doch eigentlich sehr unwahrscheinlich sein sollte oder?)

Mis2com

gr, also das ist mir jetzt nun auch klar, das ist genau so wie beim normalen read, ich hatte mich verdammt nochmal nur auf den falschen Code bezogen...

Shade Of Mine

otze schrieb:

2.ich allokiere nur ausserhalb der funktion speicher
und wieder 2 probleme:
a) vergisst der user speicher zu allokieren lande ich im undefinierten bereich
b) der user muss immer genügend speicher im vorfeld freigeben

Dies ist die richtige Methode.
Der User übergibt ja als 2. Parameter die anzahl der Bytes die du lesen sollst
Also weiss nur er wieviel speicher er braucht und kann das optimal einteilen.
wenn der user zu dumm ist, speicher zu allokieren, ist das nicht deine schuld. detto beim freigeben des speichers.

zeiger bei reference? hast eigentlich recht, ich weis nur nicht genau wiesehr sich der overhead beim erstellen und zerstören der zeiger ist...

Kaum overhead. Aber es verwirrt. Mich hat es ziemlich verwirrt.

ausserdem ist mein seek wirklich schnell im gegensatz zu dem der streams

Logisch. Denn die sind für lesen und schreiben gemacht - deins ist nur für lesen und fürs seeken.

wie soll ich auf den fehler reagieren, dass der user einen unbekannten namen eingegeben hat, bzw mittem im programm eine nicht existente datei aufgerufen wird?

du wirfst eine Exception, zB file_not_found() oder ähnliches.
uU solltest du noch eine Funktion anbieten wo der user testen kann, ob es die datei gibt.

um solchen code zu ermöglichen.

vfile* f;
if(file_exists("foobar"))
{
  f=new vfile("foobar");
}
else
{
  f=new vfile("other");
}

ein is_open wie die C++ streams ist doof. Denn wir wollen mit exceptions die Fehlerbehandlung nicht vorort vornehmen, sondern dort, wo wir darauf reagieren können.

oder wnen malloc den nicht genug memory fehler ausgibt(was doch eigentlich sehr unwahrscheinlich sein sollte oder?)

einfach bad_alloc weiter werfen

otze

hmm shades kommentar im bezug aufs kopieren hat mich ins grübeln gebracht...
vielleicht wär es ja einfach besser, wenn ich die read funktion so umschreibe,
dass sie einen pointer eines objektes(im zweifelsfall void*)nimmt, und diesen pointer auf die aktuelle position des lesezeigers ausrichtet...das würde ja nochmal nen ziemlich großen performancegewinn bringen...

gäbe es punkte die dagegen sprächen?

//edit achja shade meine klasse kann auch schreiben,zu dem zweck sind write funktionen integriert sowie die >> operatoren überladen, welche bei jedem aufruf erstmal testen,ob noch genügend speicher vorhanden ist und im zweifelsfall reallock aufrufen(achtung hier würde es mit der veränderten read funktion probleme geben).desweiteren hab ich auch noch den [] operator überladen, der sofort den lesezeiger auf eine position ausrichten kann,ich könnte im moment also sehr wohl schreiben

Shade Of Mine

otze schrieb:

vielleicht wär es ja einfach besser, wenn ich die read funktion so umschreibe,
dass sie einen pointer eines objektes(im zweifelsfall void*)nimmt, und diesen pointer auf die aktuelle position des lesezeigers ausrichtet...das würde ja nochmal nen ziemlich großen performancegewinn bringen...

Ich habe es so gemacht, dass die Datei als eine Art string representiert wird.
Es gibt begin und end Zeiger, und was dazwischen steht, kann ich selber befuschen

//edit achja shade meine klasse kann auch schreiben,zu dem zweck sind write funktionen integriert sowie die >> operatoren überladen, welche bei jedem aufruf erstmal testen,ob noch genügend speicher vorhanden ist und im zweifelsfall reallock aufrufen

Das ist aber Arsch lahm...

(achtung hier würde es mit der veränderten read funktion probleme geben).desweiteren hab ich auch noch den [] operator überladen, der sofort den lesezeiger auf eine position ausrichten kann,ich könnte im moment also sehr wohl schreiben

Man öffnet sowieso keine Datei zum lesen UND schreiben. Also erlaube das garnicht erst, und du bist das Problem los.

otze

shade so lahm ist der test garnich wenn man bedenkt, dass mein "lesezeiger" nur den start der datei beschreibt, und seine "position" in einer int variable festgehalten wird.
positionsabfragen werden dann mit lesezeiger[position] durchgeführt.
der test is dann ne simple addition.ob das nun performant ist weis ich nicht, aber 10millionen vorgänge in 140ticks sind schnell genug denk ich mal^^

//hier der test beim schreibvorgang 
if(position+sizeofdata<=size)
{
    /*schreibvorgänge usw*/
}
else
{
    throw(out_of_range(write,datapointer,size+sizeofdata));
}

aber irgendwie nervts mich, dass ich durch mein interface keine templates benutzen darf..wie ist es eigentlich, wenn ich bei einer klasse den void* cast überlade und die klasse dann so wie sie ist der read/write(void*,int) funktion übergebe,würde der compiler dann direkt nach void casten?

Shade Of Mine

otze schrieb:

shade so lahm ist der test garnich wenn man bedenkt, dass mein "lesezeiger" nur den start der datei beschreibt, und seine "position" in einer int variable festgehalten wird.

Ich meinte das realloc.

aber irgendwie nervts mich, dass ich durch mein interface keine templates benutzen darf..

Warum gehen keine templates?

otze

gib mir ne schnellere(schönere) möglichkeit für reallock

und warum keine templates gehen?

template<class T>
virtual read(T,int);//BOOM

Shade Of Mine

otze schrieb:

gib mir ne schnellere(schönere) möglichkeit für reallock

Nicht alles an einem stück im speicher halten, zb nur in 4KB blöcken (also 1 pagesize)

und warum keine templates gehen?
virtual read(T,size);//BOOM

warum muss read virtual sein?
warum nicht op>> ?

otze

read muss virtual sein, da es 2 klassen gibt, 2 streamklassen, die dasselbe interface benutzen.
ziel war bzw ist es, die klassen austauschbar zu machen, damit die eine im notfall(zb malloc versagt) für die andre einspringen kann.
und dann gehts halt nich anders...

aber nur mal so aus neugierde: wie schaffst du es, eine datei in 4kb blöcke aufzuteilen? std::list?

und wie muss ich in den streamklassen die funktionen aufbauen, damit sie einen überladenen >>/<< operatar einer anderen klasse akzeptieren?

Shade Of Mine

otze schrieb:

read muss virtual sein, da es 2 klassen gibt, 2 streamklassen, die dasselbe interface benutzen.

schau dir diesbezüglich mal die c++ streams an

ziel war bzw ist es, die klassen austauschbar zu machen, damit die eine im notfall(zb malloc versagt) für die andre einspringen kann.
und dann gehts halt nich anders...

wenn malloc einmal fehlschlägt, ist so ziemlich alles zu spät.

aber nur mal so aus neugierde: wie schaffst du es, eine datei in 4kb blöcke aufzuteilen? std::list?

jo. das wäre ne möglichkeit. uU auch ein vector.

otze

4kb sind eine pagesize, das ist klar.
geht bei größeren datenblöcken denn die performance so stark in die Knie, dass es sich lohnt sie aufzuteilen, oder hat das andre gründe?

//edit (ich edite zuviel)
wiegroß ist eigentlich der heap bei nem rechner mit 500mb ram und ner 1gb auslagerungsdatei? in der hilfe steht nur, dass heap das ist, was nicht stack ist, und das ist sehr vage^^

Christoph

Die Größe des Heaps hängt vom Betriebssystem und der Rechner-Architektur ab.

Bei 32Bit-Systemen und Windows 9x hat das Programm grundsätzlich maximal 2GB zur Verfügung. Bei Windows NT/XP sind es erstmal auch nur 2GB, mit einem Trick bekommt man IMHO auch 3GB (eine Linkeroption).
Alle Adressen, die das Programm erhält, liegen innerhalb dieser 2GB. Also auch der Code und der Stack. Der Heap wird also niemals die vollen 2GB ausnutzen können.
Der physikalisch vorhandene RAM ist bei einem halbwegs ernstzunehmenden Betriebssystem unwichtig für die Größe des Heaps.

Wenn du unter Windows programmierst, schau dir mal memory mapped files an. Vielleicht kannst du das gebrauchen. Dabei bildet Windows eine Datei auf RAM-Speicher ab. Dank virtuellem Speicher ist das auch mit großen Dateien möglich, ohne dass der Speicherverbrauch des Programms um ein Byte steigt.

otze

cd9000 schrieb:

Die Größe des Heaps hängt vom Betriebssystem und der Rechner-Architektur ab.

Bei 32Bit-Systemen und Windows 9x hat das Programm grundsätzlich maximal 2GB zur Verfügung. Bei Windows NT/XP sind es erstmal auch nur 2GB, mit einem Trick bekommt man IMHO auch 3GB (eine Linkeroption).
Alle Adressen, die das Programm erhält, liegen innerhalb dieser 2GB. Also auch der Code und der Stack. Der Heap wird also niemals die vollen 2GB ausnutzen können.
Der physikalisch vorhandene RAM ist bei einem halbwegs ernstzunehmenden Betriebssystem unwichtig für die Größe des Heaps.

Wenn du unter Windows programmierst, schau dir mal memory mapped files an. Vielleicht kannst du das gebrauchen. Dabei bildet Windows eine Datei auf RAM-Speicher ab. Dank virtuellem Speicher ist das auch mit großen Dateien möglich, ohne dass der Speicherverbrauch des Programms um ein Byte steigt.

erstmal danke für die info,das hat mir sehr geholfen
zum thema memory mapped files...ich schreib ja dateien in den heap um vielfach schnelleren zugriff auf sie zu haben, wie ist das denn mit memory mapped files? gibts da geschwindigkeitszuwächse?

//edit is der code so in ordnung?

string Filename("datei.dat");
HANDLE Filehandle=CreateFileForMapping(*Filename,GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL|FILE_FLAG_RANDOM_ACCESS);
readpointer=CreateFileForMapping(Filehandle,NULL,PAGE_READONLY,0,0,NULL);
//mit dem pointer arbeiten
buffer[3]=readpointer[3];

Shade Of Mine

Wenn du ne Datei in den Speicher mappst, dann liegt sie im Speicher. Genau wie deine Datei nur dass das mappen schneller ist.

otze

es gibt noch eine letzte frage,dann is dieses thema für mich abgeschlossen ;9
shade, du hast ja ein paar posts vorher gesagt, dass es besser wär, den großen dateibuffer in 4kb große teile aufzuspliten.
Jetzt mal ganz abgesehen davon, wie mam das am besten implementiert,wie kann ich folgende situation regeln?

Ich hab jetzt also einen 25*4kb großen Buffer,und eine funktion will mithilfe eines pointers drauf zugreifen.
so, nun haben wir ein problem:
solange nur aus dem ersten der 25 teilbuffer gelesen wird ist alles in ordnung,
will man aber das 4097.Byte lesen(also das erste byte des 2. buffers) trifft man auf eine ziemlich harte mauer: zwischen 2 buffern können x unbesetzte Bytes liegen,vom sprung von byte 4096 zu 4097 müssen also noch x bytes übersprungen werden,und das problem ist, dies dem pointer mitzuteilen...gibt es überhaupt eine möglichkeit, das zu regeln?

also im endeffekt, soll es der funktion erlaubt sein den übermittelten void pointer umzucasten,und dann zb x=*pointer[4097] aufzurufen(das entspricht auch in etwa dem, was man "in freier wildbahn"(ergo D3DXCreateTextureFromFileInMemoryEx()) antrifft.

Shade Of Mine

Das geht dann natuerlich nicht...
Ich wuerde hier eine eigene Stringklasse empfehlen. Diese Klasse zeigt nur auf den Speicher wenn dies moeglich ist - wenn es nicht moeglich ist, muss eben doch kopiert werden. allerdings treten solche situationen ja hoffentlich nicht allzuoft auf (wenn doch, dann uU die Bloecke vergroessern).

Aber du hast doch sowieso das Problem, dass du keine echten C strings hast, da du sie ja nicht gut NULL terminieren kannst...

ein absolut &quot;kranker&quot; fehler

ein absolut "kranker" fehler