[C++/WIN32] COMPRESSEUR/DECOMPRESSEUR LZW
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
16 déc. 2006 à 00:29
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 13 mai 2007 à 01:41
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 13 mai 2007 à 01:41
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40739-c-win32-compresseur-decompresseur-lzw
https://codes-sources.commentcamarche.net/source/40739-c-win32-compresseur-decompresseur-lzw
13 mai 2007 à 01:41
Si tu suis bien ce tuto d'installation de Visula C++ Express 2005, devrait ensuite compiler.
12 mai 2007 à 12:33
decompression.
Mais je voudrais que tu m'expliques comment faire la compiltion parceque quand je compile ton application avec VisualC++2005 express Edition il me donne cette erreur: fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
Je t'envoie egalement le file BuildLog.htm
J'attends ta reponse.
Merci
11 mai 2007 à 23:43
sinon il faut créer un makefile ou utiliser un autre compilateur c++ et gérer les différences non windows. Mais moi je n'utilise que visual, donc je ne peut pas t'aider.
8 mai 2007 à 18:32
Merci d'avance
22 déc. 2006 à 21:25
Encore une entrée dans mon panthéon des mystères...
(qui commence à être sacrément lourd !)
A plus.
22 déc. 2006 à 18:42
22 déc. 2006 à 14:48
22 déc. 2006 à 08:59
La police par défaut est Tahoma (8)
22 déc. 2006 à 01:14
Pour info, je suis sous XP pro avec aucunes polices spéciales ni rien de particulier, sauf l'habillage général en vieux windows et pas de thème XP.
A plus...
21 déc. 2006 à 08:42
voilà ce que ça donnerait avec manifest,
http://img86.imageshack.us/my.php?image=compresslzwru6.jpg
Yann ce n'est pas la solution à ton pb
Magicalement votre
[http://img86.imageshack.us/my.php?image=compresslzwru6.jpg [img=http://img86.imageshack.us/img86/9636/compresslzwru6.th.jpg]]
(différents essais d'intégration de l'image)
20 déc. 2006 à 23:27
http://img296.imageshack.us/img296/3196/1wk5.png
Manifestement c'est pas un problème de manifest
18 déc. 2006 à 18:53
Pour les stream petit exemple :
hChaine += octet; // + de 10 lignes de C avec API
entree >> chaineDeBits; // j'imagine même pas avec API
A plus...
18 déc. 2006 à 14:45
en fait l'exe n'integre pas de manifest, donc
rien à voir une fois qu'on lance l'exe...
et sur mon poste (XP SP2 FR, les images dépassent mm de leur cadre et vont gagner sur les boutons...)
enfin, drole d'idée que l'usage des stream ici; je respecte ce choix même si je ne le ferai pas mien
Magicalement Bonne Prog
Nono.
16 déc. 2006 à 16:24
Et qui te dis que je n'étendrais pas la classe HashTable plus tard ou dans un autre algo, alors il faudra remonter d'un niveau.
Mais j'ai bien compris ta remarques, pour l'instant, il ne sert à rien du tout.
16 déc. 2006 à 15:27
Tu aurais besoin d'un destructeur virtuel, si à un moment dans ton code, tu voyais un objet HashTable* comme un objet Tableau*.
C'est à dire si tu avais quelque chose comme ça:
// quand on fait ça, mieux vaut un desctructeur virtuel
// dans Tableau
Tableau<T>* tab = new HashTable<T, string>;
Mais si tu faisais ça, il y aurait un léger problème conceptuel car ta classe de base ne possédant aucune autre fonction virtuelle, et donc quoique tu fasses, ton tab se comporterait comme un Tableau<T> et pas comme un HashTable.
Tu aurais donc une perte d'information à faire ça plutôt qu'à faire directement:
HashTable<T, string>* tab = new HashTable<T, string>;
Donc dans ton cas, comme tu ne voudras jamais considérer une HashTable comme un Tableau, tu peux enlever le destructeur virtuel, je t'assure que t'auras aucune fuite de mémoire...
ça montre quand même que le concept est pas super clair chez toi.
16 déc. 2006 à 15:15
je ré explique ce que j'ai dit. t'as pas besoin de destructeur virtuel si t'as aucune autre fonction virtuelle dans ta classe (c'est à dire classe non polymorphique), comme c'est le cas de tes classes Tableau et HashTable.
et effectivement, la vtable n'est pas créée quand ta classe ne possède aucune fonction virtuelle.
Rajouter le destructeur virtuel est de la responsabilité de la première personne qui rajoute une fonction virtuelle à la classe.
Je n'ai *pas* dit qu'il ne fallait pas de destructeur virtuel dans une classe polymorphique (car effectivement ça expose à des bugs insidieux comme l'explique l'article que tu as cité), mais je dit que ça sert à rien dans une classe sans autre fonction virtuelle. Et ça a tendance à mystifier le concept puisqu'il devient utilisé même quand il ne sert à rien (à part à augmenter pour rien la taille de chaque objet (à cause de la vtable en plus)).
16 déc. 2006 à 15:05
Forgetting to make a destructor virtual is an insidious bug because it often doesn?t directly affect the behavior of your program, but it can quietly introduce a memory leak.
Also, the fact that some destruction is occurring can further mask the problem.
Even though the destructor, like the constructor, is an exceptional function, it is possible for the destructor to be virtual because the object already knows
what type it is (whereas it doesn?t during construction).
Once an object has been constructed, its VPTR is initialized, so virtual function calls can take place.
Ex :
Shape class includes a virtual destructor,
something you should automatically add to any class with virtual functions.
If a container holds pointers or references to Shape objects, then when the virtual destructors are called for those objects everything will be properly cleaned up.
16 déc. 2006 à 14:06
En fait il permet juste aux classe dérivées de gérer des attributs dynamique en plus de la classe de base.
En gros, il ne gène pas s'il est mis mais peut faire défaut s'il n'y est pas.
La vtable n'est-elle pas créée même si pas de destructeur virtuel ???
Enfin, j'ai besoin d'étendre la classe Chaine et je ne connais pas bien std::string.
Idem pour vector, mais tu as raison, j'aurais pu étendre directement un vector<>.
Merci de ton interet en tout cas.
16 déc. 2006 à 11:59
destructeurs virtuels = âneries sur les classes qui sont pas polymorphiques. Tu forces la création d'une table virtuelle pour chaque objet de ces classes alors qu'il n'y en a pas besoin :p
sinon le code est bien, mais je comprends pas pourquoi tu utilises pas std::string et std::vector au lieu de créer tes propres templates Chaine et TableauGen (ok je comprends le but didactique, mais ce genre de trucs est une énorme source d'erreurs)
ta source est intéressante en tout cas ;)
16 déc. 2006 à 01:28
// ECX pmem, EDX v, [esp+4] = len
j'ai mis 2 fois ce super commentaire...
Plus sérieux: il est clair que j'ai fourni du prêt-à-l'emploi, impensable de commenter ce genre de bestiau, faudrait une secrétaire à temps plein.
16 déc. 2006 à 01:16
Enfin bref, la rapidité c'est pour les pros, le ludique et le fun est plus appréciable, sinon le soir c'est comme au boulot.
16 déc. 2006 à 01:08
La compression est le sujet typique qui évacue toute philo, la vitesse est primordiale.
16 déc. 2006 à 00:55
Mais je tiendrais compte de ta remarque.
Tchao.
16 déc. 2006 à 00:30
J'apportait simplement une précision :)
A+
16 déc. 2006 à 00:29
Je pense qu'il y a un rapport direct avec la présence des <stream>. Drole d'idée d'aller mettre ce genre de poids lourds dans du code API.
Regarde la différence:
http://www.cppfrance.com/code.aspx?ID=39145
30 Ko tout compris, c'est donc 26.5 qu'on ajoute à un prog pour y mettre compression décompression.