• 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

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 !

Carte Fox

J’ai été amené à travailler dans le cadre de mes études sur un petit projet de développement d’une Interface GSM sur un système Linux embarqué. Ayant découvert la puissance du système, j’ai pensé vous faire part de mes découvertes sur l’utilisation de cette carte.

Dans mon cas le principe était de créer un système autonome d’envoi de SMS aux étudiants de mon école. L’idée étant de pouvoir envoyer les résultats des examens directement par SMS aux étudiants, ce qui est ma foi fort sympatique

Le Matériel

Alors, tout d’abord : Carte FOX Késako !? Il s’agit d’un système embarqué à bas coût utilisant le système d’exploitation Linux. La carte est dotée d’un processeur AXIS à 100MHz et de 32 MB de RAM, de connectiques USB, Ethernet, d’un port série console ainsi que 40 pins pouvant être reliées à plusieurs BUS de données. Elle permet de développer en bon nombre de langages : C, C++, PHP, PYTHON, Shell, … et permet des connections HTTP, FTP, SSH et TELNET. De petite taille et faible consommation électrique (1 W) est idéale pour mettre en place rapidement des projets de type embarqué.

Modem GSM

Le modem GSM utilisé ici est un modem de la marque Telit. Il est relié à la carte FOX par l’intermédiaire d’une carte d’extension. La carte FOX peut communiquer avec le modem par l’intermédiaire du port série /dev/ttyS2. Une simple utilisation de carte SIM classique permet de se connecter au réseau GSM. Il est possible de trouver cette carte seule sur le site d’ACME SYSTEMS à 176 € frais de port tout compris. Si l’on ajoute le kit GPRS cela monte jusqu’à 626 €, ce qui commence déjà à faire beaucoup. Je pense qu’une solution plus abordable serait de relier la carte basique à un téléphone portable pour communiquer en série étant donné que dans notre cas nous n’avons pas besoin de tous les éléments de la carte d’extension.

Les modems GSM utilisent un protocole de commandes appelées « commandes AT ». Chaque constructeur fait un peu ce qu’il veut avec ses normes, ce qui fait que chaque modem est plus ou moins différent et qu’il faut se référer à la doc du constructeur. Ces commandes AT sont donc envoyées via le port série pour soumettre différentes commandes au modem. On peut notamment dans notre cas manipuler et envoyer des SMS par l’intermédiaire de celles-ci.

Environnement de développement

La compilation d’un programme en C sur la carte fox nécessite un compilateur croisé permettant de compiler le code C pour les processeurs AXIS. La compilation directe sur la carte n’étant pas possible, il faut par conséquent utiliser un SDK pour compiler le programme. J’ai travaillé avec le SDK Axis fourni pour la carte fox.

Avant toute chose il faut se rendre dans le dossier du SDK (~/devboard-R2_01 pour ma part) et y taper la commande suivante afin d’initialiser l’environnement de développement.

. init_env

Ensuite, il faut choisir le compilateur AXIS

make cris-axis-linux-gnu

On doit alors créer un Makefile pour notre programme. Voici celui que j’ai créé :

AXIS_USABLE_LIBS=UCLIBC GLIBC
include $(AXIS_TOP_DIR)/tools/build/Rules.axis
PROGS = sms
INSTDIR= $(prefix)/mnt/flash
INSTMODE= 0755
INSTOWNER= root
INSTGROUP= root
OBJS = main.o atcommand.o modem.o
all: $(PROGS)
$(PROGS): $(OBJS)
$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
scp sms root@fox01:/mnt/flash/tx
clean:
rm -f *.o
rm -f sms

Il n’y a alors plus qu’à faire un make pour compiler le programme et à l’envoyer sur la carte en FTP ou SCP. Ayant dû compiler à de très nombreuses reprises mon programme, j’ai rajouté l’envoi du fichier dans le makefile via la commande scp. Les fichiers utilisateurs sont déposés sur la carte Flash dans le répertoire /mnt/flash. Attention toutefois, car la mémoire flash EPROM est limitée en nombre d’écritures. Il vaut mieux tant que possible éviter d’écrire dans cette mémoire régulièrement. Privilégier la RAM (dossier /var par exemple) plutôt que sur la carte flash. Seul soucis, la carte se réinitialise à chaque redémarrage, par conséquent les tests peuvent être faits en RAM et une fois que l’application compilée est stable il est préférable de la déposer sur la carte flash afin de ne pas perdre le programme à chaque reboot.

La connexion à la carte fox se fait en telnet (ou ssh) simplement à l’aide de la commande suivante grâce à un simple telnet

telnet adresse_ip_de_la_fox

Développement du programme

Utilisation des commandes AT

Le modem se commande directement grâce aux commandes AT.  Ces commandes AT suivent une certaine syntaxe et nécessitent une mise en forme particulière pour leur envoi sur le modem. Ce dernier reconnaît plusieurs caractères de contrôle :

<CR> : Caractère de retour chariot : Sa valeur ASCII en décimal est fixée à 13 par défaut. (et peut être changée grâce au paramètre AT S3) Sa valeur hexadécimale quant à elle est 0×0D.

<LF> : Caractère d’interligne : Sa valeur ASCII en décimal est fixée à 10 par défaut

<CTRL+Z> : Combinaison des touches CTRL et Z. Sa valeur hexa est 0×1A

