J'essaye d'utiliser zlib.
En faisant un programme qui est censᅵ afficher le contenu d'un fichier
compressᅵ, je me rencontre un problᅵme : les donnᅵes sont diffᅵrent selon
la taille de mon buffer.
En bon dᅵbutant, j'imagine que la zlib est parfaitement stable et que
c'est moi le bug ;-)
J'ai donc fait un programme de test pour illustrer mon problᅵme.
L'idᅵe est d'afficher la taille totale lue du fichier compressᅵ pour
chaque taille de buffer.
Je n'arrive vraiment pas ᅵ trouver oᅵ mon code cloche, je le soumet donc
aux esprits ᅵclairᅵs de ce ng.
/* ---------------- CODE --------------- */
#include <iostream>
#include <exception>
#include <zlib.h>
#include <libgen.h>
using namespace std;
string exeName;
void displayContent(char* zFilePath,unsigned buffSz)
{
//unsigned buffSz = 200;
unsigned szRead;
char buffer[ buffSz ];
gzFile gzf = gzopen(zFilePath,"rb");
if ( gzf == NULL )
throw exception() ;
unsigned szTotal = 0;
while ( ( szRead = gzread( gzf, buffer, buffSz ) > 0 ) )
{
cout << szRead << " ";
szTotal += szRead;
// for (int i=0;i<szRead;++i)
// putchar( buffer[i] ) ;
}
cout << endl;
gzclose( gzf );
if ( szRead == -1 )
throw exception();
cout << "For size " << buffSz << " - size total:" << szTotal << endl;
}
void displayUsage()
{
cout<< "Display the content of a gzipped file\n"
<< " Usage: " << exeName << " [file]\n"
<< endl;
}
int main(int argc,char** argv)
{
// Initialize
exeName = basename(argv[0]);
// If there's errors in arg, display usage
if ( argc != 2 )
{
displayUsage();
} else {
for (unsigned i=1;i<1024;i*=2)
displayContent( argv[1] ,i );
}
}
/* ------------------------------------- */
>void displayContent(char* zFilePath,unsigned buffSz)
Attention, tu indiques ici que la fonction va modifier "zFilePath".
> unsigned szRead;
Beurk. La notation hongroise est (normalement) abandonn�e depuis
longtemps, surtout en C++.
En fait, il s'agissait au d�part d'une bonne id�e, mais comprise
totalement de travers.
Plus d'infos ici : http://www.joelonsoftware.com/articles/Wrong.html
> char buffer[ buffSz ];
Ill�gal en C++, puisque buffSz n'est pas une constante connue � la
compilation. � moins que �a ait �t� rajout� dans la nouvelle norme ?
(En revanche, c'est l�gal en C. Du coup, je me demande si tu ne t'es
pas tromp� de forum.)
> while ( ( szRead = gzread( gzf, buffer, buffSz ) > 0 ) )
L'erreur dans ton code est probablement ici : tu t'es emm�l� les
pinceaux dans les parenth�ses. Du coup, szRead vaut soit 1 (en fait,
"true" converti en un entier), soit 0 (false converti en un entier).
C'est exact.
J'ai remplacᅵ :
while ( ( szRead = gzread( gzf, buffer, buffSz ) > 0 ) )
{
par :
while (true)
{
szRead = gzread( gzf, buffer, buffSz );
if ( szRead <= 0 )
break;
et ᅵa fonctionne.
<<szRead>> n'est plus ᅵ chaque fois ᅵgal 1.
Par contre, je ne comprends pas pourquoi mon code ne marchait pas.
Pourquoi mon <<szRead>> ᅵtait alimentᅵ par 1 !?
Bon. Le fichier dᅵcompressᅵ ne correspond pas.
Etant une librairie C, je vais poser la question du cᅵtᅵ du ng
fr.comp.lang.c
> On Sat, 05 Dec 2009 01:06:54 +0100, TSalm <ts...@free.fr>:
>
>> void displayContent(char* zFilePath,unsigned buffSz)
>
> Attention, tu indiques ici que la fonction va modifier "zFilePath".
>
>> unsigned szRead;
>
> Beurk. La notation hongroise est (normalement) abandonnᅵe depuis
> longtemps, surtout en C++.
> En fait, il s'agissait au dᅵpart d'une bonne idᅵe, mais comprise
> totalement de travers.
> Plus d'infos ici : http://www.joelonsoftware.com/articles/Wrong.html
>
>> char buffer[ buffSz ];
>
> Illᅵgal en C++, puisque buffSz n'est pas une constante connue ᅵ la
> compilation. ᅵ moins que ᅵa ait ᅵtᅵ rajoutᅵ dans la nouvelle norme ?
>
> (En revanche, c'est lᅵgal en C. Du coup, je me demande si tu ne t'es
> pas trompᅵ de forum.)
>
Mais le C++ ne doit pas ᅵtre 100% compatible avec le C ?
>Mais le C++ ne doit pas �tre 100% compatible avec le C ?
Non, pas sp�cialement. Il y a une certaine compatibilit� pour des
raisons historiques, c'est tout.
Oups.
Faute d'inattention sur les parenthᅵses. Ca ferait mieux l'affaire :
while ( ( szRead = gzread( gzf, buffer, buffSz ) ) > 0 )
J'ai trouvᅵ d'oᅵ vient mon problᅵme : la <<zlib>> ne gᅵre pas le format
zip :-(
Et si la zlib ne reconnait pas un format, il le lit sans dᅵcompression.
La taille que me retourne mon programme est la taille du fichier compressᅵ.