* Sax oblige a écrire plein de callbacks. Ca fait tout ce dont on peut avoir besoin, mais c'est assez lourd à coder.
* DOM chargeant tout en mémoire, ce n'est pas adapté pour les gros fichiers.
;

Introduction

Le XML c'est génial, le XML c'est beau, le XML vous fait le cacao le matin.

Pour charger un fichier XML, il y a traditionnellement deux API : Sax et DOM

• Sax oblige a écrire plein de callbacks. Ca fait tout ce dont on peut avoir besoin, mais c'est assez lourd à coder.
• DOM chargeant tout en mémoire, ce n'est pas adapté pour les gros fichiers.

Stax

L'API de type Stax est un juste milieu entre des deux approches. L'idée, c'est qu'au lieu de laisser le parseur tout gérer, on va lui demander un élément, l'analyser nous-même, puis demander l'élément suivant.

La libxml2, du projet Gnome, fournit une API de ce type. Elle est plutôt bien documentée, mais les exemples, mêmes s'ils sont fonctionnels, ne sont pas très utiles tels quels : la plupart accèdent à un élément connu d'avance et listent ses propriétés. Généralement, quand on a un fichier XML tellement gros qu'on ne peut pas utiliser DOM, la problématique est plutôt : découvrir à la volée ce qu'on a dans le fichier.

Fichier d'exemple

Pour ce tutoriel, j'utiliserai des fichiers de dump OpenStreetMap, qui peuvent atteindre plusieurs centaines de Go. Un bon test pour les fuites mémoires...

En simplifié , ça ressemble à ça (ici sur un bout de granite près de Lannion) :

<?xml  version="1.0" encoding="UTF-8" ?>
<osm version="0.6"  generator="CGImap 0.0.2">
    <bounds minlat="48.7640630"  minlon="-3.5936820" maxlat="48.7670190" maxlon="-3.5882580"  />
    <node id="28204783"  lat="48.7661740" lon="-3.5946960">
        <tag k="created_by"  v="almien_coastlines" />
    </node>
    ... encore beaucoup de texte

Donc, une racine "osm" avec un noeud "bounds" et une liste de noeuds "node", tous avec des attributs.

Initialisation

L'initialisation est très simple, et bien expliquée dans les tutoriaux officiels :

xmlTextReaderPtr reader = xmlReaderForFile("machin.xml", NULL, 0);
if (reader == NULL) return;
// 1 if the node was read successfully, 0 if there is no more nodes to read, or -1 in case of error :
if (xmlTextReaderRead(reader) == 0) return;
readRoot(policy); // C'est ici qu'on va lire la racine du fichier, et tout les enfants
xmlFreeTextReader(reader);

Lecture

Voyons voir cette fonction readRoot :

Tout d'abord, un petit test pour être sûr que l'on a pas fait de bêtise :

if (xmlTextReaderDepth(reader) != 0) return error("Le noeud racine devrait être OSM");

Ensuite, on demande au parser le nom de l'élément suivant. Il va donc lire juste ce qu'il faut du fichier pour savoir ça, et s'arrêter :

xmlChar *name;
name = xmlTextReaderName(reader);

On vérifie alors qu'on a bien un noeud "osm" comme racine:

if (name == NULL) return error("pas de noeud racine");
if (xmlStrcmp(name, (const xmlChar *) "osm")) return error("Ceci n'est pas un fichier OpenStreetMap");

Maintenant qu'on est sûrs qu'on est dans l'élément qu'on veut, on n'a plus besoin de name, donc on le libère :

xmlFree(name);

Ensuite, on va lire tous les attributs, par exemple pour vérifier qu'on est bien en OSM 0.6 :

while(xmlTextReaderMoveToNextAttribute(reader)){
    xmlChar *name_attrib, *value_attrib;
    name_attrib = xmlTextReaderName(reader);
    value_attrib = xmlTextReaderValue(reader);
    if (!xmlStrcmp(name_attrib, (const xmlChar *) "version") && xmlStrcmp(value_attrib, (const xmlChar *) "0.6")){
        std::cout << "Attention, la version du fichier n'est pas 0.6" << std::endl;
    }
    xmlFree(name_attrib);
    xmlFree(value_attrib);
}

Remarquez que les attributs ne sont absolument pas ordonnés, ni accessibles tous d'un coup. Si c'est le comportement que vous souhaitez, utilisez une map (ou map )
On veut maintenant lire les enfants : on demande le chunk suivant, on regarde son type, et on avise. Et on répète jusqu'à ce que le fichier soit vide, càd que xmlTextReaderRead retourne 0 (fin) ou -1 (erreur).

L'astuce, c'est que dans le "on avise", on va également pouvoir appeler xmlTextReaderRead, et lire ainsi récursivement tous les enfants :

int ret = xmlTextReaderRead(reader);
while (ret == 1) {
    xmlChar * name = xmlTextReaderName(reader);
    if (!xmlStrcmp(name, (const xmlChar *) "bounds")){ ret = readBounds();}
    else if (!xmlStrcmp(name, (const xmlChar *) "node"  )){ ret = readNode();    }
    else if (!xmlStrcmp(name, (const xmlChar *) "way"   )){ ret = readWay();}
    else                                                  { ret = xmlTextReaderRead(reader);} // Ne devrait pas arriver, mais peut-être que le fichier est mal formé ?
    xmlFree(name);
}

Et voilà ! readBounds n'a pas de surprises, il n'y a que des attributs, mais voyons readNode pour l'exemple :

if (xmlTextReaderDepth(reader) != 1) return error("un Node doit être au niveau 1");
while(xmlTextReaderMoveToNextAttribute(reader)){
    // Faites ce que vous voulez avec les attributs
}
int ret = xmlTextReaderRead(reader);
while (ret == 1) {
 
    // un noeud frère ou parent arrive : on redonne le contrôle au parent pour qu'il le gère.
    // Si c'est de nouveau un noeud, readRoot rappellera tout naturellement readNode.
	if (xmlTextReaderDepth(reader) <= 1){
		return 1; // 1 = lire la suite (cf readRoot)
	}else{ // child node
	xmlChar * name = xmlTextReaderName(reader);
        // faire quelque chose en fonction de name. Ici, on lit en boucle en ignorant les tags
        ret = xmlTextReaderRead(reader);
        xmlFree(name);
    }
}
return 0; // Ne devrait pas arriver

Lecture de très gros fichiers

Quand on lit des fichiers de 200Go, il est souvent utile de prévenir l'utilisateur de là où on en est, histoire d'éviter le ctrl-c furieux. On sort alors un peu d'une utilisation "simple" de la libxml2, mais c'est possible.

Tout d'abord, on abandonne xmlReaderForFile au profit de xmlNewTextReader, qui prend en paramètre un xmlParserInputBufferPtr. Cet objet implémentera les callbacks de lecture de fichier (i.e. fopen, fread, etc), tout comme xmlReaderForFile le fait en interne, à la différence près qu'on va retenir là où on en est dans le fichier.

Tout d'abord, on veut trouver la taille du fichier, en octets :

FILE * file = fopen(path,"r");
if (!m_file) return -1;
 _fseeki64(m_file,0, SEEK_END);
 __int64 size = _ftelli64(m_file); // la taille
 _fseeki64(m_file,0, SEEK_SET);

Remarquez que l'on n'utilise pas fseek, qui sont limités à des fichiers de 3Go (adressable en 32 bits). Les streams C++ ont le même problème sur les OS 32 bits, d'où l'utilisation de ces fonction assez incongrues en C++.

Maintenant, créons notre parseur :

xmlParserInputBufferPtr input = xmlParserInputBufferCreateIO(
    xmlInputReadCallback_Function,
    xmlInputCloseCallback_Function,
    this, // Ou n'importe quel objet, ou même NULL si vous mettez vos données en global
    XML_CHAR_ENCODING_NONE
 );
reader = xmlNewTextReader(input, "foobar file"); // Le second paramètre est obligatoire et inutile

Nous avons donc besoin de deux fonctions : xmlInputReadCallback_Function et xmlInputCloseCallback_Function. La seconde est assez évidente (fclose), intéressons-nous à la première :

int xmlInputReadCallback_Function (void * c, char * buffer, int length ) {
    // length est la taille du buffer demandé.
    // Sauf si vous avez recompilé la lib avec des options particulières, ce sera 4096, soit 4Ko
    UpdateProgress(length);
    // Lit 4096 octets du fichier dans le buffer
    return (int)fread(buffer,1,length,file);
}

Voilà, le callback est fini. Il ne vous reste plus qu'à implémenter UpdateProgress à votre convenance. Par exemple, pour une application en ligne de commande :

pos+=length; // On retient la position actuelle
if (m_size && (100*(m_pos-length)/m_size) != 100*m_pos/m_size) // Si la position a changé de plus de 1%
 std::cout << (int(100*m_pos/m_size)) << std::endl; // on affiche