Ces caractères sont demandés et utilisés par le modem pour identifier les commandes AT. Chacune d’entre-elles utilise ces caractères de contrôle plus ou moins différemment. Voici un aperçu des différentes commandes que j’ai utilisées avec leurs caractères de contrôle.

ATE0<CR>
Cette commande permet de désactiver la commande écho (ATE1 la réactive). Cela demande donc au modem de ne pas répéter systématiquement les commandes qui lui sont envoyées.

AT+CMGF=1<CR>

Cette commande permet de régler le format de message pour l’envoi de SMS. Par défaut, le modem est en mode PDU (AT+CMGF=0). C’est-à-dire que l’envoi de message se fait en hexadécimal. AT+CMGF=1 permet de passer en mode texte, ce qui simplifie les manipulations de SMS.

AT+CMGS= »06XXXXXXXX »<CR>

Cette commande permet de commencer la rédaction d’un SMS. On précise en argument le numéro de téléphone choisi. En retour on obtient le caractère d’invite de commande « > » qui nous invite à rentrer le texte du SMS.

Texte du SMS<CTRL+Z><CR>
Cette fin de commande permet alors de préciser le texte et de valider l’envoi du SMS par un CTRL+Z et un retour chariot.

Il est important de noter que l’envoi de la commande AT d’envoi de SMS se fait en 2 parties et pas en un coup. (j’ai testé pendant plusieurs semaines… ça ne marche pas ^^)

Le modem répond à ces commandes par des messages de retour. Ces derniers indiquent si celles-ci ont été exécutées avec succès ou non. La plupart de ces réponses sont entourées des caractères <CR><LF> Il y a toutefois des exceptions, notamment pour AT+CMGS qui renvoie +CMGS: <mr> ou +CMS ERROR: <err> Mais dans la plupart des cas les retours sont rapportés de la manière suivante :
<CR><LF>OK<CR><LF>
<CR><LF>ERROR<CR><LF>
<CR><LF>…<CR><LF>

Ces commandes AT doivent être transmises au modem par le port série /dev/ttyS2. Il existe plusieurs façons de communiquer sur le port série :

