Discussion :

[Scheb]

Coucou o/,

voilà j'ai un problème pour réaliser archivage de ressource, enfin moi j'appelle ça archivage, c'est peut être package le mot...
enfin bref, je ne comprends pas du tout car j'ai complétement suivi un tutoriel qui est celui-ci;

http://www.sfml-dev.org/wiki/fr/tutoriels/formatdat
(le code source est exactement celui là)

je n'ai pas posté cette question sur le forum de la sfml car finalement elle n'intervient nul part dans mes tentatives. Je crée mon archive, tout va bien; j'inspecte le contenu de celle-ci et je voie bien l'en-tête, et tout le continue du ou des fichiers archivés...

Le problème survient lorsque j'essaye de le lire. Je voyais que ça ne fontionné pas alors j'ai fait un béte code pour voir le probleme et en faite j'ai ceci;

Code :

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

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
26
27
28
29
 
#include <iostream>
#include <fstream>
#include <cstdlib>
#include <string>
 
 
using namespace std;
 
int main()
{
 
	DAT archive;
 
	archive.Read("pack_test.dat");
 
	char *buffer = new char[archive.GetFileSize("image.bmp")];
           buffer = archive.GetFile("image.bmp");
 
 
	cout << buffer;
	ofstream fichier;
	fichier.open("text.txt", ios::out | ios::binary);
 
	fichier.write(buffer, sizeof(buffer));
 
            fichier.close();
    return 0;
}

et là j'obtiens 6-7 caratère lu, même pas; "BM΅" par exemple (ce qui est le debut de ce qui devait lire). La question est donc, pourquoi il s'arrete ? que se passe t'il ? une idée ? (j'ai essayé differentes combine comme rajouter un '\0' mais rien)

merci d'avance, o/

[koala01]

Salut,

J'aurais bien deux question à poser:

1- A quoi correspond DAT car, à ma connaissance, on ne trouve ce type nulle part dans les fichiers d'en-tête que ton code incut

2- Je sais qu'il y a des chances pour que pack_test.dat soit écrit au format binaire, mais, à quoi correspond ce fichier, et, surtout, quelle est sa taille réelle sur le disque

Enfin, il faut te méfier comme de la peste de toute tentative d'affichage (sur la sortie standard) d'un buffer lu à partir d'un fichier "binaire"...

Il est en effet possible de rencontrer à n'importe quel moment un octet qui n'entre pas dans la catégorie des caractères affichables ( qui représente, typiquement, une valeur comprise entre 0 et 31 inclus)

Pire encore, le premier octet à valeur nulle ( '\0') sera considéré comme... le délimiteur de fin de la chaine de caractères...

Si cout s'arrête après avoir affiché 6 ou 7 caractères, il y a donc de grandes chances pour que le 7eme ou le 8eme octet du buffer ait une valeur nulle

Enfin, sois attentif à l'utilisation que tu fais de sizeof...

Appliqué à un pointeur (sans prendre "ce qui est pointé par" le pointeur) donnera une valeur constante, correspondant au nombre de byte nécessaire pour représenter l'ensemble des adresses mémoires disponible sur le système.

Typiquement, cela correspond à 4 (parce que 4*8bits = 32 bits) sur les architectures 32 bits et à 8 (parce que 8*8bits = 64 bits) sur les architectures 64 bits tournant avec un système d'exploitation 64 bits (pour les applications compilées en 64 bits).

Cela m'amène à une troisième question...

Pourquoi ouvrir un fichier auquel tu donne l'extension "txt" qui, comme tout le monde le sait, indique, normalement qu'il s'agit d'un "fichier texte" en mode "binaire" (le mal nommé) pour y écrire des informations

[Scheb]

Oups, désolé pour ce manque d'information conséquent, j'étais trop perdu dans mes idées^^
Mais en tout cas, merci d'avoir fait l'effort de me comprendre^^