ce qui fera un compteur de 1 à 100. Avec Qt, un signal en Qt::QueuedConnection (pour éviter de bloquer l'UI) fera également très bien l'affaire.

Conclusion

Nous avons donc vu comment lire un très gros fichier XML avec l'API Stax de la libxml2. Maintenant, il ne vous reste plus qu'à encapsuler tout ça, vu que pour des raisons de simplicité, j'ai fait comme si toutes les variables étaient globales.

Donc pour résumer :

• DOM si vous pouvez
• Sax si vous êtes obligés (pas d'autre API sur votre plate-forme, ...)
• Stax sinon !

C'était mon tout premier tuto Une pièce d'histoire...

Welcome pour mon premier tuto

Nous allons apprendre à faire un truc trop cool, de la POO en assembleur.
Mais bon on va y aller doucement, on va commencer par interfacer asm et C.

Pour commencer, quel est l'intérêt ? Tout simplement d'avoir accès à toutes les possibilités de l'assembleur tout en gardant un contrôle total sur le code généré (puisque justement c'est nous qui le générons ^^ ).
Evidement on pourrait simplement mettre asm{ /* code */ } mais le compilo rajoute ses propres trucs, et si on a une application très spéciale ça peut être embêtant ( je pense tout particulièrement à ScalP pour ceux qui connaissent, où j'ai été obligé de faire ça ): on n'a pas de contrôle sur les registres utilisés ainsi que sur l'utilisation de la pile, à laquelle on peut vouloir accéder.
En outre ce n'est absolument pas portable, chaque compilo a sa propre syntaxe.
De toute façon pour les indécis j'ai un argument-choc : ça fait méga g33k!
convaincu ? ^^

Alors allons-y...

Interfacer assembleur et C

Appeler de l'assembleur en C

Pour ceux qui ne connaissent absolument rien à l'assembleur, un chti tuto est disponible [url="http://www.coder-studio.com/?page=tutoriaux_aff&code=asm_1"]ici[/url], merci Funto !

Disons qu'on a ce programme :

// main.cint asm_carre (int);
int main( int nagrs, char ** vargs){
 int a = 4;
 int b = asm_carre(a);
 printf("D'après notre fonction assembleur, le carré de %d vaut %d\n",a,b);
 return 0;
}

avec int asm_carre (int) une fonction que l'on va implémenter en assembleur.
On écrit le prototype dans le .c pour que le compilateur connaisse la fonction.
Bien évidemment ça ne compilera pas dans l'état, personne ne connaît où se trouve l'implémentation de asm_carre.
Mais où mettre cette implémentation ? simple, dans un .asm... gogogo !

; asm_carre.asm
[BITS 32]
segment .data ; données initialisées: rien pour l'instant.
segment .bss  ; données non initialisées, toujours rien.
segment .text ; ah ! on entre dans le CS ( Code Segment )
 global _asm_carre ; on va exporter ce symbole
_asm_carre:
 enter 0,0         ; on n'utilise aucune variable, uniquement des registes.
 push ebx          ; La valeur de ebx ne DOIT PAS être modifiée par la fonction !! alors on le met temporairement sur la pile ( même si dans ce cas précis c'est inutile )
 mov eax,[ebp+8]   ; le paramètre de la fonction ce trouve à cet endroit.
 mul eax           ; eax = a*a
 pop ebx           ; on restaure ebx
 leave             ;
 ret               ; retour à la fonction appelante

héé partez pas
Pour les quatre premières lignes, si vous ne comprenez pas refaites un petit tour sur le tuto de Funto.
bon.
pourquoi global? pour dire à NASM que cette fonction pourra être appelée d'un programme externe.
pourquoi _asm_carre et non pas asm_carre ? C'est une convention d'écriture. Chaque fois que vous voudrez créer une fonction asm devant être appelée à partir du C, il faudra préfixer le label par _

ensuite place à l'implémentation.
Attention, rappelez vous que la pile de processeur commence à DROITE et s'aggrandit vers la gauche, donc quand on pushe une variable, elle se met le plus à gauche possible. Du coup ce qui se trouve en ebp+4 a été mis sur la pile AVANT ce qui se trouve en ebp+0

enter 0,0 : ne sert pas à grand chose ici.

push ebx : ici cela n'est pas réellement utile non plus puisque ebx, on n'y touche pas; mais c'est une question de bonnes habitudes car il est interdit pour une fonction de modifier ebx ( quand on l'interface avec du C/C++ tout du moins, en asm pur vous faites ce que vous voulez )
C'est embêtant ça ! déjà que des registes on n'en a pas beaucoup... alors du coup on le pushe, et on le popera juste avant de redonner la main au C.
à vrai dire.. il n'y a pas que ebx, mais aussi esi,edi,ebp,cs,ds,ss et es ... au pire : pusha / popa.
]

----------------------------------------------------------------
| adresse ||| ebp - 4  | ebp + 0  |    ebp + 4     |  ebp + 8  |
----------------------------------------------------------------
| contenu |||   ???    |    ebp   | adresse retour | parametre |
----------------------------------------------------------------

mov eax,[ebp+8] : strico sensu, met ce qui se trouve en ebp+8 ( sur la pile ) dans eax. Mais qu'est-ce qui se trouve donc en ebx+8 ? ohhh, notre paramètre

mul eax,eax : on multiplie eax par lui même ...

pop ebx: voilà, comme ça le standard est respecté et on risque pas de se retrouver avec erreurs incompréhensibles.

leave: symétrique de enter

ret : pope l'adresse de la fonction appelante et y va: ici, on était dans le main, ligne 2...

et voilà nous revoilà dans notre programme C avec le carré du paramètre dans eax. cool, ça sert à quoi? hé bien justement, la valeur de retour d'une fonction DOIT être dans eax, c'est la règle. Et du coup, tout est bon, b=a^2.

En fait on pouvait faire plus simple, c'est là tout l'avantage de l'assembleur :

_asm_carre:
 mov eax,[esp+4]
 mul eax
 ret

fini ! La rule of thumb, c'est 1 : vous ne modifiez pas les registres cités plus haut et 2 : valeur de retour dans eax.
[nota : eax c'est pour les DWORDS. Pour un WORD c'est ax, pour un QWORD, edx:eax]
remarquez que je n'ai pas utilisé ebp (base pointer) mais esp ( stack pointer ) car il n'y a pas la commande enter, dont l'un des rôle est justement de faire mov ebp,esp.

Bon , compilons ! OK c'est bon ça marche... Argheul nan, la compilation se fait sans ennuis mais erreur au linkage : l'éditeur de liens ne sait pas où trouver l'implémentation de asm_carre. Et pour cause ! il n'a pas été assemblé :niii:
Qu'à cela ne tienne :

C:\>nasm.exe -o asmlib.o -f coff asm_carre.asm

( si vous n'êtes pas sous windows utilisez -f elf )
Voilà vous avez un merveilleux .o ! Il n'y a plus qu'à demander au compilo de linker avec , et magie !! ça plante
[NOTAs :

• on peut utiliser aussi, nasm -f win32 asm_carre.asm , ca donnera asm_carre.obj, à linker de même manière.
• Pour éviter de retourner dans la console à chaque modif on peut aussi faire ça automatiquement : dans VC6, Project->Settings-> onglet pre-link step-> nouveau-> entrez cette ligne...

]

( bon en fait non ça plante pas mais c'est parce que vous avez de la chance )
La raison est simple, la convention d'appel utilisée par le compilo C++ est le _stdcall ( params empilés de gauche à droite, dépilés dans la fonction elle même ) et il y a de fortes chances pour que vous ayez écrit votre fonction assembleur en _cdecl ( params empilés de droite à gauche, dépilés par le programme appelant ). Aurement dit, gros plantage assuré s'il n'y a pas la même convention des deux côtés (heureusement ici c'est du C, pas du C++, donc pas de plantage en fait) .
pour spécifer la convention :

• sous VC++ : _cdecl int fonction ( int ); // respectivement _stdcall
• sous GCC : int fonction ( int ) __attribute__((cdecl)); // respectivement stdcall

Yeah ! Là ça marche vraiment, et on sait pourquoi

Appeler de l'asm, qui appelle du C

Bon, on ne va pas s'arrêter en si bon chemin ... maintenant qu'on sait écrire des fonctions hyper puissantes et polyvalentes en assembleur ( *hum* ), on aura sûrement besoin, à un moment ou à un autre, d'appeller une fonction qui elle est implémentée dans le prog C, ou même dans les librairies standard ... genre strcmp !

Pour ça c'est très simple, il suffit de déclarer le nom de la fonction en extern au début du segment .text et le linker s'occupera de tout.

Dans le genre "Programme qui sert à rien" ça donne ça:

// main.c
int _cdecl asm_carre (int);
int main( int nagrs, char ** vargs){
 int a = 4;
 int b = asm_carre(a);
 printf("D'après notre fonction assembleur, le carré de %d vaut %d\n",a,b);
 return 0;
}
int _cdecl carre(int a){return a*a;}

puis:

; asm_carre.asm
[BITS 32]
segment .text
 global _asm_c_carre:
 extern _carre ;remarquez qu'ici aussi on met un _
_asm_c_carre:
 mov eax,[esp+4]   ; on prend le param sur la pile
 push eax      ; on le re-pushe au sommet de la pile
 call _carre      ; on appelle la fonction
 add esp,4         ; on dépile
 ret               ; on retourne au C

Héé oui vous l'aurez compris, ce code atteint le sommum de l'inutilité en appellant la fonction asm_carre qui se contente d'appeler carre(), qui lui est implémenté en C ^^
Attention cependant, cela ne marche pas avec le format COFF, le win32 est impératif ( et souvenez vous que du coup ça donne pas en .o mais un .obj)

Interfacer assembleur et C++

- Here comes the bidouille -

Bien, toutes les bases sont posées, ce que vous ferez de cela dépendra de vos connaissances en assembleur.
Mais maintenant nous sommes en 2006, ya un truc qui est pas mal : le C++.
ça serait bien qu'on puisse interfacer le C++ et l'assembleur de la même manière qu'avec le C... non?

Malheureusement la convention qui nous dit de rajouter un petit _ , c'est une convention C ! et non C++ ...
c'est là que les embrouilles commencent, parce que les éditeurs de compilateurs s'en sont donné à coeur joie pour nous peaufiner des tonnes de conventions aussi différentes et incompréhensibles les unes que les autres...
ça s'appelle le name mangling ( décoration de nom ) et c'est pas du tout, mais alors pas du tout standardisé.
Heureusement, le linker est votre ami !
Ainsi, si vous renommez le main.c précédent en main.cpp, la compilation encore une fois se déroulera sans souci, mais le linker va vous sortir une erreur du genre :

tuto.obj : error LNK2001: unresolved external symbol "int __cdecl asm_carre(int)" (?asm_carre@@YAHH@Z)

Oh magie , un joli nom de label tout bizarroïde apparaît : ?asm_carre@@YAHH@Z
Il suffit d'un petit copier-coller de ce nom pour remplacer tous les _asm_carre par ?asm_carre@@YAHH@Z dans le listing assembleur.
On réassemble, on recompile, ça marche ! *joie*

Pour la compatibilité entre les différents compilateurs, on peut s'amuser à regarder toutes les erreurs de linkage créées par tous ces compilos, ajouter tous ces noms dans la liste des labels extern, et remplacer chaqun de ces labels par la liste des labels demandés par l'ensemble des compilos.....

Assembleur Orienté Objet ?

Oui c'est possible
Tout du moins à certaines conditions .....
Admettons que nous ayons une classe CMaClasse avec une fonction membre void Calcule(void).
hé bien jusque là c'est très simple : c'est exactement la même chose qu'avant. On regarde l'erreur du linker, on copie-colle le nom de la fonction.
Ca marche ... si et seulement si ladite classe est un POD ou au mieux un agrégat. Donc : pas de virtuel ! ni fonction ni membre ni quoi que ce soit de virtuel. On a le droit à l'héritage si ça reste un agrégat, mais bon ça devient plus compliqué après et à priori ça dépend du compilo utilisé.
( théoriquement, même avec du virtuel c'est possible mais n'y songez même pas ^^)

Bon , maintenant, admettons que l'on veuille prendre des paramètres. le prototype devient:

void CMaCLasse::Calcule(int a);

sauf que ...
sauf que c'est pas si simple, ce prototye c'est celui que vous écrivez, pas celui qui est utilisé.
le compilo, lui, il comprend ça:

void CMaClasse::Calcule( CMaClasse* this, int a);

c'est d'ailleurs pour ça que vous avez accès aux membres quand vous faites Instance->fonction();, ça tombe pas du ciel ...

Une fois dans la partie asm, voilà donc l'état de la pile:

----------------------------------------------------------------------------
| adresse ||| ebp - 4  | ebp + 0  |    ebp + 4     |  ebp + 8  | ebp + 12  |
----------------------------------------------------------------------------
| contenu |||   ???    |    ebp   | adresse retour |    this   | parametre |
----------------------------------------------------------------------------

'a' n'est donc plus en ebp+8 mais en ebp+12 ! à part ça rien ne change.

bon , maintenant que j'ai accès aux paramètres, je veux une valeur de retour: pareil qu'en C ! dans eax ...

[NOTA : dans la source d'exemple , j'accède à this avec mov ecx,[esp+4], mais c'est parce que je n'utilise pas enter et leave.

et dernier point fun : accéder aux membres
Le truc sympa c'est qu'on a this...
ce qu'il faudrait c'est donc ça : (ebp+8)->_membre, c'est à dire, en simili-nasm: [ebp+8]._membre
mais comment avoir l'adresse de _membre ? simple, pour un POD, le c++ demande que les membres soient stockés en mémoire de façon contigüe (cela est rarement respecté, voir plus bas) et dans l'ordre de la déclaration.
exemple:

class CMaClasse{
public:
 int a;
private:
 char c;
protected:
 float f;
};
CMaClasse inst;

dans ce cas, la mémoire sera :

0         4   5         9
-------------------------
| * * * * | * | * * * * |
|    a    | c |    f    |
-------------------------

( un * correspond un octet, le 4 signifie qu'on se situe à l'adresse &inst +4 )
( On voit d'ailleurs qu'il est presque toujours préférable de classer ses membres par taille décroissante, ça optimise les accès mémoire)

NOTA:
la plupart des compilos alignent automatiquement sur 4 octets (c'est plus rapide à l'exec), ce qui donne une organisation de la mémoire comme ça:

0         4        8         12
------------------------------
| * * * * | *      | * * * * |
|    a    | c      |    f    |
------------------------------

on peu configurer ça soi même l'alignement mémoire avec la directive pragma.
Pour comprimer au maximum la structure sous VC++ :

#pragma pack(push)
#pragma pack(1)
struct lkjlkj{...};
#pragma pack(pop)

et sous gcc:

struct ljhlkjh{
...
}__attribute__((packed)); // (oui c'est compliqué et alors ? :p)

/NOTA

nous disions donc que nous avions this en ebp+8 et qu'on voulait les membres... admettons que je veuille mettre f dans ebx. je dois alors faire:

mov ecx, [ebp+8] ;ecx=this;
mov eax, [ecx+5] ;eax=*(this+5); on met dans eax les 4 octets( 4 car c'est eaXX) situés à l'adresse this+5

(on peut optimiser avec lea , mais passons)
à partir de là on peut accéder au membres, une bonne idée est d'utiliser les macros de nasm pour y accéder plus aisément en donnant des noms compréhensibles a [ecx+5] ...)

voili voilou !!!
Comment ça ya plus personne avec moi :p

dernière chose: Magie de l'assembleur on peut même appeller des fonctions membres...mais fait connaître le label, pour ça il suffit de faire un appel de ladite fonction quelque part dans le c++ tout en commentant l'implémentation. Le linker va râler, et par là même donner le label qu'il cherche.
Ne pas oublier de pusher this! ...
Maintenant, petit truc sympa et bien utile: quand votre routine asm plante... mettez vous en mode débug dans VC++, relancez...vous verrez s'afficher le desassembly MASM de votre code NASM, avec la ligne à laquelle ça a planté...faites clic droit sur la barre des menus, cliquez sur registres: voilà, vous contrôlez votre machine B-) :p

Bon ben voilà, je verrai ce qu'il y a à ajouter à cela, please feel free de faire des commentaires dans le forum
N'oubliez pas d'aller voir les exemples.

Un zip est disponible [url="http://coder-studio.com/tutoriaux/asm/asm_4.zip"]ici[/url], et la discussion se poursuit [url="http://www.coder-studio.com/forum2/viewtopic.php?id=904"]là[/url] !

Introduction

Ce tutorial s'inscrit dans la lignée du tutorial sur les pbuffers, disponible [url="http://www.coder-studio.com/"]ici[/url] (NDLR : que je n'ai pas reporté tellement c'est vieux).
Le but est toujours le même : permettre d'enregistrer une scène sur une texture rapidement, afin de pouvoir réaliser moult joulis gfx
Nous avions vu que si les pbuffers étaient performants, ils n'existaient que sous Linux. Une extension plus récente a depuis fait apparition, ce sont les framebuffer objets. L'API pour y accéder a été normalisée par l'ARB mi-2004. C'est une extension complexe, la spec fait un demi-Mo de texte brut. Mais n'ayez pas peur, ça va bien se passer

Une caractéristique agréable du fbo est qu'elle permet, si toutefois la carte graphique le supporte, de dessiner sur des NPOTS : Non Power Of Two textures. Autrement dit, si votre écran fait 800*600, vous pouvez sans problème aucun avoir une texture de 800*600, dessiner dessus, puis l'utiliser comme une texture normale, au lieu de devoir utiliser une 1024x1024 et d'en perdre une bonne partie.

Nous allons donc voir comment utiliser ces textures rectangulaires, puis comment utiliser les fbos.

Les textures rectangulaires

Il s'agit ni plus ni moins d'une texture normale, très banale. La seule différence avec GL_TEXTURE_2D est son nom : GL_TEXTURE_RECTANGLE_ARB.
Sans plus attendre, voiçi un exemple complet de création d'une texture vide.

	glEnable(GL_TEXTURE_RECTANGLE_ARB);
	int taille_max;
	glGetIntegerv(GL_MAX_RECTANGLE_TEXTURE_SIZE_ARB,&taille_max);
	std::cout << " Taille max de texture supportée : " << taille_max << std::endl;
	GLuint rect_tex;
	glGenTextures(1,&amp;rect_tex);
	glBindTexture(GL_TEXTURE_RECTANGLE_ARB,rect_tex); // Exactement comme pour les tex2D
	glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGB8, 800, 600, 0, GL_RGB, GL_INT, NULL);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_EDGE);

Avant de continuer, quelques remarques nécessaires sur les NPOTS.
Il est impossible de créer des mipmaps. Ainsi, il ne faut jamais appeller glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_NEAREST); ou assimilé.
Elles ne supportent que ces modes de filtrage: GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_CLAMP_TO_BORDER.
Elles ne peuvent avoir de bordure, mais franchement, ce n'est pas bien grave.
Il y a des priorités dans les types de textures. De la moins forte à la plus forte: GL_TEXTURE_1D, GL_TEXTURE_2D, GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_3D, GL_TEXTURE_CUBE_MAP. Autrement dit: impérativement désactiver les tex3D et les cubemaps avant d'utiliser les texRect !!!
Les texRect sont répandues. Mais pour bien tester leur présence sur la CG, utiliser glGetBooleanv(GL_TEXTURE_RECTANGLE_ARB, &rect_supported);
Plus important ( vital ! )
Les coordonnées de textures ne sont pas normalisées de 0 à 1, mais de 0 à height et de 0 à width.
Pensez-y !

Enfin, c'est une très mauvaise idée d'abandonner subitement les POTS. Elles sont énormément plus rapides, et bénéficient en plus du mipmapping, le gain de vitesse est monstueux. Les NPOTS sont à réserver aux cas particuliers.

Voilà, il n'y a plus grand chose à dire pour une utilisation conventionnelle des textures rectangulaires. Mais il y a bien d'autres surprises, par exemple si vous voulez les utilisez pour les shaders.

Les Frambuffer Object

Il est IMPERATIF de tester si la carte supporte cette extension. Même si en 2011, les cartes qui ne la supportent pas sont tellement vieilles que vous feriez mieux d'abandonner tout support technique pour les dinosaures qui en auraient encore une.

Le test est relativement simple:

GLenum status;
status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);
status==GL_FRAMEBUFFER_COMPLETE_EXT?
	std::cout << "fbo supporté\n":
	std::cout << "fbo non supporté\n";