Termnetd (http://foxlx.acmesystems.it/?id=69)

Il s’agit d’un processus permettant de relier un port TCP/IP à un port série de manière transparente. Une fois que le deamon est lancé sur la carte fox, il est possible de se connecter depuis l’extérieur grâce à la commande telnet adress_ip_fox 7000. Le port 7000 (choisi dans la config de termnetd) redirige directement sur le port série et il est alors possible de rentrer manuellement des commandes AT et de voir leur comportement direct sur le modem. Ce programme est utile pour comprendre le fonctionnement des commandes AT.

Script Chat (http://linux.about.com/od/commands/l/blcmdl8_chat.htm)
Il est possible d’utiliser la commande UNIX chat permettant de dialoguer de manière automatisée avec le modem.

/usr/sbin/chat -V -s -f <fichier_script> > /dev/ttyS2 < /dev/ttyS2 2><fichier_resultat>

La réponse du modem est alors enregistrée dans le fichier de résultat choisi.

Programme en C
Il est également possible de dialoguer avec le modem via un programme C. Le dialogue se fait alors en écrivant et en lisant sur /dev/ttyS2. La prise en main est beaucoup plus complexe que les 2 précédentes méthodes, mais permet une totale maitrise du modem.

Développement en C

Le code pour envoyer un SMS n’est pas bien compliqué, mon but n’est pas là de copier/coller intégralement mon code, mais plutôt d’expliquer les grandes lignes son fonctionnement et de vous donner envie de bidouiller une carte fox ^^

L’idée est donc d’initialiser tout d’abord la connexion série à l’aide de Termios. La documentation sur le site du constructeur regorge d’informations et propose du code tout fait pour gérer la connexion série. Une fois la configuration réalisée (c’est très rapide à réaliser), il n’y a plus qu’à faire un write sur /dev/ttyS2

char command1[50];
char command2[50];
sprintf(command1, "AT+CMGS="%s"x0D", number);
sprintf(command2, "%sx1Ax0D", text);
write (tty_fd, command1, strlen(command1));
sleep(1); // attend la réponse du modem afin d'envoyer la seconde partie
write(tty_fd,command2,strlen(command2));

Et le SMS est envoyé ! Après libre à vous de rajouter à la suite une lecture de la réponse du modem (gentil petit read). Dès lors il est possible de se faire une petite fonction d’envoi de SMS à partir d’arguments tels que le numéro de téléphone et le texte du message. J’en ai profité pour me rajouter un système de logs et de manipulation du modem (redémarrage, arrêt). Je me suis créé une interface web en bash (scripts cgi) et par simples appels de notre programme C il est alors possible de se construire une application métier complexe. On a plus qu’à brancher notre carte fox sur le réseau et celle-ci peut envoyer des SMS à distance de manière assistée grâce à des formulaires web !

Préparation de la carte FOX

Dernier point de précision: au démarrage, le modem n’est pas allumé ni configuré. Il faut par conséquent créer un script de démarrage à déposer dans /etc/init.d/boottime . Voici le script que j’ai utilisé:

#!/bin/sh
# démarrage du modem
setbits -p b -b 7 -s 1
# Lancement de termnetd (pour les tests)
/mnt/flash/termnetd
# Initialisation série du modem (mon petit programme d’initialisation de la connexion série)
/mnt/flash/tx/sms -init
sleep 20
# Initialisation AT du modem
/usr/sbin/chat -V -s -f /mnt/flash/tx/scripts/scriptAT.chat >
/dev/ttyS2 < /dev/ttyS2 2> /mnt/flash/tx/scripts/scriptAT_result.txt
# Ecriture des logs (pour le fun ^^)
echo “`date` : MODEM start” >> /mnt/flash/tx/log/fox.log

On commence par allumer le modem, on initialise la connexion série avec le programme en C puis attend 20 secondes que le modem soit identifié sur le réseau. Le temps choisi est totalement arbitraire. Cela semble fonctionner correctement avec cette période, mais idéalement il serait intéressant d’interroger le modem pour déterminer s’il est bien connecté au réseau. Ensuite on exécute un script chat que voici :

ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
'' AT
OK ATZ
OK 'ATE0'
OK 'AT+CMGF=1'
OK ''

Ce dernier permet de désactiver l’écho afin de ne pas recevoir mes commandes en double, et permet d’activer le mode texte pour l’envoi de SMS. Par défaut l’envoi de SMS se fait en mode PDU (sous forme hexadécimale), ce qui est bien plus compliqué à utiliser. Une fois ce script exécuté, le modem est prêt à être utilisé. On peut rajouter un log à la fin pour identifier le démarrage du modem.

La carte fox est une carte embarqué assez simple à prendre en main, les utilisations sont assez illimités. Le rêve de tout bidouilleur !
Je songe à m’en commander une très bientôt, je ne peux pas résister à tant de potentiel de bidouille.

A suivre : Comment connecter la carte fox au réseau GPRS pour pouvoir aller sur le net et envoyer des mail

wxWidgets est une librairie open source dont le but 1er est de permettre de créer des interfaces graphiques pour ses programmes (fenêtres, boutons…etc). Elle est portable mais les applications crées avec ont la particularité d’adopter le « look and feel » (apparence) de la plate-forme sur laquelle elles ont été compilées. Cela est dû au fait qu’en interne, wxWidgets utilise l’API propre à chaque plate-forme (API Win32 ou juste GDI sous Windows, GTK+, Motif ou directement X11 sous Linux et autres UNIXs, Carbon ou Cocoa sous Mac…). Cependant, l’équipe de wxWidgets a également mis sur pied une version spéciale de wxWidgets, wxUniversal, qui compile sous Windows, Linux et certains périphériques embarqués, et qui s’occupe entièrement de l’affichage (le « look and feel » natif de la plate-forme n’est pas forcément respecté).

Cependant, wxWidgets ne se limite pas à permettre la création d’interfaces graphiques, elle est capable de faire beaucoup d’autres choses; elle possède ses propres classes de tableau, tables de haschage, liste chaînée, elle permet de créer des applications utilisant les sockets (connections réseau), d’intégrer une zone dédiée à OpenGL dans une fenêtre pour pouvoir faire du dessin en 3D, de faire des manipulations de chaînes grâce à la classe wxString, contient une sous-librairie, wxHTML, qui permet de visualiser une page HTML, possède son propre système d’aide semblable aux CHM de Windows, peut utiliser des ressources au format XML, peut utiliser des bases de données…etc.

Et tout cela est gratuit et portable, pourquoi s’en priver ?

II) Installation

Quelle que soit la plate-forme choisie, wxWidgets n’est pas livrée pré-compilée; c’est à vous de la compiler à partir des sources.

Mais avant de compiler, cherchez le fichier setup.h et modifiez-le si besoin. Ce fichier contient des #defines qui définissent comment la librairie doit être compilée. Personnellement, j’ai l’habitude de changer le :

// Recommended setting: 1 if you intend to use OpenGL, 0 otherwise
#define wxUSE_GLCANVAS

en :

// Recommended setting: 1 if you intend to use OpenGL, 0 otherwise
#define wxUSE_GLCANVAS

Ce qui permet d’utiliser la classe wxGLCanvas si l’on veut pouvoir créer une zone OpenGL dans une fenêtre d’un programme wxWidgets.

Ensuite, si vous êtes sous Visual C++, il lancez la compilation du projet situé dans le répertoire src. Vous avez le temps d’aller boire un café en attendant, vu que le compilateur met un certain temps à « digérer » la librairie

Après, il faut aller dans le menu Tools->Options->onglet Directories, rajouter le répertoire lib lorsque « Librairies files » est sélectionné et rajouter le répertoire include lorsque « Include files » est sélectionné.

Enfin, pour créer un projet, je vous recommande de reprendre un des projets du répertoire samples qui contient de nombreux exemples et de le réutiliser.

Si vous utilisez Dev-C++, vous pouvez trouver des DevPacks ici ou compiler vous-mêmes; si vous optez pour cette solution, regardez du côté des makefiles, du fichier configure ou essayez d’importer le projet Visual C++.

[UPDATE du 23/09/04 : vous pouvez également télécharger un DevPack ICI pour wxWidgets 2.5.2, merci à fredcl D'ailleurs il me fait remarquer qu'il faut impérativement désinstaller toute version précédente du DevPack avant d'installer celle-ci ^^]

Si vous êtes sous Linux, il faut faire le triplet habituel

./configure
 
make
make install

Mais renseignez-vous avant sur les options que vous pouvez passer au ./configure (notamment –with-opengl et –use-gtk2 il me semble, mailez-moi si je me trompe).

Ensuite, pour la compilation en ligne de commande on fait:

g++ mon_code.cpp -o mon_executable `wx-config --libs --cflags`

III) Premier programme

Allez c’est parti, maintenant on code !

// App.h
#ifndef APP_H
#define APP_H
 
// Le header principal de wxWidgets
#include 
 
// La classe App représente l'application
class App : public wxApp
{
public:
 
   virtual bool OnInit();  // OnInit() est l'équivalent du main() classique :
                           // c'est là que débute le programme.
 
};
 
#endif // APP_H

// App.cpp
#include "App.h"
 
// Cette macro crée l'objet global de type App qui représente l'application.
IMPLEMENT_APP(App)
 
// Equivalent de main()
bool App::OnInit()
{
   // On crée une nouvelle wxFrame (une fenêtre), avec new.
   // Notez qu'il est inutile d'appeler delete, wxWidgets le fera
   // automatiquement :)
   wxFrame* frame = new wxFrame(NULL, -1, "Hello World !");
 
   // On centre la fenêtre
   frame->Center();
 
   // On l'affiche
   frame->Show();
 
   // On précise à wxWidgets que ce sera la fenêtre principale;
   // grâce à cela il pourra détruire (delete) la fenêtre en fin d'application
   // et c'est aussi grâce à cela qu'un clic sur la croix ferme le programme
   // (et pas seulement la fenêtre).
   this->SetTopWindow(frame);
 
   // Pour finir on renvoie TRUE, ce qui signifie que l'application doit continuer
   // (et rentrer dans la boucle d'évènements).
 
   return TRUE;
}

IV) Conclusion