1- A quoi correspond DAT car, à ma connaissance, on ne trouve ce type nulle part dans les fichiers d'en-tête que ton code incut

Pour le DAT, oui effectivement je l'avais pas vu, j'avais renommer le nom de la classe qui se nomme au depart; "class cDAT" comme sur l'en-tête d'écrit.

2- Je sais qu'il y a des chances pour que pack_test.dat soit écrit au format binaire, mais, à quoi correspond ce fichier, et, surtout, quelle est sa taille réelle sur le disque

Ce fichier, c'est donc le fameux packtage que j'ai réalisé avant avec la même classe (et la fonction create) qui marche parfaitement. (j'y ai bien sur inclue le fichier que j'utilise après). Quand je l'ouvre en bloc-note, je remarque qu'il y a bien l'en-tête ainsi que les informations de l'image elle même. Son poinds fait quelques octets de plus que l'image inclue au depart (c'est la seule que j'inclue pour ces tests), 0.3 Ko pour être precis (ce qui doit correspondre à l'en-tête rajouter en plus).

Donc ça ne viens pas la fonction Create, j'ai testé aussi parallelement les autres fonctions; j'ai regardé les composantes de la classe une fois un read effectué;

std::string m_datfile; /// name of the DAT file
sDATHeader m_header; /// file header
std::vector<sFileEntry> m_entries; /// vector of files entries

et celle si sont conforme (on y retrouve les bonnes coordonnées, et la bonne taille du fichier)

Donc les fonctions Read et GetFileSize() marche elles aussi parfaitement.

Je suis pratiquement sûr que c'est GetFile() qui pose soucis. J'ai effectué plusieurs tests; remplacer le;

datfile.read (m_buffer, m_entries[i].size);

par un getline() et la il ne s'arrete pas et prends vraiment la ligne (même si c'est pas pratique parceque je peux pas lui dire de prendre tant de caractère...)

Pourquoi ouvrir un fichier auquel tu donne l'extension "txt" qui, comme tout le monde le sait, indique, normalement qu'il s'agit d'un "fichier texte" en mode "binaire" (le mal nommé) pour y écrire des informations

Comme tu l'as dit, il faut se mefier de l'affichage console, c'est pour ça que j'ai voulu l'ecrire dans un .txt (même avec un mode ios::binary) c'est la même chose...

Voilà, merci de te pencher sur mon cas

[Scheb]

Bonne nouvelle !!!!!!
ça marche!

Dans un dernier élan de volonté j'ai essayer plusieurs actions nottament reinstaller la derniere version de code::block et de mingw (car j'avais pris la nouvelle g++ y a quelques temps sans changer rien d'autre, peut etre que de nouvelle mise a our d'adaptation ont été realiser....enfin je sais pas moi... ça marche comme ça !)

bref sujet resolu

[3DArchi]

Code :

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

fichier.write(buffer, sizeof(buffer));

sizeof(buffer) c'est la taille d'un pointeur et non pas la taille des données que tu veux écrire.
Peut être avais-tu voulu écrire plutôt :

Code :

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

fichier.write(buffer,archive.GetFileSize("image.bmp"));

J'ai de gros doute sur ces 2 lignes :

Code :

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

1
2
char *buffer = new char[archive.GetFileSize("image.bmp")];
buffer = archive.GetFile("image.bmp");

L'opérateur '=' ne fait que changer la valeur du pointeur pas les données pointées.
Soit tu voulais copier les données depuis l'archive vers le buffer en mémoire, au quel cas, un memcpy aurait été plus approprié.
Soit tu veux juste récupérer un pointeur sur les données, au quel cas, le new est inutile.
En tout les cas, avec ces 2 lignes, tu perds l'adresse que tu as allouée et le delete a toute chance de planter.

Remarque : je préfère utiliser unsigned char quand il s'agit d'avoir un buffer d'octet plutôt que des char.

[Scheb]

Voui voui, je mettais tromper sur les sources que j'avais coller ici, mais c'est obn là, merci beaucoups^^