(N'oubliez pas d'initialiser glew au préalable)
Si c'est bon, on peut alors en créer un.

GLuint fbo;
glGenFramebuffersEXT(1, &fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_RECTANGLE_ARB, rect_tex, 0);

Vous remarquerez que, là encore, l'accès aux fonctionnalités d'openGL se fait via des integers, exactement de la même manière que les textures.
C'est peut-être un peu abstrait à manipuler au départ, mais je vous assure que l'on s'y fait vite.
D'ailleurs l'API elle-même est très similaire: glGenFrameBufferEXT, glBindFramebufferEXT... mis à part le Framebuffer et le EXT indiquant que cela ne fait pas partie de l'openGL de base, on ne se sent pas perdus.
La dernière ligne sert à dire que je dessinerai dans le framebuffer, ce sera en réalité dans la texture spécifiée.
Le premier paramètre est obligatoirement GL_FRAMEBUFFER_EXT, aussi stupide que cela _puisse_ paraître.
Le deuxième est GL_DEPTH_ATTACHMENT_EXT pour avoir accès au depth buffer, ou GL_COLOR_ATTACHMENT0_EXT pour la couleur normale.
le 3ème est le type de texture, GL_TEXTURE_2D ou GL_TEXTURE_RECTANGLE_ARB.
Le 4ème l'indice de la texture à utiliser.
Le dernier, enfin, détermine le niveau de mipmap dans lequel effectuer le dessin. Comme les textures rectangulaires ne permettent pas le mipmapping, ce sera forcément 0.

On va mainenant dessiner dans le fbo.

	glEnable(GL_TEXTURE_RECTANGLE_ARB);
	glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
	glDisable(GL_TEXTURE_RECTANGLE_ARB);
	glEnable(GL_TEXTURE_2D);
	// Dessin

On remarque qu'il est nécessaire que le type de texture utilisé par le fbo soit activé durant sa propre activation, mais après, on n'en a plus besoin. Il est même important de désactiver les textures rectangulaires, car sinon, comme précisé plus haut, ce paramètre aura précédence sur gl_texture_2d.

On va maintenant dessiner sur l'écran, avec notre texture toute neuve

	glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // cela dessine dans le buffer normal, c'est à dire l'écran.
	// Un dessin...
	glBindTexture(GL_TEXTURE_RECTANGLE_ARB,rect_tex);
	// un autre dessin, texturé avec cette texture-ci.
	// rappellez vous que les bornes sont [0..w] et [0..h] et non [0..1] !

Voilà ! rien de plus simple, n'est-ce pas ?
N'oubliez pas de fermer la porte en partant : glDeleteFramebuffersEXT(1, &fbo);
Nous sommes entre gentlemen, après tout.

Conclusion

Voici donc une autre méthode pour dessiner dans une texture. J'ai ai profité pour présenter ici les textures rectangulaires, car la plupart des effets nécessitant cette méthode ( ou une équivalente ) sont utilisés pour afficher cette texture en plein écran. Une POT n'est donc pas très appropriée.

• Elle est très peu connexe. Par exemple, il y a un unique lien vers la table des matières.
• Elle est peu explicite. Par exemple, dans l'interface de l'algorithme de dijkstra, on peut trouver un bgl_named_parameters. Il faut se lever de bonne heure pour trouver ce que c'est.
• Les exemples sont rares et peu explicites. Le seul exemple de l'algorithme A* est peu commenté (et encore moins aux parties les plus dures), démontre deux autres features qui n'ont rien à voir, utilise l'interface obsolète et non recommandée de la lib, et complique le tout avec une autre couche de templates totalement inutile pour un tuto qui se veut simple.

Ce tuto ci se veut simple. Il présente une des milliers de façons de procéder, que je considère comme simple, lisible et maintenable. Tous les membres du namespace boost seront préfixés par boost:: afin de savoir qu'est-ce qui est à nous et qu'est-ce qui est à Boost.