Voilà, ce tutorial n’est qu’une première approche à wxWidgets, normalement devraient suivre d’autres tuts sur les menus, les boutons, les listes…

Comme d’habitude, pour toute remarque/critique/suggestion, laissez un message ci-dessous ou mailez-moi à funto66 at gmail.com.

Cet article provient du tutorial publié par Funto le 08/08/2005 sur l’ancien site de Coder-Studio.

Je suppose que si vous êtes arrivé jusqu’à cette page web, soit vous vous êtes perdu soit vous voulez vraiment apprendre à programmer en langage C ^^. Si vous êtes dans ce cas, bienvenue chez les programmeurs ! Alors, qu’est-ce que le C ? Le C est un langage de programmation; on écrit un programme dans ce langage, et ensuite le texte que vous avez tapé est converti par un « compilateur » en langage binaire 0 et 1 compréhensible par le processeur de votre ordinateur (un fichier .exe). Donc, pour commencer, il vous faut un compilateur et un éditeur (le bloc-notes peut suffire comme éditeur mais il y a beaucoup mieux ). Un environnement qui intègre et compilateur et éditeur est appelé IDE (Integrated Development Environment). La plupart de ceux que je vais vous proposer sont des compilateurs C++. Qu’est-ce que le C++? C’est un autre langage, mais qui en réalité est compatible avec le C (un programme écrit en C peut se compiler avec un compilateur C++ mais pas l’inverse). Le C++, c’est donc tout le C, mais avec des notions supplémentaires (templates, objets, surcharge de fonctions…). Le C et le C++ sont définis par les normes ANSI/ISO (ce sont des organismes de normalisation, en gros ils donnent les règles que doit respecter un compilateur pour pouvoir être présenté comme un compilateur C ANSI ou C++ ANSI).

Voici donc les IDEs majeurs (sous Windows) :

Visual C++ de Microsoft : il est payant, très utilisé, et est compatible avec la plupart des librairies (j’expliquerai plus tard). Il est spécialement pratique à utilisé accompagné de Visual Assist (payant). La version 6.0 est « indépendante » alors que la version 7.0 est intégrée à Visual Studio.NET (il vous faudra un PC bien puissant pour utiliser celle-ci…)

Dev-C++ de Bloodshed Software : il est gratuit et sous licence GPL open source, vous pouvez le trouver sur http://www.bloodshed.net. Cet IDE s’appuie sur le compilateur MinGW, qui est une version Windows du compilateur pour Linux GCC. Cet environnement est très bien aussi et est aussi compatible avec la plupart des librairies (notamment celles que nous utiliserons plus tard). Prenez la bêta 5.

Borland C++Builder : il est payant (trop d’ailleurs ?) mais est fourni avec la librairie VCL, ce qui lui donne un avantage non négligeable sur les autres (en gros il permet de créer des interfaces graphiques (fenêtres, boutons… de Windows) très facilement). Cependant, Borland met à disposition de tous le compilateur de la version 5.5 de C++Builder, sans l’environnement de développement. Qu niveau des librairies, il me semble qu’il est possible d’importer celles de Visual C++.

Cf http://www.borland.com/products/downloads/download_cbuilder.html

Borland C++BuilderX : c’est le tout nouvel IDE de Borland, qui semble très prometteur. Vous pouvez l’associer à n’importe quel compilateur (MinGW, le compilateur de Borland, celui de Visual C++…)

LCC-Win32 : c’est un vieil IDE reposant sur le compilateur LCC; il est gratuit mais n’est plus développé et ne compile que le C (pas le C++). Pour les librairies, c’est comme pour Borland, on peut importer celles de Visual C++.

