Wrapper zlib, un panégyrique

Il semblerait bien que mon wrapper C++ de la zlib soit un particulièrement recherché, si j'en crois mes stats. Je tiens donc à préciser que le bout de code en question tourne joyeusement en production au boulot, et que je l'utilise également dans le code réseau d'AdH. Pour l'instant, pas de bugs en vue, et une utilisation plutôt sobre de la mémoire.

En regardant les autres implémentations sur le net, l'on s'aperçoit que beaucoup sont centrées autour des fichiers, ce que je trouve plutôt étonnant. Je ne vois en effet pas vraiment l'intérêt de s'amuser à compresser ou décompresser un fichier à partir d'un programme C++. Si par exemple l'on est inquiet de la taille que prennent les logs, pourquoi ne pas avoir une tâche quotidienne qui appelle un bon vieux tar bz2? Si ce sont des données binaires, sont-elles si grosses qu'elles vaillent la peine de se fatiguer à les compresser, pour un gain généralement assez faible? Si c'est du XML, est-ce la peine de perdre le gros avantage de pouvoir l'éditer à la main? Bien sûr, il y a des cas où utiliser directement zlib pour compresser un fichier aura un avantage, mais à ce point?

En l'occurrence, j'utilise mon wrapper dans deux cas. D'une part, pour sauver des fichiers XML dans une base de données. Nos utilisateurs veulent sauver des frames XML de tailles qui s'approchent du mégaoctet, et la base n'a pas beaucoup de place libre. La compression permet de gagner jusqu'à 20 fois l'espace, et nos utilisateurs, au lieu de faire sauter la base au bout de 1000 entrées, ce qui risque d'arriver dans l'année, pourront insérer jusqu'à 20 000 entrées, ce qui nous permet de souffler un peu. Et j'en conviens, avoir seulement 1 gigaoctet d'espace dans la base, c'est pas malin, mais que voulez-vous, c'est corporate...

D'autre part, et c'est là que la simplicité prime, compresser les paquets que l'on envoie à travers le réseau résulte en un très bon gain de performances, et permet de voir venir des structures beaucoup plus grosses. Bien sûr, n'oubliez pas que le gain dépend de la taille des données, et qu'il vous faut trouver la limite à partir de laquelle il est intéressant de compresser! Décidément, c'est la journée des backlinks, j'en avais causé ici.

Et dans ces deux cas, je ne peux m'empêcher que l'approche fonctionnelle, une fonction pour compresser, une autre pour décompresser, est de loin la plus simple et la plus élégante! Pourquoi aurait-on à créer un objet, et s'embêter avec deux ou trois couches d'abstraction? Ou pire, utiliser des méthodes statiques! Beurk...

Du simple (deux petites fonctions), du fonctionnel (fonctions libres, pas d'effets de bord), du standard (istream, ostream, vous pouvez même passer un fichier si ça vous fait plaisir).

Oh, et j'ai reçu mon WTF mug! Cool, non?