[C++/WIN32] COMPRESSEUR/DECOMPRESSEUR LZW

Commentaire de BruNews le 16/12/2006 00:29:28 administrateur CS

Si j'écarte les bmp, exe fait 190 Ko avec une simple dialog.
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.

Commentaire de yann_lo_san le 16/12/2006 00:55:49

BruNews, je sais que tu attaches beaucoup d'importance au énormes et méchants kiloOctets, mais la raison est simple, la facilité d'utilisation des stream et surcharge d'operateurs. (enfin pour moi...)
Mais je tiendrais compte de ta remarque.
Tchao.

Commentaire de yann_lo_san le 16/12/2006 01:16:26

BruNews > Après lecture de ton code bnZip, je crains de ne devoir dire qu'il est illisible, c'est un code perso qui n'interesse que celui qui le fait, sans commentaires, sans structures logiques, certe il est surement efficace (même si j'ai pas réussi à l'utiliser) mais qui va apprendre quelque chose de ces gros blocs d'assembleurs qu'on dirait copié colé du debuger microsoft.
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.

Commentaire de cosmobob le 16/12/2006 11:59:33

salut,
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 ;)

Commentaire de yann_lo_san le 16/12/2006 15:05:00

Précision : (thinking c++)
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.

Commentaire de cosmobob le 16/12/2006 15:27:02

et dans ce que tu dis, tu fais une légère confusion.

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.

Commentaire de magic_Nono le 18/12/2006 14:45:47

une petite remarque quant à l'interface, qui a l'aire tres réussie dans le shoot,
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.

Commentaire de vecchio56 le 20/12/2006 23:27:42 administrateur CS

Pareil que magin_nono:
http://img296.imageshack.us/img296/3196/1wk5.png

Manifestement c'est pas un problème de manifest

Commentaire de yann_lo_san le 22/12/2006 01:14:02

C'est quant même super bizarre cette histoire, c'est la première fois que ça m'arrive.
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...

Commentaire de yann_lo_san le 22/12/2006 14:48:56

VECCHIO56 > toute ma configuration xp est réglée sur Tahoma(8) et la police de boite de dialog est celle par défaut : MS Shell Dlg(8).

Commentaire de yann_lo_san le 22/12/2006 21:25:48

Effectivement.
Encore une entrée dans mon panthéon des mystères...
(qui commence à être sacrément lourd !)
A plus.

Commentaire de yann_lo_san le 11/05/2007 23:43:42

Et bien, je compile avec visual c++ 7 - 2002

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.