Il existe encore d’autres IDEs/compilateurs C++ (Digital Mars C++, Symantec C++, Watcom C++, CodeWarrior…), mais je vous ai cité les principaux compilateurs pour Windows (Win32). Cependant, il y a aussi des compilateurs pour MS-DOS (Turbo C++, DJGPP) mais ceux-ci ne seront pas compatibles dès lors que nous voudrons utiliser des librairies pour Win32. Cependant, vous pouvez très bien les utiliser pour ce tutorial sur le langage C, vu qu’ils respectent les normes ANSI/ISO.

Dans la suite de ce tutorial, je considérerai que vous utilisez Visual C++ 6.0 ou Dev-C++ 5 bêta. Pour les autres, les explications doivent être à peu près semblables.

II) Premier programme

Bon, c’est pas tout ça, mais faudrait commencer ! Ouvrez votre IDE, et créez un nouveau « projet » (un projet rassemble tout ce qui concerne la création d’un programme) (Fichier ->Nouveau -> Projet ou File ->New ->Onglet Project, enfin vous connaissez ). Le projet sera de type Win32 Console Application sous Visual C++ 6.0 et Console Application (langage C) sous Dev-C++. Donnez-lui un nom (« Hello ») et cliquez sur OK. Sous Visual C++ 6.0, choisissez « An empty Project ».

Maintenant que votre projet est créé et ouvert, vous devez y ajouter un fichier « hello.c » (sous Dev-C++ vous avez déjà un fichier main.c, faites un clic droit sur l’onglet et choisissez Fermer; n’enregistrez pas). Pour cela, sous Visual C++ 6.0 ouvrez l’onglet File View et faites File ->New -> Onglet Files ->C++ Source File. Appelez-le hello.c. Si vous regardez dans l’arborescence de l’onglet File View vous verrez que le fichier hello.c est bien ajouté dans les Source Files. Les dossiers que vous voyez n’existent pas réellement, ils permettent de séparer les fichiers pour pouvoir mieux les repérer. Pour les utilisateurs de Dev-C++ : faites Fichier -> Nouveau -> Fichier Source -> Ajouter au projet? Yes -> enregistrez-le sous hello.c.

Bon, si vous avez suivi jusque là, on peut enfin commencer à coder ! Recopiez dans hello.c ceci (en respectant majuscules/minuscules !) :

// hello.c
#include "stdio.h";
 
int main()
{
   printf("Hello World !");
   getchar();
   return 0;
}

Bon, ne vous effrayez pas, vous comprendrez tout ça ?. Maintenant, sous Dev-C++ faites Exécuter ->Compiler et exécuter. Sous Visual C++, vous devez voir dans une barre d’outils « Win32 Debug » : changez ça en « Win32 Release »; ça permettra au compilateur de ne pas inclure d’informations de débogage dans l’exécutable final : votre .exe sera moins gros. Faites Build -> Build Hello.exe, puis cliquez sur le point d’exclamation rouge pour commencer l’exécution de votre programme.

Que fait votre programme? Il affiche dans une console MS-DOS (bien que le programme soit un programme Win32, je le rappelle) « Hello World ! » puis attend que vous appuyez sur Entrée pour quitter. Aux utilisateurs de Visual C++ : Vous verrez écrit « Press any key to continue », ceci est dû à l’environnement, si vous exécutez votre .exe depuis l’explorateur Windows ce message ne s’affiche pas.

Bon, maintenant on passe à l’explication. Avant tout, il faut savoir que l’exécution du programme est séquentielle : les lignes que vous tapez sont des instructions, et celles-ci sont exécutées les unes après les autres, dans l’ordre dans lequel vous les avez écrit.

Commençons par la 1ère ligne : « //Hello.c ». Vous pouvez très bien l’enlever, le programme se compilera de la même façon : c’est un commentaire. Vous pouvez marquer ce que vous voulez à la place de « Hello.c », je marque cela juste pour connaître le nom du fichier. En C et en C++, tout ce qui suit « // » jusqu’à la fin de la ligne est un commentaire, de même que tout ce qui est placé entre « /* » et « */ » (sans les guillemets).

Voyons la 2ème ligne: « #include<stdio.h> ». Cette ligne n’est pas vraiment une instruction : c’est une directive du préprocesseur comme toutes celles débutant par un #. Ne vous effrayez pas ! Bon, pour simplifier, on dira que c’est elle qui vous permet d’écrire printf et getchar par la suite sans provoquer d’erreur à la compilation. Je rentrerai dans les détails plus tard, pour l’instant sachez qu’il faut la placer en début de fichier.

Maintenant, la 3ème ligne : « int main() ». Celle-ci dénote le début du bloc principal : c’est là que commencera l’exécution de votre programme, tout ce qui suit main() est exécuté en 1er. Un bloc d’instructions est délimité par { et }. Notre programme ne comporte qu’un seul bloc d’instructions.

« printf(« Hello World ! »); » : ceci est notre 1ère instruction. printf commande l’écriture à l’écran de texte. On dit que printf est une fonction, et que la ligne « printf(« Hello World ! »); » est un appel à la fonction printf. Un appel de fonction est toujours composé du nom de la fonction (printf), d’une parenthèse ouvrante, d ‘ « argument(s) » (le « Hello World ! ») et d’une parenthèse fermante. Et le point-virgule? Il délimite la fin d’une instruction. L’oubli d’un point-virgule est une erreur très fréquente en programmation en C, et elle est dure à repérer pour les débutants : faites attention !

 » getchar(); » : ceci est un autre appel à une fonction, la fonction « getchar ». Vous remarquerez qu’on ne lui passe pas d’arguments, car elle n’en a pas besoin; c’est elle qui attend l’appui sur la touche Entrée. En effet, recompilez votre programme sans cette ligne (mettez-la en commentaire) :