Il est basé sur le cas suivant : on a un graphe de waypoints, et on veut utiliser l'algorithme A* (qui utilise une bonne partie des concepts importants de la lib). Dans un premier temps, dans un souci de simplicité, on va utiliser une heuristique par défaut, qui rend toujours zéro. On verra par la suite comment l'adapter.

On va avoir besoin de deux headers boost:

#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/astar_search.hpp>

On va maintenant définir les structures nécessaires à définir notre graphe :

// Un waypoint
struct WayPoint{
    Vector3f pos;
    // et éventuellement d'autres informations (crouch, hide, camp, ...)
};
 
// Une liaison entre deux waypoints
struct WayPointConnection{
    float dist;
    // idem
};

On va maintenant déclarer le type de notre graphe. On va utiliser une adjacency_list, qui est un peu un graphe à tout faire. Ce n'est pas le plus optimisé dans tous les cas, mais il est très versatile et convient très bien ici.

typedef boost::adjacency_list<  // adjacency_list est un template qui dépend de :
    boost::listS,               //  le conteneur utilisé pour les arcs partant d'un sommet. Ici, std::list.
    boost::vecS,                //  le conteneur utilisé pour contenir tous les sommets du graphe. Ici, std::vector.
    boost::undirectedS,         //  le type des arcs. Pourrait être boost::directedS.
    WayPoint,                   //  le type qui décrit un sommet.
    WayPointConnection          //  le type qui décrit un arc.
> WayPointGraph;

Les deux premiers paramètres influent grandement sur l'organisation mémoire et les performances de graphe. Selon les applications, une liste, un vecteur, un set, une map, ... sera plus approprié. Pour plus d'information, voir la doc.

On déclare aussi des raccourcis pour les IDs de sommets et d'arcs (en fait, ce sont des unsigned int)

typedef WayPointGraph::vertex_descriptor WayPointID;
typedef WayPointGraph::edge_descriptor   WayPointConnectionID;

On va pouvoir instancier notre graphe.

WayPointGraph graphe;

On commence par rajouter tous les sommets :

for (tous nos sommets S){
    WayPointID wpID = boost::add_vertex(graphe); // wp est l'indice d'un nouveau sommet qui a été ajouté dans graphe
    graphe[wpID].pos = la position du sommet S    // graphe[ un WayPointID ] est un WayPoint. On peut donc régler sa position de cette manière.
}

Maintenant, on peut les relier par des arcs. Là, c'est à vous de savoir où vont les arcs, boost ne va pas le deviner tout seul...

for (tous nos sommets U){ // petit changement de notation, dans boost un arc est souvent décrit entre deux sommets u et v.
    for (tous les voisins V de U){ // C'est à vous de savoir quels sont les voisins de U.
 
        WayPointID u = indice de U; // soit c'est le int du for(), soit il faut y accéder via un autre vector. Cf les notes plus bas.
        WayPointID v = indice de V;
 
        WayPointConnectionID edge;
        bool ok;
        boost::tie(edge, ok) = boost::add_edge(u,v, graphe); // boost::add_edge renvoie une std::pai>WayPointConnectionID,bool>. C'est compliqué à écrire, alors on laisse boost::tie le faire pour nous.
 
        if (ok)  // Si le graphe a bel et bien été ajouté ( pas de doublon, par exemple, sauf si spécifié dans le typedef de WayPointGraph )
        graphe[edge].dist = Distance(graphe[u].pos, graphe[v].pos); // Longueur d'un arc = distance euclidienne entre les deux sommets u et v.
 
    }
}

Plusieurs choses sont à remarquer :

• Personnellement, j'ai utilisé le fait que WayPointID est en fait un int et que dans mon double for(), j'utilise un int pour accéder au waypoint. C'est pas très propre, mais ça évite l'utilisation d'un vector en plus.
• graphe[edge] ( edge étant un WayPointConnectionID ) est un WayPointConnection, alors que graphe[u] (u étant un WaypointID) est un WayPoint. On peut donc accéder directement à leurs membres.
• Cette dernière remarque est très importante. Cette syntaxe est très appréciable, elle évite d'utiliser les incompréhensibles boost::property_map, elle oblige seulement à avoir un compilateur récent. GCC et Visual s'en sortent très bien.

Pour information, mon code à moi ressemble à ça :

