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

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.