// hello.c
#include "stdio.h";
 
int main(
{
   printf("Hello World !");
   //  getchar();    // La ligne est mise en commentaire, elle n'est pas compilée.
   return 0;
}

A l’exécution du programme (hors IDE, je veux dire pour les utilisateurs de VC++, ouvrez votre exécutable depuis l’explorateur Windows), le programme quitte avant que vous ayez pu lire quoi que ce soit ! Voilà pourquoi il vous faut rajouter l’appel à la fonction getchar().

Enfin, le « return 0; », placé dans le bloc main(), indique la sortie du programme (il quitte). Si vous le placez avant getchar() par exemple, getchar() ne sera pas exécuté car le programme aura quitté avant. Le } délimite la fin du bloc main (principal).

Ouf ! Voilà, vous avez terminé le 1er tutorial sur la programmation en C, maintenant essayez de changer l’ordre des lignes, de rajouter des appels à printf avec un texte différent (à oui, au fait, j’ai oublié pour les guillemets dans printf : ils montrent que l’argument passé à printf est une chaîne de caractères, un texte quoi, vous verrez ça plus en détail + tard, encore une fois )

Pour toute remarque, conseil, correction : funto66 at gmail.com

Cet article provient du tutorial publié par Funto le 30/07/2005 sur l’ancien site de Coder-Studio.

Dans ce tutorial, je vais tenter d’aborder le design pattern factory (fabrique pour les anglophobes).
A mon habitude, nous allons retrouver la même ligne directrice que pour les précédents tutoriaux.
Je vais commencer par expliquer brièvement le principe de la factory, ensuite en découlera une première implémentation en C++ et enfin on essayera de rendre ça le plus générique possible.

Definition

La factory est en fait un objet dont le rôle est de créer des instances d’autres objets.
Dans un modeleur par exemple, on pourrait avoir une factory d’objets géométriques qui servirait à créer des sphères, cônes, etc…

Première Implémentation :

Nous allons prendre le cas d’une factory d’objets géométriques dont le but est de fournir des objets héritant de l’interface Shape.

class Shape{...};

De plus, nous avons dans l’application des objets implémentant l’interface shape comme Sphere, Cone, ….

class Sphere : public Shape{...};
class Cone   : public Shape{...};

Une premiere implémentation de la factory pourrait donner ceci :

class ShapeFactory{
public:
  Shape * createSphere(void){
    return new Sphere();
  }
  Shape * createCone(void){
    return new Cone();
  }
};

Ce qui donne à l’utilisation :

ShapeFactory factory;
 
Shape * sphere = factory.createSphere();
sphere->display();

Cette première approche fonctionne, mais a le désavantage de rendre le code de la factory dépendant de l’application.
Nous allons tenter de définir la factory de manière générique (template ) afin de pouvoir la réutiliser dans d’autres cas.

On templatise un peu ?

On peut voir la factory comme une map : à une clef donnée, on associe un type d’objet a créer.

On devrait donc avoir au niveau des paramètres de la factory générique, le type de la clef et le type d’objet que la factory retourne. Ceci nous donne le prototype suivant :

template  class Factory;

Et à l’utilisation :

Factory shapeFactory;

De plus, on s’attend à pouvoir écrire quelque chose du genre :

Shape *sphere = shapeFactory.create("Sphere");

On enrichit donc notre esquisse de la classe :

template  class Factory{
public:
  Object * create(key);
}

Pour le corps de la méthode create, nous avons besoin de réellement créer une instance d’un objet que la factory ne connait pas. Comme ceci ne peut pas se faire par magie, il va falloir enregistrer dans la factory une fonction capable de créer chaque objet et les associer à une clef.

template  class Factory{
public:
// un pointeur de fonction qui retourne un Object*
  typedef Object *(*Creator)(void);
 
  map _registeredCreator;
 
  bool register(Key key, Creator creator){
    if(_registeredCreator.find(key) != _registeredCreator.end())
      return false; // la clef est deja utilisé
    _registeredCreator.insert(pair(key, creator));
    return true;
  }
 
  Object * create(Key key){
    Object *object;
    Creator creator;
    map::iterator it;
 
    // on cherche le pointeur de fonction associé a la clef
    it = _registeredCreator.find(key);
    if(it == _registeredCreator.end())
	return NULL; // on ne l'a pas trouvé
 
    // on récupère le pointeur de fonction
    creator = (*it).second;
    // on appelle la fonction pour créer un nouvel objet
    object = (*creator)();
    // on retourne l'objet
    return object;
  }
};

Regardons maintenant comment utiliser tout ça :

// des fonctions de création d'objets
Shape *createSphere(void){return new Sphere;}
Shape *createCone(void){return new Cone;}
 
Factory shapeFactory;
shapeFactory.register("Sphere", createSphere);
shapeFactory.register("Cone", createCone);
 
Shape *sphere = shapeFactory.create("Sphere");

