[MFC] Serialisation

Bonjour

Apres épluchage du tuto de Farscape et de la FAQ, j'ai, apres une bataille acharnée réussi à fabriquer mon archive.

En ouvrant mon archive avec le bloc note, il n'y a que des signes bizarres contrairement à celle du prog lié au tuto. bizarre ...... :arrow: est ce normal ???


Ne pouvant vérifier le contenu de mon archive comme ça, j'ai ajouté ds le menu un commande bibon qui renvoi sur une fonction (ci jointe) dans laquelle je :
- serialise mon CArray
- vide le Carray
- déserialise dans le meme CArray.

Normalement si tout se passe bien, le prog continu de fonctionner. ce qui est le cas :P :D

j'ai alors déplacé la "deserialisation" dans CAngelView::OnInitialUpdate()
et là BOUM !!!!!!!!!

A la fin de l'iinitialupdate, il retouve bien le meme nombre d'élément contenu ds l'archive mais une simple boucle pour vérifier le contenu à la fin de l'initialisation fait tout exploser !!! (la boucle fonctionnait tres bien avant dans la fct)

une petite :idea: du problème :?:
:merci: d'avance

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

void CAngelView::OnChargerSerialiser() { CAngelApp *pTheApp=static_cast<CAngelApp *>(AfxGetApp());   // archivage. CFile File; if(File.Open("MyArchive.zac", File::modeCreate|CFile::modeWrite )) { CArchive ar( &File, CArchive::store); pTheApp->mesabsences.Serialize(ar); } // on vide   pTheApp->mespunitions.RemoveAll();   //Lecture de l'archive.   CFile File; if(File.Open("MyArchive.zac", CFile::modeRead )) { CArchive ar( &File, CArchive::load); pTheApp->mesabsences.Serialize(ar); } }

---

erreur de frappe suite à mes nombreux tests

dans la fct il faut lire

Code:

---

1 2 3

// on vide   pTheApp->mesabsences.RemoveAll();

---

[/quote]

salut,
pour les signes bizarres c''est normal ,une serialisation ne produit pas un fichier ascii lisible.
la serialisation sauvegarde aussi des informations liées a la signature des classes.
les tailles des zones etc...
donc il ne faut pas faire notepad dessus...
pour ton probleme ça plante ou exactement ?
le code montré me semble correcte .
:D

Salut Farscape

avec la fct ci-dessus tout marche ... enfin presque

si je fais des boucles de MessageBox avec .GetStrDump avant, au milieu et apres c'est bon. Je peux réutiliser mes données dans le reste du prog. Mais quand je ferme le prog il me genere une erreur sur "Atlsimpstr.h" !!!!!!!!!!!!

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

void Release() throw() { ATLASSERT( nRefs != 0 );   if( _InterlockedDecrement( &nRefs ) <= 0 ) { pStringMgr->Free( this ); //<<--------erreur ici à l'arret---------- } } void Unlock() throw() { ATLASSERT( IsLocked() );   if(IsLocked()) { nRefs++; // Locked buffers can't be shared, so no interlocked operation necessary if( nRefs == 0 ) { nRefs = 1;

---

Le but étant que le prog recharge l'archive tout seul au démarrage, j'ai déplacé la partie chargement de l'archive dans CAngelView::OnInitialUpdate

Code:

---

1 2 3 4 5 6 7

CAngelApp *pTheApp=static_cast<CAngelApp *>(AfxGetApp()); CFile File; if(File.Open("MyArchive.zac", CFile::modeRead )) { CArchive ar( &File, CArchive::load); pTheApp->mesabsences.Serialize(ar); }

---

si juste après l'initialisation, je verifie le contenu de "mesabsences"
:arrow: il trouve le bon nombre d'article
:arrow: GROS plantage :pan: au premier MessageBox avec .GetStrDump

:?: ce que je ne comprends pas, c'est qu'il y a quelque chose dans l'archive car elle est pas vide, mais c'est pas le bon truc apparemment.
il genere une erreur dans "memcpy.asm"

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

std ;N - set direction flag rep movsd ;N - move all of our dwords cld ;N - clear direction flag   jmp dword ptr TrailDownVec[edx*4] ;N - process trailing bytes   align @WordSize LeadDown2: mov al,[esi+3] ;U - load first byte <<----------- erreur ici and edx,ecx ;V - trailing byte count   mov [edi+3],al ;U - write out first byte mov al,[esi+2] ;V - get second byte from source   shr ecx,2 ;U - shift down to dword count mov [edi+2],al ;V - write second byte to destination

---

:help:

tu dois avoir quelque chose de pas clair dans ta serialisation.
en gros ça sent le debordement mémoire .
pour l'erreur sur le memcpy.asm il faudrait remonter la pile des appels pour voir a quel partie de ton code ça correspond .
:D

Citation:

---

Envoyé par farscape

il faudrait remonter la pile des appels pour voir a quel partie de ton code ça correspond .
:D

---

:?: Késako cette bète là :?:

voir page 90 de mon tuto sur le debuggage et plus exactement page 91
:D

Merci pour le tuyau.... :bravo:

j'avais sauté le paragraphe car je comprenais pas grand chose au code dans les fenetres.

le couteau sous la gorge :sm: , je m'y replonge car manifestement c'est un truc à savoir faire.

Bonne nuit.

Bonjour,

Le debuggeur et moi, on est devenu grand copain !!! enfin presque ...

http://christ99.free.fr/pile.jpg

2ème ligne (en partant du haut) erreur dans atlsimpstr.h pas mon prog !

Code:

---

1 2 3 4

~CSimpleStringT() throw() { CStringData* pData = GetData(); pData->Release(); <<-----ici-

---

3eme ligne erreur dans cstringt.h pas mon prog ! encore !!!

Code:

---

1 2	// Destructor ~CStringT() throw() <<------ici-

---

4eme ligne erreur dans eleve.h enfin mon prog :idea:

Code:

---

1 2 3

CEleve(){Clear();} //----------------------------- ~CEleve(){} <<----ici-

---

Ma Conclusion :
:arrow: l'erreur est générée suite de l'appui sur la touche exit du prog et non dans la boucle comme je pensais.
:arrow: il ne semble pas bien digérer la destruction du CArray de Celeve

Ce que je ne comprends pas :
:arrow: la destruction de ce CArray ne posait pas de probleme jusqu'à présent.
:arrow: En quoi la sérialisation/desérialisation d'un CArray de Cabsence (donc d'une classe que n'a rien à voir) empeche la destruction ?
j'ai essayé pour voir de sérialiser/desérialiser un CArray de Cclasse à la place. meme plantage, mais pile legerement différente il bloque au destructeur de Cclasse.

c'est vraiment l'acte de désérialiser qui fait le plantage final.

une :idea: ou des :idea: :idea: :idea: :idea: :idea: pour que je reprenne le :D
:merci:

salut,
ça c'est c'est une belle pile d'appels :bravo:
bien c'est donc sur la destruction de ton CArray<CEleve> qu'il y a un probleme.
apparemment ça touche a la classe CString .
tu pertubes la memoire dans un de tes traitements.

il faudrait voir dans un premier temps la definition/implementation de la classe CEleve.
:D

Salut Farscape

pour la classe, je l'ai copié collé de celle proposée dans la FAQ en la modifiant selon mes besoins.

une question bête mais c'est peut etre ça le problème car apres relecture papier et comparaison, je vois que ca.

:idea: ca pose un problème si dans la classe on a par exemple 15 variables (3 CString, 1 bool et 11 int) et que dans la partie void Serialize(CArchive& ar) on n'est pas interressé par tout garder (le 11eme int se calculant à partir des 10 autres int) et que l'on en sérialise donc que 14 ????

Est ce que ca lui fait perdre son latin ?

la serialisation doit etre symetrique
ce qui est archivé dans un ordre doit etre lu dans le meme ordre
si c'est pas le cas tu t'exposes a des debordements memoires...
:D

Elle est symétrique pour toutes mes classes dans le sens où c'est dans le meme ordre mais toutes les variables de la classe ne sont pas serialisées pour Celeve.

Si on peut serialiser qu'une partie de la classe, alors c'est pas ça l'erreur.

Ca ne pose pas de probleme d'avoir saposi à la fin ??

Code:

---

1 2 3 4 5 6 7 8 9 10

void Serialize(CArchive& ar) { if(ar.IsStoring()) ar << sonnom << sonprenom << saclasse << songrptp << sonoubli << sonretard << soncgum << saremneg << samap << sonclasseursalle << sonoral << sonexo; else ar >> sonnom >> sonprenom >> saclasse >>songrptp >> sonoubli >> sonretard >> soncgum >> saremneg >> samap >> sonclasseursalle >> sonoral >> sonexo;   saposi.Serialize(ar); //CArray de int }

---

ce que tu me montre est correcte.
la derniere instruction gere le sens archivage/lecture.

Citation:

---

Si on peut serialiser qu'une partie de la classe, alors c'est pas ça l'erreur.

---

oui mais ou ça ?
si il y a erreur ce n'est pas dans cette portion de code.
:D

j'ai pas l'impression que tu as compris ma question. Je reformule simplement avec un exemple bidon.

Dans une class Cbibon j'ai 3 CString (bidon1, 2, 3)
ai je le droit de déclarer dans ma classe la fct comme ça ?

Code:

---

1 2 3 4 5 6 7

void Serialize(CArchive& ar) { if(ar.IsStoring()) ar << bidon1 << bidon2 ; //pas de bidon3 <<< ------------- else ar >> bidon1 >> bidon2 ; //pas de bidon3 <<< -------------

---

------------------------------------------------------------------------------------------------------------------

Citation:

---

la derniere instruction gere le sens archivage/lecture.

---

quelle est la DERNIERE instruction pour toi
:arrow: 1 saposi.Serialize(ar); //CArray de int
OU
:arrow: 2 ar >> sonnom >> sonprenom >> ...........

:?: Si c'est 1 et que ça ne gère que l'archivage/lecture quand est ce que c'est archivé/écrit ??????
:idea: Dans ce cas, il tente de lire un truc qu'il n'a pas écrit.


Bonne nuit les petits .

salut,
la derniere instruction c'est :

Code:

---

1 2	saposi.Serialize(ar);

---

et serialize fonctionne en lecture et ecriture ,c'est l'archive ar qui gere son mode de fonctionnement .
tu as le droit d'enregistrer 2 cstring sur 3 et de relire 2 CString sur 3.
mais ton probleme initial c'est sur la destruction d'un objet conteneur CArray
en rapport avec la classe CEleve.
la portion de code montrée correspond au conteneur et a la classe CEleve ?
:D

Salut Farscape

Merci pour la précision.
j'ai essayé de réintroduire mes classes une par une dans un autre programme bidon. Aucune de mes classes ne se déserialise correctement en fait.

Je cherche le probleme et je te tiens au courant quand j'ai la soluce.