• 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 !

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 ?

• Un immeuble bleu peut être placé partout.
• Un immeuble rouge doit posséder au moins un immeuble bleu dans son voisinage.
• Un immeuble vert doit posséder au moins un immeuble bleu et rouge dans son voisinage.
• Un immeuble jaune doit posséder au moins un immeuble bleu, rouge et vert dans son voisinage.

On considère ici un voisinage en 4-connexités. Dans le jeu original, il est possible de détruire des tours voisines afin de placer davantage de tours de plus grande importance (loophole). Dans un souci de simplicité, j’ignore ici cette possibilité. L’image ci-dessous donne un exemple d’agglomération qui respecte les règles énoncées précédemment.

Exemple d'agglomération

Outre l’aspect divertissant du jeu, une question plus profonde a rapidement taraudé mon esprit : quelle est la configuration optimale des immeubles qui maximise le nombre d’immeubles de plus grande importance ?

Très vite, on devine que le problème d’optimisation combinatoire sous-jacent posé doit facilement pouvoir s’exprimer sous la forme d’un programme linéaire en nombres entiers (PLNE). Algorithmiquement, la résolution d’un PLNE est autrement plus difficile qu’un PL mais il existe des algorithmes (par exemple branch-and-bound) performants et éprouvés. Ces algorithmes se basent sur la relaxation continue du PLNE (sans les contraintes d’intégrité) et permettent d’éviter une énumération exhaustive des solutions.

Après avoir écrit sur papier la fonction objectif et les contraintes associées, je me suis donc mis en quête d’un solveur gratuit et disponible sous GNU/Linux. Ne connaissant pas en détail les différents solveurs, mon choix s’est porté sur le premier venu : GLPK. Etant novice, l’écriture du programme linéaire m’a demandé quelques refléxions préalables pour généraliser le problème pour un couple de paramètres (n, m) donné.

A partir de ce problème, on peut aussi imaginer diverses extensions :

• Transposer le problème sous la forme d’un graphe et généraliser.
• Généraliser le problème en dimension N : cela implique notamment de définir précisément la notion de voisinage en dimension quelconque.
• Utiliser d’autres règles de dépendances entre immeubles : on pourrait alors imaginer des graphes de dépendance beaucoup plus complexes.
• Utiliser d’autres types de voisinages dans le cas de graphes à « grille ».

Comme bien souvent, la question initiale en appelle plusieurs autres : est-ce que ce problème a déjà été traité dans la littérature (éventuellement présenté sous une autre forme) ? Si oui, quelle est sa complexité pour un m fixé ? Le parallèle sur la coloration de graphes vient presque spontanément. Néanmoins, le problème qui nous occupe est différent et a priori plus simple. On peut tout de même se poser la question pour m=2, m=3 et m>=4. En particulier, il serait intéressant de savoir d’une part, s’il existe un algorithme polynomial pour m=2 et d’autre part, savoir si le problème est NP-Difficile pour m>=4.

D’un point de vue plus technique, cela consiste simplement en un programme linéaire écrit en GMPL pour le solveur GLPK. Les contraintes entre immeubles sont générées à l’aide d’un simple script. Le script écrit le programme linéaire dans un fichier, lance le solveur, affiche les résultats sous la forme d’un tableau et donne le score correspondant.

Finalement, j’ai pu résoudre mon problème initial pour l’instance (n=5, m=4) en une à deux heures de calcul. Il est sûrement possible de diminuer le temps de calcul au niveau de l’algorithme de branch-and-bound, en passant les options adéquates au solveur. Lorsque j’aurai davantage de temps, j’aimerai aussi pouvoir résoudre le même problème avec loophole. Have fun

Nabaztag

J’ai reçu à Noël dernier une jolie petite bestiole. Un bon gadget de geek Le Nabaztag.

Très bonne idée à la base, le concept est intéressant, c’est typiquement le genre de truc qui m’intéresse. Sauf … que ce Nabaztag est finalement un peu trop inutile à mon goût et surtout bien trop contrôlé par la société qui le vend, à savoir la société Violet. Déjà, qu’est-ce que cette petite bestiole ? Il s’agit en fait d’un terminal connecté à Internet en wifi par lui même et qui peut interagir à la fois avec du contenu sur Internet et avec l’utilisateur. Il est alors possible de lire la météo, suivre ses emails, écouter la radio, écouter des podcast, lire des flux en streaming, suivre des flux RSS, etc. Notre ami lapin clignote de partout et bouge les oreilles dans tous les sens et peut même lire des puces RFID. Bref une bonne idée dans l’absolu, mais finalement ce lapin m’a plus énervé que servi pour l’instant. J’écoute beaucoup de webradio sur Internet, on peut charger des radios sans problème … sauf que notre ami lapin lit comme un abruti les trames METADATA (titres des musiques entre autres) des flux http des radios. Du coup on a droit à des gros parasites aléatoires dans la musique, parce que le lapin essaye de faire lire du texte au lieu du flux mp3… ahah bien joué !