Ici le problème reste la nécessité d’avoir des fonctions « C » à mettre dans le code, et de devoir enregistrer ces fonctions à la main. Donc à chaque ajout d’objet géométrique devoir aller remodifier ce code d’initialisation de la factory.

Pour rendre ceci un peu plus propre, nous allons définir ces fonctions en statique dans chaque objet géométrique et se servir de l’initialisation des CRT pour enregistrer les fonctions automatiquement.

// sphere.h
class Sphere : public Shape{
  static Shape* create(void);
  static bool register;
};

// sphere.pp
#include "ShapeFactory.h" // on considère que la shapeFactory est une variable globale accessible par ce fichier
 
Shape * Shpere::create(void){
  return new Sphere();
}
// auto enregistrement :
bool Sphere::register = shapeFactory.register("Sphere", Sphere::create);

Il est possible d’utiliser des macros pour encore réduire la taille du code à produire.

Petite explication : au lancement du programme, la variable statique register est initialisée. Cette initialisation passe par l’appel de la methode shapeFactory::register qui enregistre le « create ».

Conlusion:

J’ai ici présenté l’implémentation « générique » d’une factory; pour pousser un peu plus l’exemple du modeleur, on peut imaginer que l’interface Shape permette de décrire des attributs (association nom / valeur). Une sphère par exemple aura un paramètre de type float nommé « radius ».
Notre petite application graphique aura à parcourir les entrées de la factory pour y découvrir tous les objets « instanciables » et fournir à l’utilisateur un panel de boutons pour créer des Shapes.
A partir de là, à chaque Shape créé, elle pourra construire une boîte de dialogue d’édition adaptée à l’objet (à la mode 3DS), SANS en connaitre le type réel.

Pour aller plus loin :

Il est possible de s’abstraire de l’écriture de la fonction create statique dans les classes en utilisant les templates pour créer des objets dont le rôle est de remplacer la fonction statique.

A l’utilisation cela donne quelque chose comme :

bool Shape::register = shapeFactory.register ("Shape", Creator() );

Il faut pour cela modifier un peu la classe factory, mais je vous le laisse en exercice (j’ai toujours révé de dire ça un jour…)

Dernier point, on peut utiliser les singleton pour ne pas avoir à stocker la factory dans une variable globale.

joyeuses fetes

Twxs

Cet article provient du tutorial publié par Twxs le 24/12/2004 sur l’ancien site de Coder-Studio.

Introduction

La relation Observer/Observable est un concept assez simple, le principe repose sur le fait de pouvoir informer automatiquement des objets (Observeurs) des modification d’un autre (l’Observable). Nous prendrons comme cas « d’école » l’exemple d’un VU mètre system. On supposera avoir une classe CPU permettant de connaitre la charge cpu, une classe FileSystem donnant accès aux informations concernant les disques et enfin, une classe charger d’afficher l’état de notre machine i.e. la charge CPU et l’occupation des disques.

La classe Observer
L’observer est un objet « simple », être observeur defini uniquement le fait de pouvoir être mis a jour par un objet extérieur. Ceci se traduit par avoir une méthode de type update.
Ceci nous mène à une premiere définition de l’interface Observer :

struct Observer {
  virtual void update() = 0;
};

Rendre un objet observateur d’un sujet, se traduira alors par une implémentation de cette interface. ex :

class VUMeter : public Observer {
  void update(void){
    // mis a jour car un sujet a changé d'etat
  }
};

La première limitation de cette proposition vient du fait que l’on ne prend pas en compte le type du sujet observe dans l’interface. Ceci a l’utilisation, obligera en plus d’hériter de l’interface, de stocker dans ses attributs une référence au sujet. ex :

class VUMeter : public Observer{
private :
  Subject *subjet;
public :
  void update(void){
    // subject a change
    subject->getValues()...
  }
};

une première solution, est de passer en paramètre la classe Observable dans la méthode update.

void update(Observable *subject){
  //
}

cette solution est presque viable, mais va obliger :

• soit a implementer dans l’observable, une interface generique pour récuperer les information d’un sujet « abstrait ». Il nous faudra récuperer la charge CPU, l’occupation du disque…
• soit a « dynamic_caster » le sujet de type Observable en son reel type

void update(Observable *subjet){
  if((CPU *cpu = dynamic_cast(subject)) != NULL){
     cpu->getLoad()...
  }
  else if((FileSystem* fs = dynamic_cast(subject)) != NULL){
    fs->getFreeSpace();
  }
}

Cette solution n’est pas des plus élegantes. Une derniere alternative plus « propre » serait de posseder une méthode update prenant en paremetre un CPU* et une autre prenant un FileSystem*

void update(FileSystem*);
void update(CPU*);

Cette solution nous garantie une separation propre du code. Pour l’implementer, nous allons devoir passer par l’utilisation de template. Le principe : spécifier le type reel observé dans l’interface Observer

template
struct  Observer{
  virtual void update(Subject *) = 0;
};

Et voici maintenant l’utilisation :

