[C++] BASE64CONVERTER V1.1, UN ENCODEUR DÉCODEUR EN BASE64
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019
-
26 déc. 2006 à 12:23
katsankat
Messages postés571Date d'inscriptionvendredi 30 décembre 2005StatutMembreDernière intervention12 juillet 2012
-
27 août 2007 à 09:48
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
katsankat
Messages postés571Date d'inscriptionvendredi 30 décembre 2005StatutMembreDernière intervention12 juillet 20123 27 août 2007 à 09:48
Tu pourrais le développer dès aujourd'hui sous windows avec GTK+. Très rapide à développer car le code GTK+ est nettement plus simple que la programmation win32. Garder le module base64 et virer le reste. Si tu veux je te passe une ossature de fenêtre qui ressemble.
ordiman85
Messages postés41Date d'inscriptionsamedi 4 mars 2006StatutMembreDernière intervention19 mars 2010 26 août 2007 à 21:04
Si tu as un peu de temps dis moi comment je pourrais le faire porter sur linux au niveau des fenêtres et des contrôles ça m'intéresse vu que je vais surement passer sous linux bientot...
Merci d'avance
@+
katsankat
Messages postés571Date d'inscriptionvendredi 30 décembre 2005StatutMembreDernière intervention12 juillet 20123 25 juin 2007 à 15:05
Salut, aujourd'hui c'est bien conçu, de façon modulaire avec des objets faciles à réemployer, le code est suffisamment commenté, ça fonctionne et c'est facile à porter sur linux -> j'ai mis 9.
ordiman85
Messages postés41Date d'inscriptionsamedi 4 mars 2006StatutMembreDernière intervention19 mars 2010 27 déc. 2006 à 20:15
Merci pour vos remarques ^^ ici ce qui m'intéresse c'est de faire une toute petite appli donc il vaut mieux que je la fasse en C.
En effet ce sont les bibliothèques stl qui alourdissent le programme !! En C le nouveau programme compilé (partiellement codé) occupe à peine une quarantaine de Ko. Merci encore ! :)
@+
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 27 déc. 2006 à 18:39
La taille de ton programme vient exclusivement de l'utilisation des bibliothèques STL: sitôt que tu inclus iostream, string, vector, list, queue, stack, map, algorithm ................: n'importe lequel de ces olibrius, ton exe passe à 450 Ko sans l'option "strip". Si tu tiens à faire un petit exe, il faut t'en passer (c'est chiant ^_^). Dans la majorité des cas, on s'en tamponne pas mal que l'exe soit gros, et du reste: la fonction base64 toute seule ne "pèse" rien. Il y a deux cas de figure:
* soit tu as besoin d'un petit exe et tu l'adaptes pour utiliser des char* et des FILE plutôt que des string et des fstream
* soit tu utilises la fonction avec un programme qui inclus déjà la STL, auquel cas ça n'aura aucune incidence sur la taille de l'exe.
ordiman85
Messages postés41Date d'inscriptionsamedi 4 mars 2006StatutMembreDernière intervention19 mars 2010 27 déc. 2006 à 17:38
Je vais essayer de refaire le programme en C, ça va peut-être me faire gagner une centaine de ko...
Dites-moi ce que vous en pensez, pendant ce temps, je me lance (en essayant de faire + propre)
@+
ordiman85
Messages postés41Date d'inscriptionsamedi 4 mars 2006StatutMembreDernière intervention19 mars 2010 27 déc. 2006 à 17:27
BruNews :
Encoder et décoder dans un thread n'irait pas au moins aussi bien ?
J'avoue que les threads sont peut-être la meilleure solution, mais je voulais essayer d'autres méthodes qui prennent moins de performances mais il est vrai que déplacer la fenêtre ralentit le processus.
______________________
vecchio56 :
Avec quel compilateur as-tu obtenu ton exécutable?
J'utilise CNU GCC Compiler (par défaut dans Code::Blocks)
______________________
vecchio56 :
J'essaie de comprendre comment il peut faire 300Ko
Je l'ignore je suis moi-même surpris ! L'exécutable comprend gdi32.a, user32.a, kernel32.a, comctl32.a, un fichier .rc, une icône (25ko), le manifest (656o) et le code...
______________________
Arnaud16022 :
décoche " inclure les symboles de débug "
C'est fait...
______________________
Arnaud16022 :
Je soupçonne commctrl.h, qu'en disent les autres ?
Les headers ne prennent aucune place dans l'exécutable, ce ne sont que des déclarations de fonctions ou des #define (enfin d'après ce que je sais)
______________________
Kirua :
C'est pas super propre quoi :)
Dsl, j'ai appris à programmer tout seul et ça ne fait pas longtemps que je programme en C++ (et encore j'ai fait des progrès !).
Je vais apprendre petit à petit à structurer mes logiciels sans me précipiter comme je l'ai fait jusqu'ici (ça fait même pas une semaine que je suis sur ce projet)
______________________
Kirua :
Il est possible qu'il y ait aussi un début spécial
Non il n'y en a pas, ce qu'il y a, c'est qu'il faut encoder bloc par bloc (blocs de 3 pour donner des blocs de 4 d'où l'augmentation de la taille par 33%).
Sinon bonne idée pour le finalize !! Je prendrais plutôt le code de base64.sourceforge.net qui me semble adapté à la fois pour les fichiers et les strings.
______________________
Kirua :
Sais pas trop si c'est clair, mais en tout cas, il FAUT n'avoir la conversion base64 qu'à un seul endroit, ça c'est clair ^^.
Je suis d'accord ! Ca allégerait certainement le programme.
______________________
Je ne pensais pas que ce programme ferait autant de bruit... J'avoue que les codeurs décodeurs base64 en C, C++ ne sont pas très nombreux ici.
Allez je vais faire des efforts encore, bonnes fêtes à tous !
@+
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 27 déc. 2006 à 11:07
Hmm, c'est quand même assez sale d'avoir une partie des fonctions dans le main et l'autre partie dans deux fichiers séparés, selon le type de source de données. Sans compter le "OnEndConversion(hDlg);" dans les méthodes de conversion de fichiers. C'est pas super propre quoi :)
Je comprends bien le souci ceci dit: tu peux pas charger tout le fichier en mémoire au cas où il serait gros, mais tu peux pas donner le fichier bout par bout à la méthode de conversion de chaines parce qu'elle effectue un traitement de "fin". Mais ce que tu peux faire, c'est ajouter un paramètre optionnel aux méthodes séparées (les propres ^^):
(remarque que j'ai mis des const std::string& au lieu de string: ça évite de les copier inutilement tout en se prémunissant contre les modifs des données originales).
Si finalize est mis à false, l'algo n'effectue pas la partie de "finalisation" d'un encodage en base 64. Ça te permet d'appeler la fonction sur des bouts de chaîne du fichier et de les concaténer. Tu mets finalize à true uniquement pour le dernier bout.
Il est possible qu'il y ait aussi un début spécial, je ne sais plus. Mais un truc identique devrait fonctionner:
enum {START 1, CENTER 2, END = 4}
et par défaut, le paramètre serait: int pos = START | END.
Sais pas trop si c'est clair, mais en tout cas, il FAUT n'avoir la conversion base64 qu'à un seul endroit, ça c'est clair ^^.
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 27 déc. 2006 à 10:56
Dès que tu utilises la STL ton exe passe à 480 KO, et avec un strip tu descends à 240 Ko quand tu utilises G++ (sous win en tt cas). C'est ça, la magie des hello world :).
Sinon, c'est splendide que ce code arrive pile mtnt: j'ai 3 fenêtres ouvertes pour écrire mon encodeur base64 depuis 3 jours et pas le temps (blocus). J'irai lire ton code ... après le petit dèj' (ce qui peut expliquer pourquoi j'ai pas le temps de l'écrire moi-même).
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 26 déc. 2006 à 19:34
#include // Threads
#include <string> // chaines de caractères
#include // Fichiers
#include <fstream> // Fichiers
#include <stdio.h>
c'est d'abord tout cela que je commencerai à virer, mais bon...
Me semble évident aussi que pour faire du code Windows j'utilise un compilo MS, si toute la misère du monde m'obligeait un jour à faire du Linux j'emploierais bien entendu les outils dédiés.
Arnaud16022
Messages postés1329Date d'inscriptionvendredi 15 août 2003StatutMembreDernière intervention16 juin 20102 26 déc. 2006 à 19:22
Bon au mini j'arrive à 280 Kos, c'est louche.
Je soupçonne commctrl.h, qu'en disent les autres ?
Arnaud16022
Messages postés1329Date d'inscriptionvendredi 15 août 2003StatutMembreDernière intervention16 juin 20102 26 déc. 2006 à 19:16
oui oui C::B gère une bonne dizaine de compilos (même un compilo D ^^ ) Mais bon, l'install par défaut est avec mingW, donc c'est pour ça .
bon, je tente le coup et je vous dis
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 26 déc. 2006 à 18:41
Je pense pas qu'il a utilisé MinGW parce que j'ai fait un strip sur l'exe et ca fait rien
J'imagine avec Code::Blocks on peut utiliser n'importe quel compilateur
Arnaud16022
Messages postés1329Date d'inscriptionvendredi 15 août 2003StatutMembreDernière intervention16 juin 20102 26 déc. 2006 à 17:52
C'est dit, C::B -> on peut raisonnablement supputer MingW ... décoche " inclure les symboles de débug "
Sinon oui, porquoi pas de threads ? ça serait quand même plus simple je pense
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 26 déc. 2006 à 13:52
C'est vrai qu'on n'a pas l'habitude de voir ce genre de méthodes
Ca a l'intérêt de montrer une alternative aux threads, mais c'est très certainement moins efficace (par exemple, si on déplace la fenêtre pendant le traitement, ca bloque le traitement)
Avec quel compilateur as-tu obtenu ton exécutable? (J'essaie de comprendre comment il peut faire 300Ko)
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 26 déc. 2006 à 12:23
Encoder et décoder dans un thread n'irait pas au moins aussi bien ?
27 août 2007 à 09:48
26 août 2007 à 21:04
Merci d'avance
@+
25 juin 2007 à 15:05
27 déc. 2006 à 20:15
En effet ce sont les bibliothèques stl qui alourdissent le programme !! En C le nouveau programme compilé (partiellement codé) occupe à peine une quarantaine de Ko. Merci encore ! :)
@+
27 déc. 2006 à 18:39
* soit tu as besoin d'un petit exe et tu l'adaptes pour utiliser des char* et des FILE plutôt que des string et des fstream
* soit tu utilises la fonction avec un programme qui inclus déjà la STL, auquel cas ça n'aura aucune incidence sur la taille de l'exe.
27 déc. 2006 à 17:38
Dites-moi ce que vous en pensez, pendant ce temps, je me lance (en essayant de faire + propre)
@+
27 déc. 2006 à 17:27
Encoder et décoder dans un thread n'irait pas au moins aussi bien ?
J'avoue que les threads sont peut-être la meilleure solution, mais je voulais essayer d'autres méthodes qui prennent moins de performances mais il est vrai que déplacer la fenêtre ralentit le processus.
______________________
vecchio56 :
Avec quel compilateur as-tu obtenu ton exécutable?
J'utilise CNU GCC Compiler (par défaut dans Code::Blocks)
______________________
vecchio56 :
J'essaie de comprendre comment il peut faire 300Ko
Je l'ignore je suis moi-même surpris ! L'exécutable comprend gdi32.a, user32.a, kernel32.a, comctl32.a, un fichier .rc, une icône (25ko), le manifest (656o) et le code...
______________________
Arnaud16022 :
décoche " inclure les symboles de débug "
C'est fait...
______________________
Arnaud16022 :
Je soupçonne commctrl.h, qu'en disent les autres ?
Les headers ne prennent aucune place dans l'exécutable, ce ne sont que des déclarations de fonctions ou des #define (enfin d'après ce que je sais)
______________________
Kirua :
C'est pas super propre quoi :)
Dsl, j'ai appris à programmer tout seul et ça ne fait pas longtemps que je programme en C++ (et encore j'ai fait des progrès !).
Je vais apprendre petit à petit à structurer mes logiciels sans me précipiter comme je l'ai fait jusqu'ici (ça fait même pas une semaine que je suis sur ce projet)
______________________
Kirua :
Il est possible qu'il y ait aussi un début spécial
Non il n'y en a pas, ce qu'il y a, c'est qu'il faut encoder bloc par bloc (blocs de 3 pour donner des blocs de 4 d'où l'augmentation de la taille par 33%).
Sinon bonne idée pour le finalize !! Je prendrais plutôt le code de base64.sourceforge.net qui me semble adapté à la fois pour les fichiers et les strings.
______________________
Kirua :
Sais pas trop si c'est clair, mais en tout cas, il FAUT n'avoir la conversion base64 qu'à un seul endroit, ça c'est clair ^^.
Je suis d'accord ! Ca allégerait certainement le programme.
______________________
Je ne pensais pas que ce programme ferait autant de bruit... J'avoue que les codeurs décodeurs base64 en C, C++ ne sont pas très nombreux ici.
Allez je vais faire des efforts encore, bonnes fêtes à tous !
@+
27 déc. 2006 à 11:07
Je comprends bien le souci ceci dit: tu peux pas charger tout le fichier en mémoire au cas où il serait gros, mais tu peux pas donner le fichier bout par bout à la méthode de conversion de chaines parce qu'elle effectue un traitement de "fin". Mais ce que tu peux faire, c'est ajouter un paramètre optionnel aux méthodes séparées (les propres ^^):
std::string Base64Encode(const std::string& data, bool finalize = true);
std::string Base64Decode(const std::string& data, bool finalize = true);
(remarque que j'ai mis des const std::string& au lieu de string: ça évite de les copier inutilement tout en se prémunissant contre les modifs des données originales).
Si finalize est mis à false, l'algo n'effectue pas la partie de "finalisation" d'un encodage en base 64. Ça te permet d'appeler la fonction sur des bouts de chaîne du fichier et de les concaténer. Tu mets finalize à true uniquement pour le dernier bout.
Il est possible qu'il y ait aussi un début spécial, je ne sais plus. Mais un truc identique devrait fonctionner:
enum {START 1, CENTER 2, END = 4}
et par défaut, le paramètre serait: int pos = START | END.
Sais pas trop si c'est clair, mais en tout cas, il FAUT n'avoir la conversion base64 qu'à un seul endroit, ça c'est clair ^^.
27 déc. 2006 à 10:56
Sinon, c'est splendide que ce code arrive pile mtnt: j'ai 3 fenêtres ouvertes pour écrire mon encodeur base64 depuis 3 jours et pas le temps (blocus). J'irai lire ton code ... après le petit dèj' (ce qui peut expliquer pourquoi j'ai pas le temps de l'écrire moi-même).
26 déc. 2006 à 19:34
#include <string> // chaines de caractères
#include // Fichiers
#include <fstream> // Fichiers
#include <stdio.h>
c'est d'abord tout cela que je commencerai à virer, mais bon...
Me semble évident aussi que pour faire du code Windows j'utilise un compilo MS, si toute la misère du monde m'obligeait un jour à faire du Linux j'emploierais bien entendu les outils dédiés.
26 déc. 2006 à 19:22
Je soupçonne commctrl.h, qu'en disent les autres ?
26 déc. 2006 à 19:16
bon, je tente le coup et je vous dis
26 déc. 2006 à 18:41
J'imagine avec Code::Blocks on peut utiliser n'importe quel compilateur
26 déc. 2006 à 17:52
Sinon oui, porquoi pas de threads ? ça serait quand même plus simple je pense
26 déc. 2006 à 13:52
Ca a l'intérêt de montrer une alternative aux threads, mais c'est très certainement moins efficace (par exemple, si on déplace la fenêtre pendant le traitement, ca bloque le traitement)
Avec quel compilateur as-tu obtenu ton exécutable? (J'essaie de comprendre comment il peut faire 300Ko)
26 déc. 2006 à 12:23