Discussion :

[vdumont]

Bonjour, j'essaie d'écrire une fonction qui me permet d'écrire un objet dans un fichier binaire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
template <class T>
void Util::Ecrire(const std::string& filepath, const T& objet) 
{
    std::ofstream myfile(filepath.c_str(), std::ios::binary);
    if (!myfile) {
        std::cerr << "Erreur d'écriture." << std::endl;
        return;
    }
    myfile.write( reinterpret_cast<const char *>(objet), sizeof(T));
    myfile.close();
}

Et je l'appelle en faisait par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Util::Ecrire("banane.cfg", m_glCanvas);

Mais alors voilà ca ne plante pas cependant ca m'écrit seulement 2 petits caractères dans mon fichier (ce qui ne fait pas vraiment de sens puisque mon objet est quand même volumineux)

Est-ce qu'il faut quelque chose de spécial à mon constructeur de copie car la j'ai seulement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
GL_MAILLAGE(const GL_MAILLAGE &mesh);

[Jean-Marc.Bourguet]

Si tu prenais l'adresse de l'objet, ca irait vraissemblablement plus dans le sens que tu desires.

Quant a savoir si faire un tel dump de la memoire est quelque chose a faire, mon point de vue c'est que c'est non. Ca pose un tas de problemes de portabilite, parfois meme simplement en changeant les flags. Ceci bien sur en considerant que tu n'as pas de pointeur, de references ou des membres qui en ont dans ta classe parce qu'alors les conditions dans lesquelles ca marche sont encore plus restreinte.

La bonne methode, c'est de se definir explicitement un format et explicitement des fonctions qui le sauve et le charge. C'est plus long, mais ca marche de maniere beaucoup plus sure.

[vdumont]

Bonjour, merci pour la réponse.

Désolé j'ai du mal à saisir ce que tu essaies de me faire comprendre

Si tu prenais l'adresse de l'objet

Ou ca?


et qu'entends tu par "dump de la mémoire" ?


Écrire des objets en binaire c'est mal ?

En fait ce que je veux est sauvegarder mon objet en fichier exemple config.cfg et plus tard l'utilisateur peut ouvrir cet objet et je prend les configurations (couleurs tailles etc) de cet objet et je les affecte à l'objet courant.

[Matthieu Brucher]

Oui, c'est très mal
Regarde du côté de la serialization et serialize de boost.

[Laurent Gomila]

Ou ca?

myfile.write( reinterpret_cast<const char *>(&objet), sizeof(T));

et qu'entends tu par "dump de la mémoire" ?

Simplement ce que tu fais là, c'est-à-dire écrire brutement le contenu de la mémoire dans un fichier.

Écrire des objets en binaire c'est mal ?

De cette façon, et dans un certain contexte, oui. Imagine comme Jean-Marc te le disait, que ton objet m_glCanvas ait en donnée membre un pointeur : son adresse sera inscrite dans le fichier, ce qui n'est pas d'une grande utilité.

[vdumont]

Je vois, il est d'autant plus mal que les fichiers binaires ne sont pas identiques sous Unix et sous Windows si je ne me trompe pas ?

Je crois que je vais garder ma méthode avec fichier texte, même si elle est un peu moins propre et plus complexe.

[Laurent Gomila]

Toujours comme l'a dit Jean-Marc, tu peux tout à fait mettre en place un mécanisme de chargement / sauvegarde de tes objets, qui soit indépendant de la méthode utilisée. Chaque objet saura se lire / écrire dans un fichier, que ce soit en binaire ou sous forme textuelle importe peu au final.

Concernant le mode texte, c'est la meilleure solution car compréhensible par l'homme, et surtout portable. Ensuite, si tu as des contraintes de cryptage ou de taille des fichiers, là c'est une autre histoire.

[Jean-Marc.Bourguet]

Je vois, il est d'autant plus mal que les fichiers binaires ne sont pas identiques sous Unix et sous Windows si je ne me trompe pas ?

Les différences ne sont pas particulièrement une question d'OS mais plutôt d'architecture. Par exemple en mode 32 ou 64 bits ca risque fort de ne pas être pareil.

Je crois que je vais garder ma méthode avec fichier texte, même si elle est un peu moins propre et plus complexe.

Quelque chose qui a un format défini est a priori plus propre que quelque chose dont le format dépend de facteurs non maîtrisé.