class VUMeter :
  public Observer,
  public Observer{
public:
  void update(FileSystem* fs){
    fs->getFreeSpace(...
  }
  void update(CPU* cpu){
    cpu->...
  }
};

Et voila le travail, nous avons un observeur capable d’observer plusieurs sujets. Ils nous reste a implémenter l’autre partie : l’Observable

La classe Observable
Nous devons ici definir la classe de laquelle vont deriver CPU et FileSystem pour être observable. Les besoins d’un Observable sont :

• lui attacher un observateur
• le détacher
• notifier tous les observateurs
• stocker ses observateurs

class Observable{
  std::set _observers;
  void attach(Observer *o); // insertion dans le set
  void detach(Observer *o); // suppression du set
  void notify(void){ // updater tous les observers dans le set
    ...
      obs->update(...)
  }
};

Cette implémentation ne fonctionne pas a cause de la « templatisation » de la class Observer qui prend, déjà, pour la méthode update le type réel du sujet (ex : FileSystem) mais aussi par le fait que les observeurs n’héritent pas de Observer, mais Observer.
Dans la classe Obserable, nous devons donc connaitre le type reel du sujet.
Encore une fois les template vont permettre de nous en sortir :

template  class Observable
{
public:
  ~Observable(void);
  void attach(Observer *o);
  void detach(Observer *o);
  void notify(void);
private:
  std::set<Observer *> _observers;
};

A l’utilisation, ceci donne :

class FileSystem : public Observable{
   ...
   void some_func(){
     ...
     notify(); // on change d'etat, informer les observateurs
   }
   ...
};
 
VUMeter vum;
 
FileSystem fs;
CPU cpu;
 
cpu.attach(&vum);
fs.attach(&vum);

Et Voilà, c’est fini!

Cet article provient du tutorial publié par Twxs le 03/11/2004 sur l’ancien site de Coder-Studio.

Prenons un exemple:

glEnable(flag);
....
glDisable(flag);

C’est ici l’utilisation normale d’opengl. Rien de compliqué mais c’est exactement ce qu’on veut éviter pour ne pas alourdir le code…

Un premier pas vers le RAII

struct Enable{
   Enable(GLenum flag){
      glEnable(flag);
   }
 
   ~Enable() {
      glDisable(flag);
   }
};

Puis on l’utilise dans un bloc, comme suit :

{
   Enable active(flag);
   ...
}

Comme on peut le voir ici, Le principe est très simple : Lors de la création de l’instance de la structure Enable, on execute via le constructeur la commande opengl glEnable(). Lorsque l’on sort de la zone de portée de cette instance (ici, le bloc {}), elle est détruite. Il y a donc appel du destructeur dans lequel on a placé la commande glDisable().

Conservation et propreté

Cette première version fonctionne, mais imaginons qu’avant le bloc le flag soit deja activé : à la sortie il sera desactivé. Pour s’assurer de la récuperation d’un contexte identique, nous devons modifier notre classe pour mémoriser l’etat courant avant sa modification.

On procède de cette manière :

struct Enable {
 
   GLboolean state;
   Enable(GLenum flag) {
      state = glIsEnable(flag);
      // State contient l'état actuel du flag
      // Si le flag est deja activé il n'est pas necessaire de le réactiver
      if(!state)
         glEnable(flag);
   }
 
   ~Enable() {
      // Si le flag était désactivé à la création de la classe on le désactive à nouveau
      if(!state)
         glDisable(flag);
   }
};

Ici nous sommes : L’utilisation de l’objet conserve le contexte opengl.

Cas d’usage : factorisation du code à l’aide des templates

Prenons le cas suivant :

{
   Enable lighting(GL_LIGHTING);
   Enable light0(GL_LIGHT0);
   Enable depth(GL_DEPTH_TEST);
 
   // ...code
}

Supposons que ces trois appels reviennnent régulierement : l’héritage multiple devrait nous permettre de factoriser ce code en regroupant le tout en une seule et même classe. Mais le probleme ici, c’est que nous avons une unique classe pour tous les états. Comme nous ne pouvons pas heriter plusiseurs fois de la même classe, il va falloir trouver une autre solution.

Et celle qui s’y prête le mieux reste l’utilisation de templates :

template struct Enable {
   GLboolean state;
   Enable() { //plus de paramètre au constructeur
      state = glIsEnable(Flag);
      // state contiend l'etat actuel du flag
      // si le flag est deja active il 'est pas necessaire de le reactiver
 
      if(!state)
          glEnable(Flag);
   }
 
   ~Enable() {
      if(!state)
      glDisable(Flag);
   }
};

En « templetant » la classe Enable, nous obtenons une classe différente pour chaque paramètre du template, et donc pour chaque flag.

Au niveau de l’utilisation,

Enable depth(GL_DEPTH_TEST);

deviendra :

Enable depth;

Mais surtout, ceci va nous permettre de factoriser des états.
Reprenons les trois appels redondant de notre programme :

Enable lighting;
Enable light0;
Enable depth;

En templatant, on peut créer une structure héritant de chaque classe :

struct MonContext :
   Enable ,
   Enable ,
   Enable
{
};

Nous obtenons une structure ayant les propriétés de 3 classes parents. Et surtout, à la creation de l’objet les 3 constructeurs des parents seront appelés, et réciproquement à la destruction.
On peut donc se contenter de ceci :

{
   MonContext ctx_light;
}

Conclusion

Voilà pour l’utilisation des RAII : Rien de très complexe dans la théorie ou dans la pratique. C’est par contre un puissant outil qui devrait rapidement devenir indispensable à la clarté de tout programme conséquent.
Un grand merci à Twxs pour ce tuto !

Cet article provient du tutorial publié par Twxs le 03/10/2004 sur l’ancien site de Coder-Studio.