Second truc qui m’embête pas mal. Le lapin se connecte par Internet au serveur de Violet. Le système embarqué au sein du lapin n’est pas super puissant, donc tout le traitement a lieu, semblerait-il, de manière déportée, le lapin ne reçoit que des commandes.En gros si la société fait faillite ou arrête le développement du lapin … le lapin devient hors d’usage. J’ai quand même du mal à me savoir dépendant d’une société pour utiliser un objet comme celui-ci. En dehors du fait que le lapin n’est pas super fiable, dépend du serveur de violet pour fonctionner comme réveil ou lire ses mails etc, le gadget reste intéressant, mais hélas ça reste un gadget. Je n’ai pas réussi à l’intégrer dans ma vie de tous le jours. Dommage.

En dehors des services de base proposés par Violet pour le nabaztag, la société a créé une API pour permettre aux propriétaires de Nabaztag de le commander eux mêmes, c’est à dire faire bouger les oreilles, lancer des flux mp3 à la demande, lancer le synthétiseur de parole, etc. Mais, même problème ce ne sont que de simples requêtes HTTP qui ne permettent pas d’aller bien loin. Et puis accessoirement, le lapin est carrément manipulable depuis n’importe quel coin de la planète, du moment qu’une personne a l’identifiant de votre lapin (sorte d’adresse MAC). Vous avez vite fait de tomber par hasard sur l’adresse d’un lapin existant.

Bref, après moins de 2 semaines de tentatives d’utilisation je n’ai pas résisté à la tentation de démonter cette petite bestiole. Il s’avère qu’elle cache du matériel plutôt sympathique, et j’ai découvert avec joie qu’elle disposait d’un port JTAG, permettant de programmer le processeur directement.

Nabaztag Démonté

Carte embarquée du Nabaztag

J’ai pu donc diséquer le lapin et découvrir ce qu’il se trouvait à l’intérieur:

• 2 moteurs continus pour faire bouger les oreilles
• Un lecteur de puce RFID
• Un micro
• Une prise jack reliée à la carte son
• Un potentiomètre pour régler le volume
• Une carte wifi
• Un haut parleur
• Des DELs associées et leurs cônes de direction pour avoir de jolies petits ronds lumineux sur la coque par transparence

MCBSTM32 - Carte de développement pour processeur ARM

Je ne vais pas détailler minutieusement tous les composants de la carte principale. Quelqu’un s’en est déjà chargé sur ce blog. Je peux lire sur le processeur « OKI L670405I – INNN, ARM 722EBAUJ ». Il semblerait qu’il s’agisse d’un processeur ARM7 TDMI, ce processeur pourrait d’après mes recherches (je n’en suis pas sûr) être programmé par une carte de développement qui vaut 229$. Ahah la bonne blague ! Il doit peut être y avoir moyen de trouver un moyen moins cher, mais je ne le connais pas encore.

Du coup j’essaye de découvrir comment reprogrammer le processeur pour y mettre un Firmware maison et libre de surcroit. En gros dans l’idée de permettre aux gens d’utiliser leur nabaztag sur des serveurs qui ne sont pas ceux de Violet. (Free your rabits !!!) Cela impliquerait un certain travail, analyse minutieuse des specifications matérielles, reprogrammation des drivers, reprogrammation des protocoles de communication, reprogrammation d’un serveur etc. Mais c’est le genre de projet qui m’intéresserait vraiment : refaire de A à Z le firmware à des fins pédagogiques. J’essaye de contacter des gens sur Internet qui semblent intéressés par la libération des lapins, pour l’instant pas de réponse positive. Mais je cherche toujours ! Pour l’instant je ne sais pas trop par où commencer avec le peu de connaissances et de matériel que j’ai à ma disposition. Mais si par hasard, vous êtes intéressé par une telle entreprise n’hésitez pas à me contacter.