fehler bei speichern einer datei

otze

also, ich habe ein object das ich gerne speichern würde, dazu benutze ich diese funktion:

void saveMap(std::string mapName,Map& map){
    mapName+=".map";
    std::fstream file(mapName.c_str(),std::ios::out|std::ios::trunc|std::ios::binary);
    file<<map;
}

in meinem programm öffnet er korrekt die datei(sie existiert danach), und streamt dann mithilfe folgendes operators die map ein:

/*
das steht in private von map:
std::vector<Layer> layers;
std::vector<ChangeData> changePos;
std::vector<ObjectData> objects;
std::string mapName;
int backgroundColor;
*/
std::fstream& operator<<(std::fstream& stream,Map& object){
    //getting informations
    int layercount=object.layerCount();
    int changedataCount=object.changePosCount();
    int objectcount=object.objectCount();

    //writing mapName to file
    stream<<object.getName().size();
    stream<<object.getName();

    //writing color to file
    stream<<object.getBackgroundColor();

    //writing count to file
    stream<<layercount;
    stream<<changedataCount;
    stream<<objectcount;

    //writing layers to file
    for(int i=0;i<layercount;++i){
        stream<<object.getLayer(i);
    }

    //writing changedataObjects to file
    for(int i=0;i<layercount;++i){
        stream<<object.getChangeData(i);
    }

    //writing Objects to file
    for(int i=0;i<layercount;++i){
        stream<<object.getObject(1);
    }

    return stream;
}

ok, der stream schreibt ein zeichen rein und macht sich dann dran, dass programm mit einer access violation zum absturz zu bringen .
dabei ist es egal,was ich zuerst reinschreibe, nach einem zeichen ist immer schluss. Ka was da los ist, hab alles überprüft,der stream ist nachwievor in einem guten zustand,das programm aber nicht^^

achja, das zeichen welches reingeschrieben wird hat den korrekten wert(hab auf die weise alle werte überprüft),daran kanns nicht liegen

otze

snief hat keiner ne antwort?

phlox81

doch, ne antwort hab ich schon *g*.
Liegt evtl. daran, oder anwas anderes.
Aber zu erst, warum spezialisierst du den op<< auf fstream statt auf ostream ?

Ach, und

for(int i=0;i<layercount;++i){
   stream<<object.getObject(1);
}

könnte der Fehler sein, da muss i hin.

Devil

rüdiger

öhm, kenn mich damit nicht wirklich aus, da die OSs unter denen ich arbeite kein Binary kennen, aber sollte man im Binary Mode nicht die << Operatoren benutzen? Oder verwechsel ich da gerade was?

Aber wenn ich deinen Code so sehe:
Solltest du Variablen so spät wie möglich erst deklarieren [url][/url], solltest du mehr const benutzen http://www.gotw.ca/gotw/006.htm und kann es sein, dass du int benutzt, wo du lieber std::size_t oder ähnliches benutzen solltest?

otze

devil81 schrieb:

doch, ne antwort hab ich schon *g*.
Liegt evtl. daran, oder anwas anderes.
Aber zu erst, warum spezialisierst du den op<< auf fstream statt auf ostream ?

Ach, und
for(int i=0;i<layercount;++i){
   stream<<object.getObject(1);
}
könnte der Fehler sein, da muss i hin.

Devil

deshalb würd der code nich abstürzen, aber der fehler is mir nie aufgefallen, weil mein code schon beim 2. geschriebenen zeichen abgestürzt ist-.-

@kingruedi mit oder ohne binary is egal,funzt trotzdem nich, werd dann ma versuchen auf ostream zu gehen^^

so, hab nun alles auf ostream geändert, funzt trotzdem nicht, nun änder ich wieder auf fstream, da ich den op<</>> eh nur für dateien brauch

volkard

otze schrieb:

so, hab nun alles auf ostream geändert, funzt trotzdem nicht, nun änder ich wieder auf fstream, da ich den op<</>> eh nur für dateien brauch

ganz miese idee.
nimm ifstream und ofstream, wenn du dateuen erzwingen willst.
fstream provoziert den tippfehler

ifstream in(...);
...
in>>bla;

und genau dazu wurden ifstream und ofstream zu zwei klassen, damit man ihnen unterschiedlichen operatorensatz (methodensatz) geben tun kann.

volkard

kingruedi schrieb:

und kann es sein, dass du int benutzt, wo du lieber std::size_t oder ähnliches benutzen solltest?

nein. trifft erst bei mehr als 2 milliarden objekten.
drunter ist es zum debuggen manchmal sogar fein, int zu nehmen, weil man damit overflow und underflow als getrennte phänomene hat. bei size_t gips nur overflows.
man steigt irgendwann nach size_t am besten um, wenn man keinen unterschied mehr zwischen 4294967196 und -100 mehr sieht.

otze

danke für die info

btw, hab grad den fehler gefunden, der lag in der programmlogik . die hat durch nen logikfehler den layercount erhöht, ohne nen layer zu erstellen...aua

rüdiger

volkard schrieb:

kingruedi schrieb:

und kann es sein, dass du int benutzt, wo du lieber std::size_t oder ähnliches benutzen solltest?

nein. trifft erst bei mehr als 2 milliarden objekten.
drunter ist es zum debuggen manchmal sogar fein, int zu nehmen, weil man damit overflow und underflow als getrennte phänomene hat. bei size_t gips nur overflows.
man steigt irgendwann nach size_t am besten um, wenn man keinen unterschied mehr zwischen 4294967196 und -100 mehr sieht.

dann sollte man aber ein

#ifdef USE_SIGNED_SIZE_T
typedef signed long my_size_t
#else
typedef ::std::size_t my_size_t;
#endif

oder so im Code einbauen. Außerdem merk ich schon einen Unterschied, wenn ich auf einmal 0xFFFFFFFF(FFFFFFFF) in einer Variable stehen habe, die vorher auf irgend was kleineres stand und wie du selber sagst, hat man selten mit 2 milliarden Objekten zu tun.

volkard

kingruedi schrieb:

dann sollte man aber ein
#ifdef USE_SIGNED_SIZE_T
typedef signed long my_size_t
#else
typedef ::std::size_t my_size_t;
#endif
oder so im Code einbauen.

warum? laß uns mal ersthaft bleiben, und annehmen, daß wir unseren code nicht später auf ner 4-bittigen kaffemühle drehen lassen wollen. warum long statt int? am besten per template-metaprogrammierung den integralen typ suchen, der so viele bits hat, wie ein void*?

Außerdem merk ich schon einen Unterschied, wenn ich auf einmal 0xFFFFFFFF(FFFFFFFF) in einer Variable stehen habe, die vorher auf irgend was kleineres stand und wie du selber sagst, hat man selten mit 2 milliarden Objekten zu tun.

sag ich doch. du siehst ne 4294967196 und denkst -100. du hast wohl keinen debugging-vorteil mehr, daß man underflow von overflow leichter trennen kann.

nen echten bedarf für unsigned size_t gibs's nicht. wenn ich nämlich dann mein array of char. wo der spielfilm in voller länge drin liegt, und das 3G groß ist, abspeichern mag, werde ich erkennen, daß fseek nur signed dateizeiger hat. so ein mist aber auch.