for (int i=0; i<indices.size()/3; i++){
    ConnectiviteTriangle connectivity;
    fillconnectivityinfo(i, connectivity, indices);
    for (int c=0; c!=3; c++){
        if (connectivity.connexe[c]!=-1){
        TriangleDescriptor u = i;
        TriangleDescriptor v = connectivity.connexe[c];

La syntaxe est moyennement cool, mais j'espère que ça vous aidera à mieux comprendre.

Ok, donc maintenant notre graphe a des sommets et des arcs. On va pouvoir faire du pathfinding !

Pour ça, on va avoir besoin de quelques structures :

// Une instance de cette structure sera lancée en exception quand on aura trouvé un chemin
struct found_goal {};
 
// Le visiteur, dont le but est de définir une fonction examine_vertex qui dit si on est arrivé au but.
// Le but est spécifié via le constructeur.
class astar_goal_visitor : public boost::default_astar_visitor{
public:
    astar_goal_visitor(WayPointID goal) : m_goal(goal) {}
 
    void examine_vertex(WayPointID u, const Graph & g){ // Le const est important.
        if(u == m_goal)
            throw found_goal(); // On sort en lancant une exception. C'est moche mais c'est comme ça.
        }
private:
    WayPointID m_goal;
};

Il faut maintenant trouver notre point de départ et notre point d'arrivée. C'est votre problème, mais il faut arriver à quelque chose du style :

TriangleDescriptor goal = ...
TriangleDescriptor start = ...

Ok, on y va :

// Deux vecteurs qui vont servir à sauvegarder le résultat de la recherche
vector<WayPointID> p(boost::num_vertices(graphe)); // Les prédécesseurs
vector<float>      d(boost::num_vertices(graphe)); // Les distances
 
try { // Encore une fois, la découverte d'un chemin est signalée par une exception, donc il faut un try/catch.
    boost::astar_search
    (
        graphe, // notre graphe
        start,  // notre point de départ
        boost::astar_heuristic<NavMeshGraph, float>(), // Une heuristique bidon qui renvoie toujours 0
        boost::predecessor_map(&p[0]).distance_map(&d[0]).visitor(astar_goal_visitor(goal)).weight_map(boost::get(&WayPointConnection::dist, graphe)) // Voir plus bas
    );
 
} catch(found_goal fg) { // On a trouvé un chemin
    // On suit le chemin trouvé dans le sens inverse
    std::list<WayPointID> shortest_path;
    for(WayPointID v = goal;; v = p[v]) {
        shortest_path.push_front(v);
        if(p[v] == v)
            break;
    }
 
    // et on l'affiche.
    std::list<WayPointID>::iterator spi = shortest_path.begin();
    for(++spi; spi != shortest_path.end(); ++spi)
        Log(*spi);
    Log("Total travel time: " , d[goal] );
}

Remarque sur la ligne bizarre:

- Ce ne sont pas des virgules, ce sont des points ! Il s'agit d'un seul objet auquel on rajoute plein de propriétés. Cette syntaxe est par exemple utilisée dans la création d'interfaces graphiques : monmenu.addoption("option1").addoption("option2") etc
- A* a besoin de ces quatre propriétés : une map de prédécesseurs, une map de distances, une map de poids, et un visiteur.
- La map de poids est intrisèque au graphe : elle est stockée dans le champ dist des arcs. Mais Boost ne peut pas deviner tout seul que c'est cette variable qu'il faut lire, donc on le lui dit avec boost::get(&WayPointConnection::dist, graphe)
• Le visiteur est initialisé avec le goal pour pouvoir lancer son exception si il y a réussite.

Vous avez économisé 4 heures de prise de tête avec la doc de BGL, autant d'implémentation de l'A* si vous l'aviez codé vous même, et autant de débug que vous n'aurez jamais à faire : un des grands intérêts des templates, c'est que comme en OCaml, quand ça compile, ça marche (souvent) ^^.

Voyons maintenant comment améliorer un peu notre heuristique : pour l'instant, on n'a fait qu'un parcours brutal de l'arbre, ça ne valait pas trop le coup.
Cela va bien sûr passer par une nouvelle structure :

class distance_heuristic : public boost::astar_heuristic <WayPointGraph, float>{
public:
    // De la même manière que tout à l'heure, on passe les données dont il aura besoin dans son foncteur à la construction.
    distance_heuristic(const WayPointGraph & l, WayPointID goal)
    : m_graph(l), m_goal(goal) {}
 
    float operator()(WayPointID u)
    {
        const WayPoint & U = m_graph[u];
        const WayPoint & V = m_graph[m_goal];
        float dx = U.pos.x - V.pos.x;
        float dy = U.pos.y - V.pos.y;
        return sqrt(dx * dx + dy * dy);
    }
private:
    const WayPointGraph & m_graph;
    TriangleDescriptor m_goal;
}

m_graph peut être remplacé ( en changeant le constructeur et l'opérateur ) par n'importe quoi qui vous permette d'obtenir la position d'un vertex à partir de son identifiant. Cela peut être comme ici le graphe lui-même, mais aussi les données à partir duquel il a été construit, etc.

Il suffit maintenant de remplacer boost::astar_heuristic() par distance_heuristic(graphe, goal) dans l'appel au A*.

Oh, et au fait : les waypoints ça pue, utilisez des navmeshes.

Discussion sur le forum

L'autre nuit, muni de café, j'ai souhaité m'amuser avec Haskell. J'ai alors consulté le chapitre sur le réseau en Haskell de Real World Haskell et... j'ai écrit un (très petit) clône de client telnet... qui fait 41 lignes. Le seul soucis étant que dans toute application de ce genre, on doit partager habilement la lecture des entrées de l'utilisateur, et l'affichage de ce que l'on nous envoie. Ceci mis à part, tout cela fonctionne très bien !

Regardons à quoi cela ressemble. Petit détail : à chaque tour, je lance la réception de données réseau dans un autre thread, pour ne pas bloquer l'écriture de l'utilisateur.

On importe d'abord les modules nécessaires.

import Control.Concurrent 
import Control.Monad 
import Network.Socket 
import Network.BSD 
import System.Environment 
import System.IO

Ensuite, j'ai écrit quelques fonctions pour rendre la connection, l'envoi etc plus faciles.

-- Ouverture d'une connexion TCP cliente 
-- Prend en argument l'host et le port/service (qui est une String également) 
-- Retourne le "Handle" vers le socket en question. 
openConnection :: String -> ServiceName -> IO Handle 
openConnection hostname port = 
  do 
  addrInfos <- getAddrInfo Nothing (Just hostname) (Just port) 
  let serveraddr = head addrInfos 
  sock <- socket (addrFamily serveraddr) Stream defaultProtocol 
  setSocketOption sock KeepAlive 1 
  connect sock (addrAddress serveraddr) 
  h <- socketToHandle sock ReadWriteMode 
  hSetBuffering h (BlockBuffering Nothing) 
  return h 
 
-- Ferme la connexion dont le Handle est donné 
closeConnection :: Handle -> IO () 
closeConnection h = hClose h 
 
-- Envoie la chaîne donnée sur le Handle donné, et ensuite fait un flush sur ce handle, ce qui force l'envoi immédiat et nettoie les états 
sendMsg :: Handle -> String -> IO () 
sendMsg h msg = hPutStrLn h msg >> hFlush h 
 
-- Lis sur le Handle donné une chaîne et la renvoie (dans la monade IO) 
recvMsg :: Handle -> IO String 
recvMsg h = do 
  msg <- hGetContents h  
  return msg

Voyons maintenant la fonction main.

main = do 
  args <- getArgs 
  let (host, port) = (args !! 0, args !! 1)

On récupère les arguments donnés au programme (s'il n'y en a pas assez, cela fera planter le logiciel -- je ne me suis pas vraiment préoccupé de tous les cas d'erreur, mais ce n'était pas ma priorité ici) via la fonction getArgs, et l'on en récupère l'host et le port donnés.

  putStrLn $ "Opening client on " ++ host ++ ":" ++ port ++ "\n" 
  hclient <- openConnection host port 
  putStrLn "Client connected"

Ca y est, on se connecte, en affichant des messages pour tenir l'utilisateur informé. Si la connection échoue, le programme s'arrêtera avec une erreur -- cf remarque ci-dessus.

Et maintenant, la boucle qui permet de lire depuis le réseau et lire depuis l'utilisateur, etc.

  forever $ do 
    getLine >>= sendMsg hclient 
    forkIO $ recvMsg hclient >>= putStrLn

Ici, on a une sorte de boucle "à la while(true)", dans laquelle on va tour à tour récupérer une entrée de l'utilisateur et l'envoyer au serveur, puis, dans un thread séparé, récupérer ce qu'a envoyé le serveur et l'afficher.
Enfin, on ferme la connection (ce code est inutile tant que l'on a pas de possibilité de sortir du forever... qui devra tôt ou tard se transformer en "until" ou autre).

  closeConnection hclient

Voilà le code complet :

import Control.Concurrent 
import Control.Monad 
import Network.Socket 
import Network.BSD 
import System.Environment 
import System.IO 
 
openConnection :: String -> ServiceName -> IO Handle 
openConnection hostname port = do 
  addrInfos <- getAddrInfo Nothing (Just hostname) (Just port) 
  let serveraddr = head addrInfos 
  sock <- socket (addrFamily serveraddr) Stream defaultProtocol 
  setSocketOption sock KeepAlive 1 
  connect sock (addrAddress serveraddr) 
  h <- socketToHandle sock ReadWriteMode 
  hSetBuffering h (BlockBuffering Nothing) 
  return h 
 
closeConnection :: Handle -> IO () 
closeConnection h = hClose h 
 
sendMsg :: Handle -> String -> IO () 
sendMsg h msg = hPutStrLn h msg >> hFlush h 
 
recvMsg :: Handle -> IO String 
recvMsg h = do 
  msg <- hGetContents h  
  return msg 
 
main = do 
  args <- getArgs 
  let (host, port) = (args !! 0, args !! 1) 
  putStrLn $ "Opening client on " ++ host ++ ":" ++ port ++ "\n" 
  hclient <- openConnection host port 
  putStrLn "Client connected" 
  forever $ do 
    getLine >>= sendMsg hclient 
    forkIO $ recvMsg hclient >>= putStrLn 
  closeConnection hclient

Compilation :

ghc --make -o net net.hs

Puis 2 exemples d'exécution...

$ ./net google.fr 80
Opening client on google.fr:80
Client connected
GET / HTTP/1.0
HTTP/1.0 302 Found
Location: http://www.google.fr/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=30b094ad566b5532:TM=1251456529:LM=1251456529:S=94IXp5-SGiaYADWc; expires=Sun, 28-Aug-2011 10:48:49 GMT; path=/; domain=.google.com
Date: Fri, 28 Aug 2009 10:48:49 GMT
Server: gws
Content-Length: 218 



302 Moved
The document has moved
here.
 

^C

(c'est moi qui ai tapé "GET / HTTP/1.0")
( qui vous dira que la page a été déplacée )

Et enfin, la surprise...

$ ./net towel.blinkenlights.nl 23

Qui, une version simplifiée d'un film très connu, vous permettra de voir, Jedi.

Enjoy !

Au détour d'une naviguation web fortuite mais bienheureuse, je suis tombé sur CipherSaber. Vous savez, c'est ce genre de moment où on tombe sur une initiative sympa, facile à suivre et qui fait sens. Bref, j'ai accroché tout de suite, alors j'ai laissé tomber ce que j'étais en train de faire et y ai consacré mes heures suivantes.
CipherSaber, c'est la reprise du concept selon lequel il faut en savoir faire un minimum, tout seul, comme un grand. A l'instar des Jedis dans l'univers Star Wars qui vont réaliser eux-même leur sabre laser (vous comprenez maintenant le nom du projet), on nous propose de réaliser nous-même notre petit logiciel de chiffrement. Je vous laisse parcourir le site pour une explication plus en détail de la philosophie derrière ce petit combat pour la cryptographie, mais l'idée est là : A n'importe quel moment, nous devrions être capable de produire un logiciel de chiffrement suffisamment solide pour être utilisé sans risque, afin de s'affranchir des éventuelles lois contre l'exportation et garantir notre liberté de parole, autant que faire se peut. Joli programme !
Voici les instructions que l'on nous fournit pour réaliser cet outil (directement traduites depuis le lien du début de l'article) :

1. Utiliser l'algorithme de chiffrement ARCFOUR (ou RC4), tel que décrit par exemple ici.
2. Chaque fichier chiffré se compose d'un Vecteur d'Initialisation (IV) de 10 octets, puis du contenu chiffré. Un nouveau vecteur aléatoire devra être généré à chaque chiffrement de fichier.
3. La clé de chiffrement se compose elle de la clé que l'utilisateur nous fournit suivie de ce même Vecteur d'Initialisation.

Et effectivement, ce sont les seules indications dont nous aurons besoin. Une fois le programme réalisé, nous aurons la possibilité de déchiffrer un certificat en gif, preuve de notre petite réussite. Si l'idée vous plait et que vous souhaitez vous contenter de ces informations pour vous-même construire votre CipherSaber, alors ne revenez lire la suite de cet article que quand vous aurez votre certificat !

ARCFOUR ?

ARCFOUR, c'est l'algorithme libre identique au RC4 qui lui est une propriété de RSA Security. Ici, pas de clé publique/privée, pas d'algorithme alambiqué, mais une solution implémentable "de tête", pour peu qu'on fasse l'effort de la comprendre et d'en retenir les fondements.

Bon, ok, c'est gentil, mais le ARCFOUR moi, je ne le connais pas. Qu'à cela ne tienne, il suffira de suivre le lien donné ou de rechercher RC4 sur le web pour que l'algorithme nous tombe tout cru, ou presque. Mais j'insiste, le but ici est de pouvoir à tout moment réécrire ce logiciel de mémoire, donc on apportera un soin tout particulier à en retenir les principes de fonctionnement.

C'est un algorithme de chiffrement à flot, il repose sur deux phases :

1. A partir de la clé K que nous donne l'utilisateur, on va générer un tableau d'état S que l'on va mélanger de nombreuses fois afin d'obtenir une suite de chiffres pseudo-aléatoires.
2. On va ensuite chiffrer le contenu sensible par un simple XOR entre ses octets et ceux du tableau d'état. Si c'est votre tout premier pas dans le monde de la cryptographie, sachez que l'opération XOR est "réversible" (il y a sûrement un terme mathématique approprié à cette propriété, pardon à eux pour mon ignorance), c'est à dire que si A xor B = C, alors A xor C = B. On utilise donc exactement la même procédure et la même clé pour chiffrer et déchiffrer.

Maintenant qu'on saisit la généralité de la méthode, voyons comment la réaliser plus en détail :

1. Créons notre tableau d'état :
   1. Soit la clé K d'une taille de 256 octets (si elle fait moins, on la répète à la suite jusqu'à obtenir 256 octets pile)
   2. Construisons un tableau S de 256 valeurs, chacune contenant son index basé à 0 : S[0] = 0, S[255]=255.
   3. Mélangeons S, avec i allant de 0 à 255 et j démarrant à 0:
      1. Inverser l'élément i de S avec celui de rang (S[i]+K[i])+j, j étant le rang du "mélangé" précédent. Autrement dit, ajouter S[i]+K[i] à j et inverser S[i] et S[j]
2. Chiffrons :
   1. Boucler sur chaque octet du fichier à chiffrer, et avec i et j démarrant à 0 :
      1. incrémenter i
      2. Un peu comme précédemment, inverser l'élément i de S avec celui de rang (S[i]+j), j étant le rang du mélangé précédent. Autrement dit, ajouter S[i] à j et inverser S[i] et S[j]
      3. Combiner l'octet à chiffrer avec la valeur de l'élément S[i]+S[j] par un XOR.

J'ai conscience que ce n'est sûrement pas clair au premier abord, mais j'ai essayé ici de résumer l'algorithme par ses opérations logiques, afin que ce soit appréhendable pour l'esprit et donc plus aisé à retenir. Pour une version plus proche de l'implémentation, il vous reste votre moteur de recherche préféré. Retenez par contre un détail important : Chaque éléments de chaque tableau est un octet, il en va de même pour i et j. Par conséquent, chaque addition se fait modulo 256.

Une fois votre implémentation écrite, n'hésitez pas à la tester. Un petit chiffrement/dechiffrement pour s'assurer que tout va bien ne sera pas de trop, croyez-moi.

IVs et tests

Maintenant que votre ARC4 est implémenté et testé, reste à en faire quelque chose. Oui car utilisé tel quel, c'est un algorithme tout à fait prévisible, or nous recherchons un chiffrement suffisament fort. La règle qui semble être celle de base, c'est qu'un même chiffrement appliqué à un même fichier ne doit pas donner le même résultat. L'idée est donc d'ajouter un IV, l'Initialisation Vector dont on parlait plus haut. Ainsi, lors du chiffrement, on va générer un IV aléatoire de 10 octets, qu'on va :

• Mettre à la suite de la clé que nous a fourni l'utilisateur pour produire une clé unique à fournir à l'argorithme de chiffrement
• Ajouter en clair au début du fichier crypté, afin quand même que l'on puisse connaitre la clé à utiliser pour déchiffrer.

L'IV est donc une donnée "publique" puisqu'en clair, mais cela suffit à notre besoin de non-répétition. Par contre son choix est important, crucial même, alors attention à la méthode de génération pseudo aléatoire que vous allez utiliser.

Et voilà ! Une fois ce dernier détail implémenté, il ne vous reste plus qu'à tester votre programme sur les fichiers chiffrés fournis sur le site. Si vos tests ne fonctionnent pas, vous trouverez dans la FAQ quelques points à vérifier dans votre code pour trouver le bug. Voici ceux qui m'ont servi :

• Si vous programmez en C/C++, ouvrez vos fichiers en binaire... On aurait tendance à l'oublier.
• Double, triple-vérifiez vos index et les combinaisons de tailles, ajout, suppression, décalages.

Aller un peu plus loin

Ainsi que vous avez peut-être lu quelque part, certaines faiblesses ont été décelées dans l'ARC4. Elles sont notamment à la base des attaques contre le protocole WEP maintenant si rapides qu'on peut faire tomber un réseau Wifi en 15 minutes. L'auteur recommande donc de passer à... CipherSaber 2 ! <Musique épique, et là avouez, ça picote !>

En fait ce n'est qu'une petite évolution de votre programme actuel : le moyen le plus simple de sécuriser son CipherSaber est de démultiplier le nombre de mélanges de S. Ainsi, à l'étape 3 de la création de notre tableau d'état décrite ci-dessus, on va non pas effectuer ce mélange complet de S une fois mais N fois, N étant une donnée qu'il faudra bien évidemment connaitre lors du déchiffrement. Pour être tranquille, utilisez un N de 15 ou 20.

Aller vraiment au bout de son sabre

Mais toute bonne votre méthode de chiffrement soit-elle, si vous utilisez une passphrase de 3 lettres ou votre date d'anniversaire, tout cela n'aura servi à rien. Ce n'est pas le but de l'article que de décrire un moyen efficace d'en générer une, mais sachez qu'il existe des méthodes comme celle décrite sur Diceware (c'est depuis ce site que j'ai découvert CipherSabre, ce n'est donc pas par hasard que je met ce lien ici). Retenez tout de même qu'un mot de passe n'est pas une.. hm, et bien phrase de passe. Le premier est adapté à un contexte local, lorsque vous avez besoin d'un mot court à entropie forte. La passphrase, de ce que j'en comprend, permet de s'affranchir plus ou moins du coté "impossible à retenir" d'un vrai de mot de passe fort, en augmentant la taille de la clé à 15 ou 20 caractères avec des mots courants, tout en fournissant pour peu qu'elle soit bien choisie (aléatoire) un entropie plus que satisfaisante.

Et alors ?

Et bien voilà, maintenant vous savez écrire un logiciel de chiffrement. Gardez bien-sûr conscience qu'il ne remplacera jamais une vraie solution comme OpenPGP, qui malgré sa puissance est deja suffisament mal diffusée pour qu'on n'en rajoute pas à vouloir utiliser notre solution personnelle moins pratique et moins sûre. Mais enfin, à votre niveau vous savez reproduire tout seul un outil basique mais potentiellement utile en situation réelle, vous avez limité votre dépendance à ceux qui savent, ceux qui dirigent, ceux en qui on vous demande d'avoir une confiance presque aveugle. Et enfin, vous en aurez un peu appris sur les fondements de la cryptographie, peut-être plus qu'en jouant avec AirCrack sur votre propre réseau ou celui du voisin...

Cela fait quelques temps maintenant que la communauté Haskell a sorti Haskell Platform. Il s'agit d'un "paquet" qui regroupe :
- le compilateur haskell GHC, un debugger, un profiler, etc
- les bibliothèques les plus populaires et les plus utilisées, fournies d'office
- tout un tas d'outils auxiliaires, comme haddock, qui permet de générer de la documentation depuis les commentaires du code source.

Il existe des paquets pour déjà quelques distributions Linux, sachant que ce sera bientôt prêt pour Debian et Ubuntu également. Les installeurs Windows et Mac sont très simples également.

Bref, plus aucune raison de ne pas essayer Haskell

Pour rappel, nous en sommes restés à un système de macro qui permettait d'automatiser la création
d'un opérateur "<<" pour iostream, capable d'afficher le nom d'une énumération.

Voici le code :

// Enumerate.h
 
#ifndef ENUMERATE_H
#define ENUMERATE_H
 
#define MAKE_ENUM(enum_name, ...)	\
	enum enum_name { __VA_ARGS__ };
 
#define ENUM_CASE_1(val)	\
	case val:	\
		os << #val;	\
		break;
 
#define ENUM_CASE_2(val, ...)	ENUM_CASE_1(val) ENUM_CASE_1(__VA_ARGS__)
#define ENUM_CASE_3(val, ...)	ENUM_CASE_1(val) ENUM_CASE_2(__VA_ARGS__)
#define ENUM_CASE_4(val, ...)	ENUM_CASE_1(val) ENUM_CASE_3(__VA_ARGS__)
#define ENUM_CASE_5(val, ...)	ENUM_CASE_1(val) ENUM_CASE_4(__VA_ARGS__)
#define ENUM_CASE_6(val, ...)	ENUM_CASE_1(val) ENUM_CASE_5(__VA_ARGS__)
#define ENUM_CASE_7(val, ...)	ENUM_CASE_1(val) ENUM_CASE_6(__VA_ARGS__)
#define ENUM_CASE_8(val, ...)	ENUM_CASE_1(val) ENUM_CASE_7(__VA_ARGS__)
#define ENUM_CASE_9(val, ...)	ENUM_CASE_1(val) ENUM_CASE_8(__VA_ARGS__)
#define ENUM_CASE_10(val, ...)	ENUM_CASE_1(val) ENUM_CASE_9(__VA_ARGS__)
 
#define ENUM_CASE_N(nb_vals, ...) ENUM_CASE_ ## nb_vals(__VA_ARGS__)
 
#define MAKE_OPERATOR(nb_vals, enum_name, ...)	\
	inline std::ostream& operator<<(std::ostream& os, const enum_name& e)	{\
		switch(e) {	\
			ENUM_CASE_N(nb_vals, __VA_ARGS__)	\
		}	\
		return os;	\
	}
 
 
#define ENUMERATE(nb_vals, enum_name, ...)	\
	MAKE_ENUM(enum_name, __VA_ARGS__)	\
	MAKE_OPERATOR(nb_vals, enum_name, __VA_ARGS__)
 
#endif // ENUMERATE_H

// main.cpp
 
#include <iostream>
#include "Enumerate.h"
 
ENUMERATE(3, MonEnumeration,
	E_VAL_1,
	E_VAL_2,
	E_VAL_3);
 
int main()
{
	MonEnumeration e = E_VAL_1;
	std::cout << e << std::endl;
	return 0;
}

Le plus gros problème de ce système est le fait que l'on soit obligés de donner le nombre de valeurs de l'énumération
lors de l'utilisation de la macro ENUMERATE.

Ce qui nous oblige à spécifier ce numéro, c'est la nécessiter de "choisir" la bonne macro parmi ENUM_CASE_1, ENUM_CASE_2, ..., ENUM_CASE_10.

Se passer de ce nombre, c'est effectuer l' "appel récursif" jusqu'à ce qu'il n'y ait plus d'argument à traiter dans la
"liste" __VA_ARGS__.

Que se passe-t-il si l'on supprime ce nombre et que l'on remplace l'appel à ENUM_CASE_N par la version qui gère le plus d'arguments
(ici ENUM_CASE_10, donc) ?

Version remaniée :

// Enumerate.h
 
#ifndef ENUMERATE_H
#define ENUMERATE_H
 
#define MAKE_ENUM(enum_name, ...)	\
	enum enum_name { __VA_ARGS__ };
 
#define ENUM_CASE_1(val)	\
	case val:	\
		os << #val;	\
		break;
 
#define ENUM_CASE_2(val, ...)	ENUM_CASE_1(val) ENUM_CASE_1(__VA_ARGS__)
#define ENUM_CASE_3(val, ...)	ENUM_CASE_1(val) ENUM_CASE_2(__VA_ARGS__)
#define ENUM_CASE_4(val, ...)	ENUM_CASE_1(val) ENUM_CASE_3(__VA_ARGS__)
#define ENUM_CASE_5(val, ...)	ENUM_CASE_1(val) ENUM_CASE_4(__VA_ARGS__)
#define ENUM_CASE_6(val, ...)	ENUM_CASE_1(val) ENUM_CASE_5(__VA_ARGS__)
#define ENUM_CASE_7(val, ...)	ENUM_CASE_1(val) ENUM_CASE_6(__VA_ARGS__)
#define ENUM_CASE_8(val, ...)	ENUM_CASE_1(val) ENUM_CASE_7(__VA_ARGS__)
#define ENUM_CASE_9(val, ...)	ENUM_CASE_1(val) ENUM_CASE_8(__VA_ARGS__)
#define ENUM_CASE_10(val, ...)	ENUM_CASE_1(val) ENUM_CASE_9(__VA_ARGS__)
 
#define MAKE_OPERATOR(enum_name, ...)	\
	inline std::ostream& operator<<(std::ostream& os, const enum_name& e)	{\
		switch(e) {	\
			ENUM_CASE_10(__VA_ARGS__)	\
		}	\
		return os;	\
	}
 
 
#define ENUMERATE(enum_name, ...)	\
	MAKE_ENUM(enum_name, __VA_ARGS__)	\
	MAKE_OPERATOR(enum_name, __VA_ARGS__)
 
#endif // ENUMERATE_H

// test.cpp
 
#include "Enumerate.h"
 
ENUMERATE(MonEnumeration,
	E_VAL_1,
	E_VAL_2,
	E_VAL_3);

Après un appel au préprocesseur par "cpp test.cpp", voici ce qu'il nous affiche (remis en forme pour être lisible et
en enlevant les lignes commençant par un #, sans importance) :

enum MonEnumeration { E_VAL_1, E_VAL_2, E_VAL_3 };
 
inline std::ostream& operator<<(std::ostream& os, const MonEnumeration& e)
{
	switch(e)
	{
	case E_VAL_1: os << "E_VAL_1"; break;
	case E_VAL_2: os << "E_VAL_2"; break;
	case E_VAL_3: os << "E_VAL_3"; break;
	case : os << ""; break;
	case : os << ""; break;
	case : os << ""; break;
	case : os << ""; break;
	case : os << ""; break;
	case : os << ""; break;
	case : os << ""; break;
	}
	return os;
};

Vous voyez le problème : on a des "case :" à partir du stade où il n'y a plus d'argument. Il faut donc remplacer
chaque ligne "case ..." (correspondant à ce que génère ENUM_CASE_1) par quelque chose qui puisse faire un test d'égalité
entre "e" et "E_VAL_1", "E_VAL_2"...etc, mais qui puisse aussi compiler et ne rien faire lorsqu'en lieu et place
de "E_VAL_XXX", il n'y a rien.

Là, on pense à la surcharge de fonction ! En effet, si l'on a une fonction surchargée ainsi :

void f(int i)
{
	// blabla
}
 
void f()
{
	// blublu
}

on peut obtenir un comportement différent selon que l'on passe ou pas quelque chose en argument à la fonction !
Il suffirait de remplacer chaque ligne "case ..." par un test d'égalité qui aurait cette forme :

if(TestEgalite(e, E_VAL_1)) {os << "E_VAL_1"; return os;}

et le tour est joué !

Mais attendez, vous ne voyez pas un problème ? Si, si : contrairement à la fonction f() de l'exemple, ce "TestEgalite"
a 2 arguments. Si l'on remplace "E_VAL_1" par du vide, on obtient un "if(TestEgalite(e, )) {blabla;}" : ça ne marche pas !

Le problème reste donc entier...
Oui, pour ceux qui se demandent, cette partie de l'article n'apporte rien à la solution, c'est juste la démarche que j'ai
eue : vous pouvez vous dire que ça ne sert à rien, je ne vous le reprocherai pas, mais maintenant c'est trop tard, vous
l'avez lu :p

On pourrait se poser le problème ainsi : comment, à partir d'une fonction à 2 arguments, en faire 2 fonctions à 1 argument ?
En effet, si l'on arrive à en faire 2 fonctions à 1 argument, alors le problème serait réglé Si je ne m'abuse, il
s'agit de la "curryfication", que l'on trouve en programmation fonctionnelle et en lambda-calcul

Peut-être est-ce possible, je n'ai pas exploré cette possibilité. Il ne m'étonnerait pas que cela soit possible grâce à des
foncteurs, i.e. une classe dont un surcharge l'opérateur "()". On peut ainsi se retrouver avec une construction de la forme
"MaClasse(arg1)(arg2)", i.e. un appel au constructeur suivi d'un appel à l'opérateur "()".

En fait, à mon avis, c'est une solution possible, je garderai peut-être pour la suite, dans un hypothétique futur article

Quoi qu'il en soit, pour en revenir au problème : on peut aussi se le poser ainsi : est-on obligés de traiter les cas où
le préprocesseur ne met rien, en lieu et place de nos "E_VAL_1", "E_VAL_2"...etc ? Dit encore autrement, ne peut-on pas mettre
quelque chose d'autre à la place ? Qu'est-ce qui nous arrangerait alors ?

Hmm, voyons voir, remplacer le vide par quelque chose que l'on pourrait tester lors de la compilation...
Il s'agit bien de méta-programmation. Or, en méta-programmation : les 2 outils principaux que le C++ met à notre disposition
sont les macros et les templates.

Eurêka !

On peut "surcharger" une fonction template qui s'occupera de faire le test d'égalité !
On écrit alors les tests d'égalité comme ceci :

if(TestEgalite<E_VAL_1>(e)) {blabla;}
if(TestEgalite<E_VAL_2>(e)) {blabla;}
...
if(TestEgalite<void>(e)) {blabla;}

On déclare alors TestEgalite sous cette forme :

template <MonEnumeration val>
inline bool TestEgalite(const EnumType& e)
{
	return e == val;
}
 
template <class T>
inline bool TestEgalite(const EnumType& e)
{
	return false;
}

Et le tour est joué !

Bon, maintenant, pour faire plus pro, en renommant ça en anglais et en préfixant par le nom de l'énumération
(histoire que l'on n'ait pas de conflit s'il y a 2 énumérations différentes, au cas où), et en remettant tout
ensemble, cela donne ceci :

Version finale :

// Enumerate.h
 
#ifndef ENUMERATE_H
#define ENUMERATE_H
 
#define MAKE_ENUM(EnumType, ...)	\
	enum EnumType { __VA_ARGS__ };
 
#define ENUM_CASE_1(EnumType, val, ...)	\
	if(EnumType ## _EnumIsEqual<val>(e)) {os << #val; break;}
 
#define ENUM_CASE_2(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_1(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_3(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_2(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_4(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_3(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_5(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_4(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_6(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_5(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_7(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_6(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_8(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_7(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_9(EnumType, val, ...)		ENUM_CASE_1(EnumType, val) ENUM_CASE_8(EnumType, __VA_ARGS__, void)
#define ENUM_CASE_10(EnumType, val, ...)	ENUM_CASE_1(EnumType, val) ENUM_CASE_9(EnumType, __VA_ARGS__, void)
 
#define MAKE_OPERATOR(EnumType, ...)	\
	template <EnumType val>				\
	inline bool EnumType ## _EnumIsEqual(const EnumType& e) {	\
		return e == val;										\
	}															\
																\
	template <class T>											\
	inline bool EnumType ## _EnumIsEqual(const EnumType& e) {	\
		return false;											\
	}															\
																\
	inline std::ostream& operator<<(std::ostream& os, const EnumType& e) {	\
		do {																\
			ENUM_CASE_10(EnumType, __VA_ARGS__, void)								\
		} while(0);											\
		return os;											\
	}
 
#define ENUMERATE(EnumType, ...)		\
	MAKE_ENUM(EnumType, __VA_ARGS__)	\
	MAKE_OPERATOR(EnumType, __VA_ARGS__)
 
#endif // ENUMERATE_H

// main.cpp
 
#include <iostream>
#include "Enumerate.h"
 
ENUMERATE(MonEnumeration,
	E_VAL_1,
	E_VAL_2,
	E_VAL_3);
 
int main()
{
	MonEnumeration e = E_VAL_1;
	std::cout << e << std::endl;
	return 0;
}

Voilà pour cette partie

Ceci dit, un problème est résolu, mais il en reste d'autres, notamment :
- ça doit toujours aussi mal passer auprès des systèmes d'auto-complétion (enfin, j'ai pas testé sur Visual Assist
ou Eclipse à vrai dire...)
- on ne peut toujours pas attribuer de valeur numérique manuellement à un symbole de l'énumération

Il pourrait aussi être intéressant d'associer une autre chaîne de caractères, voire toute autre valeur, à un symbole de
l'énumération...
Tout comme il serait intéressant d'explorer une solution à base de pseudo-curryfication plutôt que de templates, voire, qui
sait, une solution entièrement à base de templates. A ce sujet, un article très intéressant est disponible ici pour les
curieux : http://www.codeguru.com/cpp/cpp/cpp_mfc/templates/article.php/c4137

Ce sera tout pour cette fois !

-------------
EDIT

Petite édition du post original : un pote m'a proposé une petite amélioration du code original (Jérémie, si tu me lis ^^), qui rend le code plus clair et évite de passer par les templates.

L'idée est dans l'opérateur "<<" de créer un objet wrapper autour de ma valeur d'énumération, muni de fonctions de test d'égalité surchargées afin d'accepter un ou zéro argument.
Grâce à cette surcharge, on peut ainsi éviter de traîner les "void" utilisés en paramètres des templates, ce qui est quand même plus propre, et qui encore une fois si le compilateur optimise bien, ne devrait pas créer de différence

Trève de discours, voici la version finale du code :

// Enumerate.h
 
#ifndef ENUMERATE_H
#define ENUMERATE_H
 
#define MAKE_ENUM(enum_name, ...)	\
	enum enum_name { __VA_ARGS__ };
 
#define ENUM_CASE_1(val)	\
	if(s.isEqual(val))		\
		os << #val;
 
#define ENUM_CASE_2(val, ...)	ENUM_CASE_1(val) ENUM_CASE_1(__VA_ARGS__)
#define ENUM_CASE_3(val, ...)	ENUM_CASE_1(val) ENUM_CASE_2(__VA_ARGS__)
#define ENUM_CASE_4(val, ...)	ENUM_CASE_1(val) ENUM_CASE_3(__VA_ARGS__)
#define ENUM_CASE_5(val, ...)	ENUM_CASE_1(val) ENUM_CASE_4(__VA_ARGS__)
#define ENUM_CASE_6(val, ...)	ENUM_CASE_1(val) ENUM_CASE_5(__VA_ARGS__)
#define ENUM_CASE_7(val, ...)	ENUM_CASE_1(val) ENUM_CASE_6(__VA_ARGS__)
#define ENUM_CASE_8(val, ...)	ENUM_CASE_1(val) ENUM_CASE_7(__VA_ARGS__)
#define ENUM_CASE_9(val, ...)	ENUM_CASE_1(val) ENUM_CASE_8(__VA_ARGS__)
#define ENUM_CASE_10(val, ...)	ENUM_CASE_1(val) ENUM_CASE_9(__VA_ARGS__)
 
#define MAKE_OPERATOR(enum_name, ...)	\
	inline std::ostream& operator<<(std::ostream& os, const enum_name& e)	{\
		struct {							\
			enum_name e;					\
			inline bool isEqual(enum_name val) const {return e == val;}	\
			inline bool isEqual() const {return false;}					\
		} s;														\
		s.e = e;			\
		ENUM_CASE_10(__VA_ARGS__)	\
		return os;	\
	}
 
 
#define ENUMERATE(enum_name, ...)	\
	MAKE_ENUM(enum_name, __VA_ARGS__)	\
	MAKE_OPERATOR(enum_name, __VA_ARGS__)
 
#endif // ENUMERATE_H

Et voilà !

Du 17 au 19 avril 2009, a eu lieu la finale de Cod'INSA, un concours de programmation inter-INSA,
qui s'est déroulée à l'INSA de Toulouse (plus d'infos sur http://codinsa.insa-lyon.fr pour les intéressés).
Faisant partie des organisateurs, j'ai eu à faire l'interfaçage C++/Java (oui parce qu'il y en a qui veulent
participer en Java...allez comprendre :p [/troll]). J'y ai découvert les joies de GCJ et de CNI, ce qui
pourra peut-être être l'objet d'un autre article, selon ma motivation...

Bref, tout ça pour dire qu'il m'a fallu interfacer une librairie écrite en C avec du Java, et qu'il a fallu
automatiser un peu le boulot pour la partie concernant les énumérations.

Dans cet article, je vais illustrer une méthode pour faciliter l'affichage des valeurs des énumérations.
En gros, le but, c'est que si l'on a :

MonEnumeration e = E_VAL_1;
std::cout << e << std::endl;

il s'affiche alors à l'écran "E_VAL_1".

La version non automatisée consiste en l'écriture d'une surcharge de l'opérateur "<<". Programme de démonstration :

#include <iostream>
#include "Enumerate.h"
 
enum MonEnumeration
{
	E_VAL_1,
	E_VAL_2
};
 
std::ostream& operator<<(std::ostream& os, const MonEnumeration& e)
{
	switch(e)
	{
	case E_VAL_1:
		os << "E_VAL_1";
		break;
	case E_VAL_2:
		os << "E_VAL_2";
		break;
	}
	return os;
}
 
int main()
{
	MonEnumeration e = E_VAL_1;
	std::cout << e << std::endl;
	return 0;
}

Ce programme affiche bien "E_VAL_1" à l'écran.

Mais c'est tout de même bien contraignant : la duplication des informations est évidente : entre la
déclaration de l'énumération et l'opérateur "<<", "E_VAL_1" est écrit 3 fois ! C'est évidemment source
d'erreurs (le copier-coller n'est pas le meilleur ami du programmeur, loin s'en faut...), particulièrement
lorsque l'on veut rajouter de nouvelles valeurs à l'énumération. Et puis c'est tout simplement pénible
de devoir maintenir l'énumération et l'opérateur.
Bref, c'est moche, peut mieux faire.

C'est là qu'arrive le préprocesseur.

A partir de là, je suppose que vous utilisez GCC (ou MinGW/Cygwin sous Windows).

Nous allons en particulier nous baser sur 2 opérateurs spéciaux du préprocesseur, qui ne sont pas très
connus : # et ##.

Commençons par # : il permet de rajouter des guillemets autour de l'argument d'une macro.

Démonstration :

#define STRINGIFY(val) #val
 
STRINGIFY(pouet)

Supposons que vous ayez enregistré cela dans "pouet.h" : passez un coup de préprocesseur : "cpp pouet.h"
(ou bien "g++ -E pouet.h", ça revient au même).

Résultat affiché :

# 1 "pouet.h"
# 1 "<interne>"
# 1 "<command-line>"
# 1 "pouet.h"
 
 
"pouet"

Bon, déjà, ça c'est intéressant On remarque que cpp écrit des lignes commençant par un #, que le compilateur
qui passe derrière doit probablement interpréter pour les messages d'erreurs afin d'indiquer la ligne de l'erreur.

Passons à la suite : on voudrait une macro qui permette d'automatiser la création de l'opérateur "<<" pour
l'affichage de la valeur de notre énumération.
Essayons d'abord en supposant que notre énumération ne puisse contenir qu'une seule valeur :

#define MAKE_ENUM(enum_name, val)	\
	enum enum_name {	\
		val			\
	};
 
#define MAKE_OPERATOR(enum_name, val)	\
	inline std::ostream& operator<<(std::ostream& os, const enum_name& e)	{\
		switch(e) {	\
			case val:	\
				os << #val;	\
				break;	\
		}	\
		return os;	\
	}
 
 
#define ENUMERATE(enum_name, val)	\
	MAKE_ENUM(enum_name, val)	\
	MAKE_OPERATOR(enum_name, val)
 
ENUMERATE(MonEnumeration,
	E_VAL_1);

On a donc une macro MAKE_ENUM qui s'occupe de déclarer l'énumération et une macro MAKE_OPERATOR qui s'occupe
de définir l'operateur "<<". Notez le "inline" qui sert à éviter tout problème de linkage (si le même fichier .h,
qui décrit l'énumération et l'opérateur, est inclus dans 2 .cpp différents, on se retrouve avec l'opérateur défini 2
fois, et couic !).

Cool, ça marche ! (en même temps c'est un tuto...)

Maintenant, on peut arrêter de contourner la difficulté et s'attaquer au vrai problème : comment gérer le fait
qu'une énumération n'ai pas 1, 2, ou 3 valeurs, mais un nombre variable ??

C'est là qu'arrive une autre astuce du préprocesseur : la macro __VA_ARGS__.

Démonstration, dans notre pouet.h :

#define MA_MACRO(...) __VA_ARGS__
MA_MACRO(a, b, c)

cpp pouet.h donne :

# 1 "pouet.h"
# 1 "<interne>"
# 1 "<command-line>"
# 1 "pouet.h"
 
a, b, c

Pratique, quand on veut des macros avec un nombre variable d'arguments...

On peut dores et déjà remplacer MAKE_ENUM par une version capable de gérer un nombre variable d'arguments :

#define MAKE_ENUM(enum_name, ...)	\
	enum enum_name { __VA_ARGS__ };

Ça, c'est fait. Maintenant, reste le problème de MAKE_OPERATOR...

Si l'on analyse le problème, on voit que l'on a 3 parties :

- une introduction :

inline std::ostream& operator<<(std::ostream& os, const enum_name& e)	{
		switch(e) {

- une partie qui se répète :

		case val:
			os << #val;
			break;

- une conclusion :

		}
		return os;
	}

Il s'agit donc, à partir d'une liste variable d'arguments, de répéter plusieurs fois la partie centrale pour
chaque argument "val". C'est là que j'ai pensé à ces vieux cours de Caml, où pour traiter une liste, on écrivait
une fonction récursive, qui décomposait la liste en t::q (pour tête et queue), la tête étant le 1er élément, et la
queue tout le reste. Désolé pour ceux qui n'ont pas fait de Caml :p

Pour revenir à notre préprocesseur, cela se traduirait par une macro qui prend en argument quelque chose de la forme :
#define MACRO(a, ...) et qui ensuite s'appellerait récursivement jusqu'à ce qu'il n'y ait plus d'argument.

Malheureusement, la récursivité, en préprocesseur ça n'existe pas, ou alors j'ai pas trouvé comment...

Il va donc falloir trouver une parade : il s'agira d'écrire une version de la macro pour chaque appel récursif, i.e.
pour chaque nombre d'arguments :

#define ENUM_CASE_1(val)	\
	case val:	\
		os << #val;	\
		break;
 
#define ENUM_CASE_2(val, ...)	ENUM_CASE_1(val) ENUM_CASE_1(__VA_ARGS__)
#define ENUM_CASE_3(val, ...)	ENUM_CASE_1(val) ENUM_CASE_2(__VA_ARGS__)
#define ENUM_CASE_4(val, ...)	ENUM_CASE_1(val) ENUM_CASE_3(__VA_ARGS__)

Le problème n'est toujours pas totalement résolu : encore faut-il choisir la bonne macro à utiliser...

C'est là qu'arrive l'opérateur ## du préprocesseur
Celui-ci permet de concaténer des symboles.

Exemple (dans pouet.h) :

#define CONCAT(a, b) a ## b
CONCAT(foo, bar)

"cpp pouet.h" affiche cette fois :

# 1 "pouet.h"
# 1 "<interne>"
# 1 "<command-line>"
# 1 "pouet.h"
 
foobar

Cela va nous servir à choisir la bonne macro à utiliser :

#define ENUM_CASE_N(nb_vals, ...) ENUM_CASE_ ## nb_vals(__VA_ARGS__)

Le gros inconvénient est bien sûr qu'il nous faut préciser le nombre de valeurs de l'énumération :/

Il semble que l'on ait fait le tour. Voici donc la version finale de tout ça, séparée dans un .h générique
et un .cpp d'exemple :

// Enumerate.h
 
#ifndef ENUMERATE_H
#define ENUMERATE_H
 
#define MAKE_ENUM(enum_name, ...)	\
	enum enum_name { __VA_ARGS__ };
 
#define ENUM_CASE_1(val)	\
	case val:	\
		os << #val;	\
		break;
 
#define ENUM_CASE_2(val, ...)	ENUM_CASE_1(val) ENUM_CASE_1(__VA_ARGS__)
#define ENUM_CASE_3(val, ...)	ENUM_CASE_1(val) ENUM_CASE_2(__VA_ARGS__)
#define ENUM_CASE_4(val, ...)	ENUM_CASE_1(val) ENUM_CASE_3(__VA_ARGS__)
#define ENUM_CASE_5(val, ...)	ENUM_CASE_1(val) ENUM_CASE_4(__VA_ARGS__)
#define ENUM_CASE_6(val, ...)	ENUM_CASE_1(val) ENUM_CASE_5(__VA_ARGS__)
#define ENUM_CASE_7(val, ...)	ENUM_CASE_1(val) ENUM_CASE_6(__VA_ARGS__)
#define ENUM_CASE_8(val, ...)	ENUM_CASE_1(val) ENUM_CASE_7(__VA_ARGS__)
#define ENUM_CASE_9(val, ...)	ENUM_CASE_1(val) ENUM_CASE_8(__VA_ARGS__)
#define ENUM_CASE_10(val, ...)	ENUM_CASE_1(val) ENUM_CASE_9(__VA_ARGS__)
 
#define ENUM_CASE_N(nb_vals, ...) ENUM_CASE_ ## nb_vals(__VA_ARGS__)
 
#define MAKE_OPERATOR(nb_vals, enum_name, ...)	\
	inline std::ostream& operator<<(std::ostream& os, const enum_name& e)	{\
		switch(e) {	\
			ENUM_CASE_N(nb_vals, __VA_ARGS__)	\
		}	\
		return os;	\
	}
 
 
#define ENUMERATE(nb_vals, enum_name, ...)	\
	MAKE_ENUM(enum_name, __VA_ARGS__)	\
	MAKE_OPERATOR(nb_vals, enum_name, __VA_ARGS__)
 
#endif // ENUMERATE_H

// main.cpp
 
#include <iostream>
#include "Enumerate.h"
 
ENUMERATE(3, MonEnumeration,
	E_VAL_1,
	E_VAL_2,
	E_VAL_3);
 
int main()
{
	MonEnumeration e = E_VAL_1;
	std::cout << e << std::endl;
	return 0;
}

Conclusion

Au final, cette méthode présente l'avantage d'éviter la duplication de code, et tous les ennuis qui vont avec.
Il reste cependant plusieurs inconvénients non négligeables :
- On est obligés de préciser le nombre de valeurs de l'énumération
- On est limités dans le nombre de valeurs que l'on peut définir par le nombre de macros que l'on a définis dans Enumerate.h
A la limite, si l'on a besoin de plus de valeurs, il suffit de les rajouter, c'est pas bien grave ^^
- Pour la plupart des IDE, je pense qu'un tel système aboutit à un type "MonEnumeration", ainsi que les valeurs définies,
qui sont inconnus. Ça peut être un problème...
- En déclarant ses énumérations de la sorte, on ne peut pas préciser de valeur numérique pour chaque valeur possible de
l'énumération.

La méthode a ses limites, et je me demande s'il n'y aurait pas moyen d'aller au-delà en utilisant des templates...
Par ailleurs, ce petit article sur le préprocesseur ne fait aucune mention de Boost::Preprocessor, qui, selon Arnaud,
est incroyable à voir...
Je serais curieux de voir s'il pourrait apporter un élément de réponse au problème ^^

Ce sera tout !

M'étant mis à Haskell depuis quelques temps (principalement grâce au désormais fameux Real World Haskell), je me suis dis qu'il était temps que je regarde un peu du côté des bibliothèques pour interfaces utilisateurs. Hé bien, je n'ai pas été déçu. Il y a notamment Gtk2Hs qui fournit un bon binding de GTK+, compatible avec Glade (le designer) et qui permet donc de charger des interfaces depuis du XML.

Allez-y, devinez combien de lignes il a fallu ?
Initialiser le GUI, créer les widgets, ... Hmm beaucoup ?

Hé bien non ! Le designer, Glade, exporte le "projet" suivant dans un XML.

XML généré :

<?xml version="1.0"?> 
<glade-interface> 
  <!-- interface-requires gtk+ 2.16 --> 
  <!-- interface-naming-policy project-wide --> 
  <widget class="GtkWindow" id="window1"> 
  <property name="title" translatable="yes">Hello, Developpez !</property> 
  <property name="default_width">400</property> 
  <property name="default_height">400</property> 
  <child> 
  <widget class="GtkButton" id="yo"> 
  <property name="label" translatable="yes">Bonjour Developpez, comment vas-tu ? 
 
Je suis un programme Haskell qui utilise 
Gtk2Hs, binding Haskell de GTK+. 
 
Clique pour fermer.</property> 
  <property name="visible">True</property> 
  <property name="can_focus">True</property> 
  <property name="receives_default">True</property> 
  </widget> 
  </child> 
  </widget> 
</glade-interface>

Et voilà, l'essentiel est fait.

Voici donc le main.hs, qui est le programme Haskell dont vous avez vu un screenshot plus haut :

module Main where 
 
import Graphics.UI.Gtk -- on importe le module GTK 
import Graphics.UI.Gtk.Glade -- et le module Glade, pour créer une IHM depuis le XML au format Glade 
 
main = do 
  initGUI 
  Just xml <- xmlNew "test.glade"  
  window <- xmlGetWidget xml castToWindow "window1" 
  button <- xmlGetWidget xml castToButton "yo" 
  onClicked button $ do 
  putStrLn "Bye" 
  mainQuit 
  onDestroy window mainQuit 
  widgetShowAll window 
  mainGUI

Et voilà. Assez simple non ?