Architecture Logicielle & Développement

Passage à Dotclear v2.1.6

Emmanuel Deloget — Wed, 10 Mar 2010 13:30:00 +0100

Il fallait bien que ça arrive un jour : le logiciel de blog sur ce site web est passé de la version 1.2.7 à la version 2.1.6. Et ça n'a pas été sans heurts...

Il fallait bien que ça arrive un jour : le logiciel de blog sur ce site web est passé de la version 1.2.7 à la version 2.1.6. Et ça n'a pas été sans heurts...Premièrement, il manque encore plein de choses :

les images - ne vous affolez pas si un diagramme manque, il vont revenir d'ici quelques jours (le temps de les dépoussiérer et de les importer dans le nouveau logiciel de blog).
les notes des billets - je n'ai pas encore trouvé de plugins satisfaisant que vous permette de donner une note aux billets. Mais je continue de chercher (et si je ne trouve pas et bien je me lancerais dans l'écriture d'un tel plugin).
les tags - la technique que j'ai utilisé pour importer les billets n'a pas récupérer les tags associés. Je vais devoir me taper un peu de SQL pour réussir à faire ce que je veux, et ça devrait revenir dans les jours qui viennent.
les téléchargements - il va me falloir trouver une solution rapide pour les stocker. Dans l'idée, ils vont tous atterrir dans http://download.emmanueldeloget.com/, puisque ce site est maintenant la plateforme de stockage de tout ce qui se télécharge chez moi.

Pour une raison que j'ignore, l'import du blog s'est mal passé, et il m'a fallu ruser pour réussir à importer commentaires et autres billets. Dans un premier temps, j'ai créé un blog en local (et je l'ai paramétré au mieux). J'ai réussi à importer les données de mon blog en ligne dans ce blog local, et j'ai exporté la base de données en trois parties :

la structure de la base
les données
les contraintes sur la base

J'ai ensuite installé DC 2.1.6 sur la machine de mon hébergeur puis j'ai exporté la structure de la base de données créée (sans les contraintes). J'ai alors effacé les tables, et je les ai recréé grâce à cette dernière exportation. J'ai pu ensuite importer les données et recréer les contraintes.

Pourquoi cette opération délicate ? Principalement parce que si j'essaie d'importer les données dans les tables avec les contraintes, l'import ne fonctionne pas (une erreur SQL se produit à cause de contraintes non satisfaites).

Une fois les données importées, j'ai pu réinstaller les plugins manquants :

Noodles v0.5 (pour les gravatars dans les commentaires)
Adsense Management v0.6beta90 (devinez pourquoi). J'ai légèrement modifié le plugin pour spécifier le schéma de couleurs dont j'avais besoin.
Comments Wikibarre v1.0-RC3 (parce que ça va vous aider de pouvoir mettre en forme vos commentaires)
ArchivesWidget v1.0,, modifié par mes soins (pour afficher les archives de la même manière que précédemment). Sans la modification, les entrées sont triées par années, puis par mois, et le rendu n'est pas très agréable à l'oeil.
DC1 Redirect v1.0.1 (parce que le format d'URL a changé)
Tag Flash v1.0.2 (la boule avec les tags)

J'ai du écrire quelques petits widgets :

Xiti Personnal (pour afficher l'icône Xiti)
Google Search (pour afficher une barre de recherche Google en lieu et place de la barre de recherche fournie en standard)

Ces widgets sont regroupés (avec le widget amazon) dans un plugin Emmanuel Deloget Web Sites pour faciliter leur déploiement. L'archive est disponible ici.

Le thème utilisé est le même que précédemment, mis à jour pour DC 2.1.6.

Un point intéressant de DC 2, c'est le fait que les templates n'ont pas besoin d'être modifiés pour ajouter de nouveaux éléments dans la page. La notion de widgets permet d'afficher tout ce qu'on souhaite afficher dans les deux barres de navigation. DC 2 est donc infiniment plus ouvert que DC 1 (pour mon plus grand plaisir).

webvcs - vérification de l'identité en ligne sans transfert du mot de passe

Emmanuel Deloget — Fri, 05 Mar 2010 19:00:00 +0000

De nombreux systèmes - qu'ils soient des sites web ou des programmes se connectant à internet - ont besoin de vérifier l'identité de l'utilisateur. Souvent, cette identité est stockée dans une base de donnée qu'il faut alors interroger. Le problème est que pour interroger cette base de donnée, il faut au moins deux information : l'identifiant de connexion et le mot de passe qui lui est associé. Il est courant de voir des implémentations qui font transiter ce mot de passe en clair sur internet - avec tous les risques de sécurité que cette transmission d'information pose.

Cet article présente une méthode simple d'implémentation ne nécessitant pas le transfert en clair ou crypté du mot de passe, permettant ainsi l'authentification d'un utilisateur de manière plus sécurisée. Cette méthode est implémentée dans le logiciel en cours de développement webvcs, mais il peut aisément être porté vers une architecture de type client léger.

Implémentation

L'identification s'effectue en deux passes :

dans la première passe, le client interroge le serveur pour obtenir un identifiant lié à la connexion. Cet identifiant est lié à la certaines informations en provenance de la machine cliente (par exemple, son adresse IP).
dans la seconde passe, le client envoie le login de l'utilisateur ainsi qu'une clef de hashage créée à partir de l'identifiant de connexion et du mot de passe de l'utilisateur. Le serveur recalcule l'identifiant de connexion, récupère le mot de passe lié au login, et compare la clef de hashage reçue avec la clef de hashage qu'il calcule lui-même. En fonction du résultat de cette comparaison le client reçoit soit une erreur d'authentification, soit un cookie contenant un token d'authentification réussie - qui sera utilisé pour toutes les transactions suivantes entre le client et le serveur.

Dans webvcs, j'ai choisi d'utiliser l'algorithme de hashage SHA1 - pour sa simplicité, et parce que cette algorithme est implémenté dans de nombreux langages, y compris javascript, PHP (supporté de manière native), C et C++.

Considérations de sécurité

A aucun moment le client n'envoie le mot de passe en clair. De fait, il n'est pas possible d'intercepter ce mot de passe.
La longueur du mot de passe n'a pas d'influence sur la longueur de la clef de hashage. En choisissant un mot de passe suffisamment long, on peut éliminer les problèmes que peuvent soulever une attaque de type force brute.
Même si un attaquant intercepte le token d'authentification, il ne peut pas s'en servir puisque celui-ci est lié à la machine cliente. Par contre, si il est situé sur une machine qui partage ses informations de connexion avec la machine cliente (par exemple si il est situé derrière le même routeur NAT), il peut obtenir les mêmes droits que l'utilisateur connecté.

SHA1 et MD5 (les deux fonctions de hashage les plus utilisées) sont sujets à des collisions (voir cet article de X.Wang et H.Yu). Pour plus de sécurité, on peut leur préférer des évolutions plus récentes telle que SHA-256. En PHP, la fonction hash() vous permet de choisir l'agorithme de hashage parmi les algorithmes disponibles.

Conclusion

Cette authentification n'est pas une authentification complètement sécurisée et de fait, webvcs qui implémente cette technologie ne doit pas être utilisé dans un contexte où la sécurité est primordiale.

Elle est toutefois plus fiable qu'une authentification qui ferait passer le mot de passe en clair sur le réseau, ce qui, ramené aux intentions originelle du projet webvcs, est suffisant dans un premier temps. Le seul moyen d'obtenir une connexion sécurisée entre un client et un serveur reste le cryptage complet des échanges de données.

Notes sur l'implémentation sur un client léger

Pour une implémentation dans un client léger, il suffit d'un bon browser web supportant javascript et la librairie javascript présentée ci-dessus. Le même système peut être implémenté sur une unique page web car :

la première passe est automatique, les informations d'identification de la machine client pouvant être récupérée lors de la génération de la page de login ;
la seconde passe est effectuée par l'envoi de la requête de test lorsque l'utilisateur se connecte.

Comme dans le cas client riche/serveur, le token d'authentification est renvoyé au client léger sous la forme d'un cookie.

Plugin pour DotClear 2.1.6

Emmanuel Deloget — Mon, 01 Mar 2010 14:00:00 +0000

Note - ce billet a été posté originellement le mercredi 14 octobre 2009 à 11:30. La version courante du plugin amazon pour DC 2.1.6 est la v0.4.

J'ai ouvert un autre blog (qui parle de jeux de rôle, de romans et tout ça ; rien de bien intéressant pour le fan de technique que vous êtes). Afin de pouvoir afficher une jolie boite proposant un lien vers un livre particulier sur Amazon, j'ai développé un petit plugin pour DotClear 2.1.6. Ce billet le documente, et vous donne le lien pour le télécharger...

Installation

La dernière version de l'archive est stockée ici : http://download.emmanueldeloget.com/plugins/. L'installation du plugin est effectuée par l'interface d'administration (comme pour les autres plugins).

Utilisation

Ce plugin est un widget - pour l'activer, il suffit de déposer le widget dans l'un des bandeaux depuis l'interface d'administration du blog. Les options de configurations sont :

Serveur Amazon : le nom du serveur qui héberge la publicité (exemple: rcm-fr.amazon.fr)
ID partenaire : votre ID partenaire Amazon
MD (optionnel) : pour repérer la valeur de cette variable, allez sur Amazon et générez un lien pour un livre quelconque. Dans le code HTML proposé, repérez la chaine "&MD=valeur&". Récupérer la valeur précisée pour renseigner la variable MD.
Liste des ASINs : liste d'ASIN séparés par des virgules (,). Certaines pages Amazon présentent directement un ASIN, que vous pouvez directement copier dans la liste. D'autres pages présentent un ISBN. Dans ce cas, générez un lien pour cet ouvrage et repérez dans le code HTML la chaine "asins=valeur". Récupérez la valeur et ajoutez la à la liste.

L'ASIN de l'élément affiché est pris au hasard dans la liste proposée. Vous pouvez un exemple d'utilisation sur http://rpg.emmanueldeloget.com/.

Versions

0.1 : version initiale
0.2 : support de toutes les variables modifiables pour le paramétrage de l'affichage
0.3 : support des variables de couleur de bordure et cible pour l'ouverture du lien
0.4 : si MD n'est pas renseigné, la variable n'est pas rajoutée à l'URI généré.

webvcs - un système de contrôle de version sans serveur

Emmanuel Deloget — Thu, 25 Feb 2010 13:00:00 +0000

Pour mes projets personnels, je suis en train de développer un logiciel que j'ai nommé webvcs, et qui n'est autre qu'un SVCS (pour serverless version control system) composé de deux parties :

un client (fonctionnant sous Windows 32/64, mais le porter sous Linux ou Mac OS X ne devrait pas poser de problèmes)
un ensemble de scripts PHP pouvant s'installer sur n'importe quel serveur web autorisant l'exécution de scripts PHP 5.

Le but : héberger sur mon site web mes propres projets open source, sans avoir besoin de passer par un plateforme telle que codeplex, sourceforge ou google code.

Le fonctionnement, coté web

Les scripts PHP émulent un serveur VCS simple, capable de comprendre quelques notions de base :

import : importer un projet dans le système
get revision : récupère une version particulière d'un fichier
commit : enregistrer les fichiers modifiés sur le serveur web
branch : crée une branche.

Les trois notions manipulées sont, dans l'ordre de taille :

le fichier : c'est l'unité de base du système. Les fichiers sont pour l'instant stockés dans une base de donnée SQL (mysql pour l'instant, mais l'écriture d'un driver pour un autre SGBC ne me semble pas trop complexe), mais je pense développer un sous-système permettant l'utilisation de webvcs sur des serveurs sans accès à une base de donnée.

le travail (job) : lorsqu'un commit est effectué, il est nécessairement lié à une activité (activity) - qui peut être une évolution, une correction de bug, etc - pour produire un job. L'idée est de ne pas permettre un commit si ce commit n'est pas motivé par quelque chose. Les jobs sont gérés sur la base de transactions - un seul job peut être appliqué à la fois, ce qui permet d'assurer la possibilité de travail concurrentiel sur un même ensemble de fichiers. Bien évidemment, les activities doivent exister avant le commit pour que celui-ci puisse se faire.

la branche (branch) : un utilisateur travaille nécessairement sur une branche - que cette branche soit la branche principale (mainline) ou une branche secondaire (marquée par un label). Dès qu'il y a création d'un label, il y a création d'une branche - et inversement. Il est possible d'intégrer un job dans une autre branche que celle dans laquelle il a été produit.

Le tout fonctionne sur la base d'un protocole web très simple inspiré par les technologies du type "web service" et que je documenterais plus tard (ce qui, je l'espère, autorisera la création de versions ASP.Net de webvcs).

Le fonctionnement, coté client

L'application cliente webvcs est relativement simple. Elle ne comporte qu'un nombre réduit de fonctions : connect/disconnect, import, get, commit, branch. La question de la sécurité est gérée sommairement via les commandes connect/disconnect (le connect a une durée de vie limitée à une dizaine de minutes d'inactivité, donc le disconnect n'est pas nécessaire dans la plupart des cas). Un hash est calculé à partir des informations d'identification et des informations liées à la machine cliente, ce hash étant systématiquement durant les dialogues entre le logiciel client et les scripts installés sur le serveur. Un saupoudrage de gestion pas trop idiote permet de s'assurer avec une "certaine certitude" que la personne dialoguant avec les scripts serveur est bien celle qu'elle prétends être. Point important : les mots de passe ne circulent jamais en clair sur le réseau.

Les autres actions sont assez triviales, donc je ne vais pas m'étendre sur le sujet.

Beta-testeurs ?

Le logiciel est en cours de développement. Il n'est pas mûr pour être testé, j'en suis à la phase de pré-alpha. Dès que j'entrerais dans une phase alpha (avec un produit suffisamment fonctionnel pour être testé et utilisé mais comportant encore des problèmes de stabilité voire des fonctions manquantes), je vous tiendrais au courant.

Idem pour ceux qui veulent rejoindre le développement : je les encourage pour l'instant à me faire part de leurs idées. Dès que le logiciel sera en pré-alpha, il apparaîtra comme par magie sur mon site web, et il sera utilisé pour continuer le développement sur lui-même (lire : webvcs sera utilisé pour héberger le projet webvcs ; c'est la raison pour laquelle j'ai besoin de m'assurer qu'il fonctionne suffisamment avant de le lâcher dans la nature...)

En conclusion : dès que j'ai quelque chose à vous dire sur le projet en cours, je mettrais à jour ce blog. Vous n'avez donc qu'à le suivre régulièrement pour être informé de l'avancement du projet :)

Le futur standard C++ : les templates variadiques

Emmanuel Deloget — Mon, 08 Feb 2010 14:00:00 +0000

Oui, je sais, variadique n'est pas un mot très franchouillard (et franchouillard n'est pas trouvé par le dictionnaire de Firefox, qui me propose antibrouillard à la place). Il faut toutefois bien trouver quelque chose. Les fonctions à un argument sont des fonctions monadiques. Une fonction à plusieurs arguments est dite polyadique. Alors utiliser le néologisme "variadique" pour parler d'un nombre d'arguments variable ne me choque pas vraiment - d'autant plus que ce néologisme est très utilisé dans la communauté C / C++.

Outre cette digression, reste à expliciter le but de cet article. Comme les articles précédents de la série (et certains commencent à être ancien), cette saillie technique va tenter de vous donner quelques informations d'importance concernant cette nouveauté du futur standard C++ - l'une des plus importante, si vous voulez mon avis.

L'Existant

Afin de bien saisir toute la puissance de ce nouvel outil, il convient de faire le tour des solutions existantes. A l'heure actuelle, notre bon vieux standard datant de 1998 et amendé en 2003 se contente de définir une notation simple pour gérer tout ce qui est fonction et macros variadiques : les célèbres "trois petits points" (...) qu'on retrouve par exemple dans la définition de std::printf :

namespace std {
  int printf(const char* format, ...);
}

Cette déclaration signifie que la fonction prends au moins un argument (la chaîne de formatage) mais qu'on peut lui en spécifier d'autres. Le problème principal est qu'il est impossible de connaître le type de chaque argument. Pour pouvoir les traiter correctement, on doit spécifier un certain nombre de codes dans la chaine de formatage. C'est dangereux, et loin d'être résistant à l'erreur, ainsi que le code suivant le montre :

int i = 0;
std::printf("%s est en fait du type int", i);
// crash, car printf() va tenter de transformer 0 en un pointeur vers une 
// chaîne de caractère ; or 0 est le pointeur null...

Ce code ne peut pas être vérifier par le compilateur, qui au maximum pourra se contenter de lever un warning - mais pas une erreur, tant votre légendaire sagacité lui est précieuse - après tout, t peut très bien contenir une adresse valide pour une chaine de caractère - bien que cela soit improbable et certainement en dehors de la norme C++ (qui ne spécifie pas de conversion possible entre un type intégral et un pointeur).

Bref, ce n'est pas génial, mais ça tombe en marche suffisamment souvent pour qu'on le considère avec bienveillance.

Au niveau des arguments de templates, rien n'existe - donc le problème est à priori réglé. A priori seulement, car le TR1 définit de nombreux types template qui peuvent prendre un nombre quelconque d'arguments : std::tr1::tuple<> est un excellent exemple. Comment écrire le code permettant de créer un tuple quelconque alors que le langage impose que le nombre d'arguments du type template soit connu ? Les concepteurs de boost et de la librairie standard GNU sont ingénieux : un savant mélange de macros, une bonne dose d'utilisation du préprocesseur et hop, le tour est joué... pour un nombre maximum d'arguments. Pour simplifier, le code ressemble à :

#define N__ARGUMENT_COUNT 10
#include "definition_with_N_args.h"

#define N__ARGUMENT_COUNT 9
#include "definition_with_N_args.h"

...

Le fait est qu'une fois passé par le précompilateur, l'unité de compilation obtenue est une horreur sans nom. Elle comptera des milliers de lignes, et par conséquent sera extrêmement longue à compiler. En fait, pour certains cas particuliers dans le TR1, je soupçonne que le temps de compilation des fichiers headers n'est plus (et de loin) une fonction linéaire du nombre d'arguments qu'il est possible d'utiliser. Et puis on abeau dire : 10 arguments, c'est peut être assez pour régler un problème particulier. Pour en régler un autre, il en faudra peut-être 20, ou 30.

Ce problème est l'une des motivation principale de Douglas Gregor, la personne qui a formalisé la proposition des templates variadiques pour le C++ - et dont j'ai honteusement volé le diagramme ci-dessus.

Bref, cet court état des lieux démontre assez clairement que les solutions existantes sont loin d'être optimales. Il était temps de faire quelque chose...

Variadic templates : la proposition N1603 (pfd)

La toute première proposition de Douglas Gregor, Jaakko Järvi et Gary Powell décrivant les templates variadiques a été publiée en Février 2004 sous le numéro N1603. Elle présente une évolution majeure du coeur du langage en décrivant une syntaxe (encore approximative et remarquablement loin de ce qui a été adopté par le comité de normalisation) permettant l'utilisation d'un nombre de paramètres variable dans la définition d'une classe ou d'une fonction template. Il faut attendre septembre 2006 (proposition N2080) pour commencer à voir ce qui deviendra la syntaxe officielle. Une fois les bases solidement établies, les propositions s'intéressent à la formulation de cette nouvelle fonctionnalité de manière à l'intégrer à la norme C++. Se suivent les proposition N2152, N2192 et N2242 en avril 2007. Cette dernière version sera à peine remaniée avant d'être intégrée au draft du standard C++ en le mois suivant (voir N2283: Editor's Note. Depuis cette date, peu de chose ont véritablement changé, si ce n'est la syntaxe de l'opérateur sizeof...() associé.

Nous allons étudier ce qui est présenté dans la dernière version du draft du standard - N3000.

La concept maître des templates variadiques est la notion de paquet de paramètres (parameters pack dans le texte du standard ; nous allons simplement utiliser l'acronyme PP pour parler d'eux). Les PP sont intimement liés à une syntaxe particluière mettant en oeuvre les trois caractères ... déjà utilisé pour signifier un nombre variable d'arguments dans la déclaration d'une fonction C.

Prenons les déclarations suivantes :

// déclaration d'une classe template prenant un nombre variable de types en argument
template <class... Args>
class C { };

Dans cette déclaration, on crée un PP de nom de Args. Ce PP, on peut en obtenir la taille grâce à l'opérateur %%sizeof...()%% qui prends en paramètre un PP et renvoie un std::size_t qui correspond au nombre d'entités qu'il contient. Si on déclare C<int,double,long>, on a la relation sizeof...(Args) == 3 dans la portée de C.

Un PP peut être "dépaqueté" grâce à ... qui agit dans ce cas comme un méta-opérateur recréant la liste d'argument.

template <class... Args>
struct C { 
  static const std::size_t size = sizeof...(Args); 
};

template <class... Args>
struct D {
  static const bool has_two_args = C<Args...>::size == 2;
};

Dans ce code, l'expression Args... reconstruit la liste d'arguments complète de manière à la passer à la définition de C.

On peut se servir de cette propriété pour récursivement vider le PP. Par exemple :

// pré-déclaration de C
template <class... Args> struct C;

// plus de paramètre : fin de la récursion
template <> 
struct C<> { };
// récursion : C<T,Args...> hérite de C<Args...> 
template <class T, class... Args>
struct C<T, Args...> : public C<Args...> {
  T value;
};

Si on analyse ce code et ce qui se passe lorsqu'on instancie C avec les paramètres <int,float,long> :

C<int,float,long> définit une variable value de type int et hérite de C<float,long>
C<float,long> définit une variable value de type float et hérite de C<long>
C<long> définit une variable value de type long et hérite de C<>.
C<> stoppe la récursion.

Au final, On se retrouve avec un type définissant 3 variables, une de chaque type passé en paramètre.

Lorsqu'on défini une fonction prenant un nombre variable d'arguments, on joue en fait avec un ou plusieurs PP.

template <class... Types>
void function(Types... values) { }

Cette définition fait intervenir deux PP : Types (une liste de type) et values (une liste de valeurs). values et Types sont liés, puisque le type de chacun des paramètres de la fonction va se retrouver dans le PP Types.

Grâce à cette notion de PP et grâce à la syntaxe relativement simple des templates variadiques, on peut réécrire une version type-safe de la fonction printf() :

void printf(const char* format)
{
  while (*format) {
    if (*format == '%') throw std::exception("not enough arguments provided");
    std::cout << *format;
    ++format;
  }
}

template <class T, class... Args>
void printf(const char* format, const T& value, const Args&... args)
{
  while (*format) {
    if (*format == '%') {
      // on peut passer le caractère donnant le type de la valeur
      // puisque celui-ci est automatiquement déduit pas std::cout. 
      ++format; 
      std::cout << value;
      printf(format, args...);
    } else {
      std::cout << *format;
    }
    ++format;
  }
  throw std::exception("too many arguments provided");
}

Encore une fois, la notation ... nous a permis de dépaqueter les PP args et Args ; encore une fois, nous avons utilisé la récursion pour dépiler progressivement les différents arguments des deux PP. Une petite nouveauté toutefois : dans la définition de la version variadique de printf(), on voit qu'on a utilisé la notation const Args&... args. Cette notation permet bien évidemment à dire que chaque argument du PP args est une référence constante vers un type de du PP Args.

Conclusion

Bien entendu, la librairie standard va profiter de cette nouvelle notation - notamment ceux des types définis dans le TR1 qui utilisent un nombre variable d'arguments (std::tr1::tuple<>, std::tr1::function<>...). Dès que vous allez devoir travailler avec un ensemble variable d'arguments, vous allez pouvoir utiliser les templates variadiques de manière à vous assurer que vous contrôlez correctement le type des paramètres utilisés. Cette solution simple à mettre en oevre va limiter les problèmes liés aux fonctions variadiques définies dans le standard C et reprises dans le standard C++ de 1998.

A noter que le support des templates variadiques commence à faire son apparition dans les compilateurs du marché. Si Visual Studio .Net 2010 beta 2 ne semble pas les supporter, les dernières versions de GCC (notamment la version en cours de développement gcc 4.5) proposent un support expérimental - activé par l'option --std=c++0x en ligne de commande. Vous pouvez donc vous amuser à en tester les finesses.

const X& x ou X const& x ? (et autres amusements)

Emmanuel Deloget — Thu, 04 Feb 2010 20:00:00 +0000

Parce que ces deux notations sont strictement équivalentes^[1], quelle est celle qu'il faut utiliser ? Est-ce qu'il est nécessaire de préciser que la surcharge d'une méthode virtuelle est elle-même virtuelle ? Faut-il utiliser les version post-fixée ou pré-fixées des opérateurs d"incrémentation/décrémentation ?

Je ne prétends pas vous donner une réponse définitive à ces questions, mais j'ai ma petite idée sur ce qu'il est préférable de faire.

Notes

[1] si vous êtes un peu rouillé sur le sujet et que vous lisez relativement bien l'anglais, vous pouvez vous reporter à la C++ FAQ Lite. Si vous êtes en plus rouillé en anglais, dirigez vous vers la FAQ de dvp.com

`const X& x` contre `X const& x`

En C++ comme en C, une déclaration se lit en anglais de la gauche vers la droite - sauf en ce qui concerne const. En cas de doute, rappelez vous que ce mot-clef modifie la mutabilité de l'entité qui le précède. Ainsi, X const* p est un pointeur vers un type X constant (c'est à dire que la valeur de p peut changer, mais pas la variable pointée par p), tandis que X* const p est un pointeur constant vers un type X (c'est à dire que la valeur du pointeur ne peut pas changer, mais la variable pointée par p peut être modifiée). Cette étrange étrangeté rends le code C++ un peu plus compliqué à déchiffrer - comme s'il n'était pas assez compliqué comme ça.

Élargissons un peu le problème. Une variable d'un type pointeur constant sur un type constant se déclare ainsi :

X const* const p;

De cette manière, p n'est pas modifiable (pointeur constant) et la variable pointée par p ne l'est pas non plus (type constant). Cette déclaration est assez lisible, car le mot-clef const est employé plusieurs fois. Qu'on enlève une seule occurrence du mot-clef, et la déclaration devient singulièrement plus complexe :

le code est moins clair, parce deux interprétation proches sont possibles si on ne connait pas assez bien son standard C++.
il y a une possibilité d'erreur lors de l'écriture du code, puisque l'inversion de * et const modifie le comportement du code de manière drastique.

On peut aussi définir la même variable ainsi :

const X* const p;

Cette définition est fonctionnellement équivalente, mais on la lit autrement - de gauche à droite, pour une fois : il s'agit maintenant d'une variable constante de type pointeur sur un type constant. D'autre part, si on enlève le premier const (et si on prends pour règle de ne jamais écrire X const* à la place de const X*), on réduit l'ambiguïté de la définition du type à la lecture puisqu'on ne confondra pas les deux formes X const* et X* const. Il est donc plus rassurant de définir une variable d'un type constant en préfixant le nom du type avec const plutôt que de le mettre en suffixe.

mais revenons à la question originelle : le problème ne se pose pas en ces termes puisque les références C++ sont nécessairement constantes : X& const n'a donc pas de sens en C++, et il est impossible de le confondre avec X const&. Mais puisqu'on préfère la notation const X* à X const*, il est logique et cohérent de préférer aussi const X& à X const&.

Je mets `virtual` ou pas?

Soit la classe B :

class B {
public:
  virtual void f() { }
}

Cette classe défini une méthode virtuelle B::f(). Si je crée une classe D qui hérite de B afin de surcharger f(), est-ce qu'il est nécessaire de préciser que f() est virtuelle ou non ?

Bien évidemment, non, ça n'est pas nécessaire : la méthode héritée est déclarée virtuelle implicitement par le compilateur si aucune déclaration explicite n'est présente. Ainsi :

class D : public B {
public:
  void f() { ... }
}

class D : public B {
public:
  virtual void f() { ... }
}

Sont des définitions strictement équivalentes. Dans ce cas, est il préférable de préciser explicitement que la méthode est virtuelle ou peut on se contenter du fait que le compilateur l'ajoute de manière implicite ?

Rappelons nous que le code que nous écrivons n'est pas destiné à la machine - mais aux autres programmeurs^[1]. La première qualité d'un code source, c'est sa lisibilité. Par définition, une information implicite est une information manquante - elle dégrade la lisibilité. Par conséquent, il est toujours préférable d'être explicite lorsqu'on écrit du code. Ajoutons donc ces 8 caractères - ce n'est pas comme si ça allait provoquer une usure prématurée de votre clavier...

`v++` contre `++v`

Au moins, celle-la est simple. Les réponses aux autres questions sont largement dépendantes d'un style de programmation - mais la réponse à cette question a des implications techniques définies.

Revenons quand même un peu sur les définitions : l'opérateur postfixé (v++) renvoie la valeur de v, puis incrémente la variable. L'opérateur préfixé ++v) incrémente d'abord la variable puis renvoie la valeur de celle-ci. Dans la plupart des cas, ces opérations d'incrémentation sont effectuées de manière unitaire, et on ne stocker même pas le résultat. Dans d'autres cas, le résultat nous importe. La réponse n°1 est donc triviale : si le résultat de l'opération a une importance pour vous, alors la question ne se pose plus. Soit vous avez besoin de l'opérateur postfixé, soit vous avez besoin de l'opérateur préfixé, mais en aucun cas vous ne pouvez vous permettre de prendre un de ces deux opérateurs au hasard.

Maintenant, il peut arriver que nous n'ayons pas besoin du résultat - seule l'opération d'incrémentation nous intéresse. Par exemple :

for (int i=0; i<size(); i++) {
  ...
}

est strictement équivalent à

for (int i=0; i<size(); ++i) {
  ...
}

(le même code est généré puisque la partie qui récupère la valeur de i est supprimée par le compilateur lors d'une passe d'optimisation).

A priori, les deux possibilités nous sont offertes, donc allons-y gaiment, et laissons la fonction std::rand() décider pour nous de la notation à utiliser. Sauf que (bien évidemment, il y a un "sauf que") l'équivalence stricte que j'ai avancé ci-dessus a une sévère limitation : elle n'est valide que si la variable incrémentée est un type scalaire entier ou sur un pointeur. Hors, le C++ nous permet de redéfinir l'opérateur ++() sur n'importe quelle classe.

L'exemple typique de redéfinition de ++() est l'itérateur du conteneur std::vector<>.

typedef std::vector<type>::iterator itype;

for (itype i=v.begin(); i!=v.end(); ???) {
  ...
}

Doit on remplacer ??? par un incrémentation de i préfixée ou postfixée ? La réponse nous viens de la définition déjà donnée de ces opérateurs, et de la façon dont le compilateur les traite lorsqu'ils ont utilisé.

Le compilateur est intelligent - mais il n'est pas pour autant le plus intelligent de vous deux. Lorsqu'il appelle une fonction, il ne peut pas se permettre de ne pas vider le code de cette fonction à des fins d'optimisation. Ce code peut avoir des effets de bord qu'il ignore, et qui peuvent modifier le comportement du programme. Par conséquent, il met le code complet de la fonction. Si ce code est inliné, il est possible qu'il puisse en éliminer une partie - mais c'est quand même plus difficile que ça en a l'air (ici, internal_state.advance() est l'opération qui effectue l'incrémentation sur l'état interne de l'instance).

Le code typique d'un opérateur ++ préfixé est le suivant :

{
  internal_state.advance();
  return *this;
}

Celui d'un opérateur postfixé correspondant est proche de :

{
  T copy = *this;
  internal_state.advance();
  return copy;
}

L'opérateur postfixé, de part sa définition, a besoin de faire une copie de l'état précédant l'incrémentation - de manière à pouvoir retourner cet état. Sur des objets non triviaux, cette opération peut être coûteuse. Par conséquent, l'opérateur préfixé - qui n'a pas besoin de faire cette copie - est sensiblement plus rapide que la version postfixée.

Lorsque le choix existe, on préfèrera dès lors utilisé la version préfixée de l'opérateur d'incrémentation (ou de décrémentation).

Notes

[1] il pourrait vous arriver des mésaventures du genre "analyse ce code source afin d'y trouver un bug, sachant que tu n'as pas d'accès aux librairies sur lesquelles ce code est basé et que tu ne peux pas le compiler". Avoir tous les outils et toutes les informations nécessaires à la résolution d'un problème est un luxe.

Visual Studio .Net 2010 (beta 2)

Emmanuel Deloget — Mon, 01 Feb 2010 14:00:00 +0000

Les versions beta des outils de développement de la gamme Visual Studio .Net 2010 Express sont disponibles au téléchargement sur le site de Microsoft depuis quelques semaines déjà. Pour information, le compilateur intégré à l'IDE a été mis à jour et comprends un certain nombre de constructions décrites dans le futur standard du C++ (le bien nommé C++0x, ou x est maintenant un chiffre hexadécimal).

Download des versions Express

Les autres versions beta (Pro, Ultimate, ...) sont aussi disponibles en téléchargement gratuit :

Download des versions complètes

Ces versions s'arrêteront de fonctionner le 30 juin 2010 (vous avez donc largement le temps de les tester...).

A noter que même si ce sont là des beta (attendez vous donc à quelques bugs), il n'en reste pas moins que les compilateurs proposés sont tout à fait valables. Le code généré peut ne pas être exempts de tout bug (ceci-dit, il est plus probable qu'il soit exempts de tout bug lié au compilateur ou aux librairies).

A noter aussi que j'utilise VS 2010 beta 1 pour compiler le code lié à la série d'articles Implémentation d'un système de règle pour un jeu de rôle. Je n'ai noté pour l'instant aucun problème majeur.

gcc sous Windows ? C'est possible, mais...

Emmanuel Deloget — Mon, 18 Jan 2010 14:00:00 +0000

... c'est pas simple. A la lumière de ma propre expérience, voici quelques points noirs (parce que les points pas noir, ça n'aide pas vraiment à faire un choix, n'est-ce pas) sur les plateformes de développement Windows basées sur GCC.

Cygwin

Le tout intégré. Cygwin est un environnement qui émule vaguement le fonctionnement d'un Unix-like sous Windows. Le coeur de cygwin, c'est sa DLL cygwin.dll qui permet à une application d'utiliser un grand nombre de services POSIX sous Windows.

C'est une bonne chose, surtout pour le portage d'applications ou de librairies. Ca ne va pas toutefois sans problèmes.

Installation

Le système d'installation est lourd et peu pratique à utiliser. A l'heure des gestionnaires de packages tel synaptic (Ubuntu), le système de cygwin montre d'ennuyeuses limites : ainsi, la sélection des packages est peu claire. Difficile de voir aussi quelles vont être les dépendances d'un package. Encore plus difficile, comprendre quel package est installé dans l'environnement. De mes tests, il est carrément plus simple de générer un répertoire cygwin en installant tout sur une machine avec un bon débit en download et de copier le répertoire cygwin sur une autre machine que de tenter de réaliser la même installation sur deux machines différentes. C'est petit...

/bin/sh, ou la lenteur faite programme.

La version cygwin du shell (en fait bash) est d'un lenteur à faire peur. Un script un peu chargé (par exemple un script généré par les autotools GNU) peut mettre jusqu'à plusieurs minutes à s'exécuter là ou le même script nécessite quelques secondes sous Linux. Je ne comprends pas vraiment très bien les raisons de cette incroyable lenteur, mais elle est là. Et bien évidemment, si le script est sur un disque partagé, le résultat est encore pire...

Des soupçons sur la stabilité ?

Les binaires que j'ai générés (à partir d'une code source en C++) souffrent tous du même mal : lorsqu'une exception est générée, le dépilement ne se fait pas correctement et la fonction abort() est appelée dès qu'on quitte la fonction qui génère l'exception. Impossible de contrer le problème, et impossible d'en comprendre la source. Je soupçonne un problème dans la librairie de GCC fournie avec la distribution - mais ça peut être aussi un problème liés aux options de compilation utilisées.

Une documentation peu explicite...

#include <iostream>

int main() 
{
 std::cout << "test" << std::endl
}

Ce code pourtant simple génère un warning au moment du link et le programme généré ne fonctionne carrément pas. C'est dommage, étant donné que cette option de compilation ésotérique est censée être activée par défaut sur cygwin. En cherchant bien, et malgré les informations données par GCC et l'aide en ligne de GCC, c'est l'option --enable-runtime-pseudo-relocs qu'il faut utiliser à l'étape du linkage.

Mingw

Mingw est le concurrent de cygwin. Enfin, pas vraiment puisqu'il résout un problème différent : la création d'applications standard Windows en utilisant le compilateur gcc (plutôt que le portage d'applications POSIX sur Windows).

Installation

L'installation de cygwin est complexe, mais au moins, tout est automatisé. En comparaison, l'installation de mingw est représentative de ce que j'appellerais "la volonté de faire compliqué". En fait, si on veut un système vaguement équivalent à cygwin, il faut installer mingw, puis msys, puis ceci, puis cela, ... Le tout en passant par des download et des lignes de commande. Rébarbatif. Surtout quand on sait que généralement, les outils dont un développeur a besoin changent peu. Incroyable que ni les gens de cygwin ni les gens de mingw n'aient pensé à créer une archive avec le système complet pré-installé, histoire de gagner du temps (c'est mon employeur qui serait heureux ; j'aurais gagné une bonne demi-journée de travail...)

/bin/sh... ok, on sait déjà.

Mais ça n'empêche pas de revenir dessus. Le bash de mingw est lent, bien qu'il semble un poil plus rapide que celui de cygwin. Il reste néanmoins trop lent. Est-il si incroyablement complexe que personne n'ai pris le temps de comprendre d'où venait cette lenteur ? Les commentaires sur Internet parlent de 3 à 10 fois plus lent. C'est un peu trop à mon goût.

"Faire semblant" et "faire semblant"

Cygwin fait semblant d'être un OS avec une couche POSIX et y réussit relativement bien. MSYS fait semblant d'être une couche POSIX et échoue lamentablement. Il fait un peu trop semblant en fait. Le résultat, c'est un système de fichier complètement incompréhensible (franchement, ls -l / ne renvoie aucun répertoire /usr, ce qui n'empêche pas de faire cd /usr - et de se retrouver dans /. Enfin, je crois. Enfin, je ne comprends rien.). Sans compter que le système de montage de partitions est obscure, que /home/$user ne pointe pas sur le répertoire de l'utilisateur mais sur un répertoire spécialement créé, etc. Agaçant au possible.

Conclusion

Ces deux produits sont matures techniquement, mais souffrent d'un certain nombre de défauts qui ne facilitent pas leur utilisation en entreprise. Et bien sûr, j'en ai besoin (sinon, est-ce que ça serait ne serait-ce qu'un peu drôle ? Je vous le demande...)

Noel, joyeux

Emmanuel Deloget — Sun, 27 Dec 2009 10:07:59 +0000

Je fais très court et sans complexe : ce billet est entre avec mon nouveau téléphone portable. Ça y est, j'ai enfin un iPhone. Si vous y voyez un certain esprit de contradiction avec un témoignage récent, ben, heu, il y a de ça, ok.

Quelques petites modifications...

Emmanuel Deloget — Fri, 18 Dec 2009 13:30:00 +0000

Je me suis permis de changer quelques petites choses à la présentation de ce blog...

Ainsi, la liste des tags est maintenant en haut de chaque page - vous n'avez qu'à cliquer sur Montrer tous les tags pour qu'elle s'affiche. Cette solution me permet de libérer un peu de place dans le sidebar gauche, et d'augmenter la visibilité de certaines fonctions du blog (les liens de syndication sont maintenant en haut à droite ; avant, ils n'étaient visible qu'après avoir scrollé en bas de page).

Le code pour montrer/cacher les tags:

<script type="text/javascript">
<!--
  function toggle_visibility(id, idTitle) {
    var e = document.getElementById(id);
    var t = document.getElementById(idTitle);
    if(e.style.display == 'block')
    {
      e.style.display = 'none';
      t.innerHTML = "Montrer tous les tags";
    }
    else
    {
      e.style.display = 'block';
      t.innerHTML = "Cacher tous les tags";
    }
  }
//-->
</script>

<!-- debut tags -->
<div class="post">
  <div id="tagcloud">
    <h2><a href="http://blog.emmanueldeloget.com/index.php?post/2009/12/18/149-quelques-petites-modifications#" id="tagcloud_title" 
      onclick="toggle_visibility('tagcloud_content','tagcloud_title')">Montrer tous les tags</a></h2>
    <div id="tagcloud_content" style="display:none;">
      <?php twTags::tagCloud($levels = 5, $block = '%s', $item = '<span class="level-%2$d">%1$s</span>') ?>
    </div>
  </div>
</div>
<!-- fin tags -->

Voilà. C'est mieux, non ?

Sortie prochaine de XQual XStudio v1.1

Emmanuel Deloget — Fri, 18 Dec 2009 13:00:00 +0000

XQual va bientôt sortir la version 1.1 de son logiciel gratuit XStudio dont j'avais testé il y a déjà quelques temps la version 0.4b3. Pour rappel, XStudio est un logiciel de management de tests ouvert, permettant de créer des campagnes de validation de tout type (tests unitaires, tests fonctionnels, ...) et produisant des rapports de grande qualité.

Depuis la version 0.4b3, de nombreuses fonctionnalités se sont rajoutées. Il serait un peu complexe de toutes les citer ici, mais on peu citer les plus importantes :

Passage en GPL3
100% graphique
API simple et open source (LGPL3) pour le développement de nouveaux Launchers (à noter que la version 0.4b3 présentait deux lauchers - il y a une quinzaine maintenant - de quoi trouver votre bonheur).
Support des tests manuels et automatiques
Intégration avec Bugzilla (d'autres outils de tracking - Trac, Jira - sont prévus en version 1.2).
Fonctionne sous Windows (XP, Vista, 7), Mac OS X (Snow Leopard) et Linux

La documentation a elle aussi beaucoup évolué - elle est plus complète, et propose de nombreux tutoriaux.

Ce logiciel, maintenant en version stable (la version 1.0 est sortie fin novembre 2009), est un concurrent direct de certains packages commerciaux. Tous ceux qui souhaitent découvrir une solution de test management fiable, efficace et peut couteuse se doivent de le tester au moins une fois. La prise en main est rapide, et les possibilités sont infinies (pour peu que vous ayez un programmeur Java disponible pour vous créer un launcher adaptés à vos besoins).

Pour plus d'informations, vous pouvez vous rendre sur le site web du produit.

template struct do_not_misuse

Emmanuel Deloget — Thu, 17 Dec 2009 17:00:00 +0000

En C++, être capable d'abstraire un type de données pour qu'il puisse être utilisé sous une forme paramétrée est à la fois tentant, amusant, difficile et très souvent inutile. Je vais laisser de coté le dernier point (j'y reviendrait peut-être dans un article futur, et ceux qui lisent ce blog régulièrement savent que j'ai déjà traité le sujet dans un billet datant de 2007) pour me concentrer sur le précédent : la difficulté intrinsèque liée à la programmation générique en C++.

Mesdames et messieurs, venez vous assoir - le show va commencer...

Je code générique, donc je suis

Comme cette magnifique et chaleureuse introduction l'annonce, utiliser des techniques de méta-programmation ou de programmation générique en C++ a quelque chose d'étrangement attirant. On voit bien que le code peut devenir excessivement complexe, certains points de détails nous échappent royalement (dans de nombreux cas, je soupçonne les développeurs de ne même pas en avoir conscience), et bizarrement, c'est ce coté extrêmement technique de l'écriture de template en C++ qui fait aussi sa popularité. Au programmeur débutant, il semble que les templates peuvent tout faire. Au programmeur intermédiaire, il apparaît que les templates sont une solution possible à nombre de ses propres problèmes. Au programmeur chevronné, les templates sont un outil d'une puissance incomparable qu'il convient d'utiliser de manière innovante pour résoudre des problèmes qui, soyons honnêtes, n'existent pas forcément dans d'autres langages... Et finalement, à l'ethnologue qui observe ces trois programmeurs, les templates sont une sorte de déité sortie tout droit de l'inconscient de ses adorateurs.

Il est vrai que la complexité des templates est un véritable challenge pour un programmeur - quel que soit son niveau. Plutôt que de vous dire que vous ne devriez pas vous y frotter, cet article va plutôt s'attacher à vous lister quelques points auxquels vous devez penser lorsque vous touchez aux templates en C++ - autrement appelé des Bonnes Pratiques^[1].

Redéfinir les types paramètre

Un type de donnée quelconque utilisé dans la définition d'une classe template et faisant partie de l'interface publique de cette classe doit être redéfini sous la forme d'un type de donnée appartenant à la classe template.

Exemple:

template <class T>
struct type
{
  typedef T value_type;
  bool operator()(const value_type& a, const value_type& b)
  { ... }
};

Il y a plusieurs raisons pour ça : la première est que cette redéfinition est une abstraction dont vont dépendre les détails de l'implémentation. Dans la définition précédente, si je change T, je n'ai qu'une ligne à changer. Si je n'ai pas défini un type alias alors une modification de T pourrait avoir un impact sur toute la définition de l'interface. Deuxièmement, si type<T> est utilisé à son tour comme argument d'une classe template, il peut m'être impossible de déterminer T et donc de baser mes traitements sur les particularités de ce type. Ce n'est plus le cas dans notre définition, car je peux retrouver T via type<T>::value_type.

C'est vrai pour tous les types de données qui peuvent être utilisés dans l'interface publique de la classe.

template <class T>
class t_collection
{
public:
  typedef std::vector<T> vector_type;
  typedef typename std::vector<T>::iterator iterator_type;

private:
  vector_type m_vector;

public:
  t_collection(const vector_type& in) { ... }
  t_collection(iterator_type first, iterator_type end) { .. }
  iterator_type begin() { ... }
  iterator_type end() { ... }
};

N'oubliez pas que dans certains cas, vous pouvez avoir besoin d'utiliser le mot-clef typename

N'oubliez pas les exceptions

Votre code template a l'obligation d'être résistant aux exceptions. En termes simples, cela signifie qu'une exception générée par votre code (et donc, bien évidemment, par le code que vous appelez) ne doit pas mettre en péril l'invariant de votre classe ni créer de resource leak. La manière la plus simple de procéder et de faire en sorte de n'effectuer aucune modification de l'état interne de votre classe tant qu'il est encore possible qu'une exception soit levée.

Cet exemple n'est pas résistant aux exceptions :

template <class T>
class type
{
public:
  typedef T value_type;
  typedef const value_type& cr_value_type;
  typedef value_type* p_value_type;

private:
  p_value_type m_array;
  std::size_t m_size;

public:
  type() : m_array(NULL), m_size(0) { }

  void add(cr_value_type value)
  {
    p_value_type array = new value_type[m_size + 1];
    array[m_size] = value;
    ++m_size;
    delete m_array;
    m_array = array;
  }
};

Le code de add() est presque correct. Lu de cette manière, il n'y a guère de doute qu'il fonctionne. Que se passe-t-il si on utiliser cette classe misuse en lieu et place du paramètre T ?

struct misuse
{
...
  misuse& operator=(const misuse& other)
  {
    if (!other.allow_copy()) throw std::runtime_error("instance does not allow copy");
    ...
    return *this;
  }
...
};

Vous avez bien lu, une exception est générée par operator=(). Tout à coup, un problème se pose dans le code de type<T>::add() : au cas ou une exception est générée par la seconde ligne, alors la mémoire allouée à la première ligne est perdue. Et maintenant, la question que vous vous posez est : comment éviter le problème ? Vous n'avez pas accès au code de misuse, donc vous ne devez modifier que type<T>. La solution la plus simple est de récupérer les exceptions (dans un bloc try/catch), nettoyer ce qui doit l'être avant de relancer l'exception reçue. Honnêtement, ce n'est pas particulièrement beau.

L'autre solution est d'utiliser des techniques telle que RAII en conjonction avec d'autre mécanismes de protection tel que par exemple l'idiome swap.

Ainsi, par exemple :

template <class T>
class type
{
public:
  typedef T value_type;
  typedef const value_type& cr_value_type;
  typedef value_type* p_value_type;

private:
  class array_container
  {
    p_value_type m_array;
    std::size_t    m_size;
  public:
    array_container(std::size_t n) : m_array(new value_typen), m_size(n) { }
    ~array_container() { delete m_array; }
    void swap(array_container& other) throw ()
    {
      std::swap(m_array, other.m_array);
      std::swap(m_size, other.m_size);
    }
    std::size_t size() const { return m_size; }
  };

  array_container m_array;

public:
  type() : m_array(NULL), m_size(0) { }

  void add(cr_value_type value)
  {
    array_container other_array(m_array.size() + 1);
    other_array[m_array.size()] = value;
    other_array.swap(m_array);
  }
};

Que se passe-t-il dans ce cas ? Si une exception est générée au moment de la copie de value, type<T>::array_container::swap() n'aura pas lieu. Le contenu de m_array n'est donc pas modifié (l'invariant est donc conservé). De plus, le destructeur de type<T>::array_container sera appelé pour détruire l'instance other. La mémoire allouée sera donc libérée.

Élargissez l'utilisation de votre template au maximum

Est-ce que votre classe template ne fonctionne que sur un nombre réduit de type ? Si oui, peut-être est-ce parce que c'est un mauvais candidat à la généralisation. Une autre raison est que vous avez mis des contraintes trop fortes sur le type de donnée qui peut être passé en paramètre. Dans la plupart des cas, c'est parce que vous utilisez les connaissances que vous possédez sur la classe paramètre.

template <class T>
struct type
{
  typedef T value_type;

  void call_func(const value_type& value) const 
  { value.func(); }
};

Vous en avez parfaitement le droit. Au moment de l'instanciation, le compilateur va vérifier que la classe T possède bien une méthode T::func() et va générer une erreur dans le cas contraire. Cependant, toutes les classes ne définissent pas cette méthode T::func() dont vous avez pourtant besoin.

La solution est de passer par des type traits et des policies^[2].

Dans cet exemple, on peut faire :

template <class T, class P = policy<T> >
strut type
{
  typedef P policy_type;
  typedef T value_type;

  void call_func(const value_type& value) const
  {
     policy_type<T>::call_func(value);
  }
};

Et on défini la classe policy:

// par défaut, ne défini rien...
template <class T> class policy { };

template <>
class policy<mon_type_a>
{
  static void call_func(const mon_type& value)
  { value.function_a(); }
};

template <>
class policy<mon_type_b>
{
  static void call_func(const mon_type& value)
  { value.function_b(); }
};

Pour permettre à type<T> de manipuler un type T qui ne contient pas de méthode func, il suffit de créer la policy correspondante.

Respectez le principe de moindre surprise

Les template permettent, par le biais de spécialisations et autre amusements divers, de redéfinir des comportements qui sont parfois très différent selon les paramètres qui sont utilisés pour l'instanciation du template. Un exemple avec la fonction std::advance, qui avance un itérateur d'un certain nombre de pas. Si l'itérateur en question est un itérateur à accès aléatoire (par exemple std::vector<>::iterator), std::advance va simplement utiilser son operator+(). Si l'itérateur ne propose qu'un accès séquentiel (par exemple std::list<>::iterator), std::advance va boucler sur l'appel de l'operator++().

Plus généralement, évitez de changer du tout au tout le comportement d'une classe en fonction des paramètres qui lui sont donnée, à moins que ce changement notable de comportement ne soit induit par le design lui-même.

Notes

[1] Attention: des fois, ça pique les yeux.

[2] Faute de meilleur terme...

Mac OS X - je t'aime !

Emmanuel Deloget — Wed, 09 Dec 2009 18:00:00 +0000

Et pas qu'un peu ! Qui pourrait oser prétendre que ce système, extrêmement bien conçu, mériterait de s'attirer mes foudres ? Certainement pas vous. Et pour vous remercier de votre sollicitude, je vous présente un tour d'horizon des raisons pour lesquelles je suis tombé amoureux des petites machines de firme de Cupertino.

L'auguste machine : le rêve des programmeurs

Oh mon dieu qu'elle est jolie ! J'ai sous les yeux deux superbes bêtes : un iBook G4 fonctionnant sous Mac OS X 10.4.11 et un MacBook (intel) fonctionnant sous Mac OS X 10.5.8. Et pour le développeur que je suis, ces machines sont une véritable révolution.

Dans un premier temps, ce qui frappe, c'est l'indéniable chance qu'on les utilisateurs de Mac de n'avoir besoin que d'un seul et unique bouton sur leur souris. Pour avoir accès aux fonctions qui seraient accessibles en un clic si le pad présentait deux boutons, il suffit de jouer avec ces mignonnes touches poétiquement nommées Pomme et Fleur ou (plus prosaïquement) "Ctrl" ou "Shift". Un clic sur le bouton droit devient ainsi Ctrl+bouton. C'est tellement plus simple que je me demande pourquoi les constructeurs PC font la course aux boutons.

Et en parlant du clavier, que dire ? il est magnifique et fonctionnel. On pourrait regretter son léger manque de réponse, qui donne un peu l'impression d'appuyer dans du pudding pas assez cuit, mais n'y voyez pas là une critique : je préfère. Comme ça, je suis obligé de faire très attention à ce que j'écris histoire d'éviter de l'écrire deux fois. Passé la fausse impression de perte de temps qui en découle, cette technique finit par s'avérer très reposante pour l'esprit et les doigts. Certains mauvais esprits penserait que certaines touches manquent : ou sont les touches |, {, ou encore } ? Soyez franc : en tant que programmeur, vous les utilisez souvent ces touches ? Si vous le faite, vous ne devriez pas. Pourquoi perdre son temps avec un langage basé sur les paradigmes d'un C ancestral lorsque des langages de nouvelle génération aussi puissants que le Basic nous tendent les bras ? Soyez un peu sérieux quand même, et sachez vous remettre en question ! Ce clavier est parfait - il rompt vos mauvaise habitudes acquises durant des années de travail sur des systèmes très inférieurs à celui d'Apple. Ainsi, oubliez la touche "AltGr" - rien que le nom fait froid dans le dos. Ne soyez pas affolé des changements de position de certaines touches comme '-' ou '_', qui se transforment respectivement en '§' et '!' sur le beau clavier tout blanc de mon MacBook. La raison principale de cette modification est que ces dernières touches sont trop peu usitées. Alors afin d'assurer leur promotion, elles ont été placées à une position plus centrale et plus visible.

Un système en avance sur son temps

Vous avez programmé une application pour un OS quelconque récemment ? Peut être avez vous utilisé un langage bas de gamme tel que le C ou l'horrible C++. Franchement, vous êtes dépassé : l'avenir est à Objective-C, un langage magnifique offrant une véritable implémentation objet au dessus de C. Tellement au dessus qu'en fait, le -C à la fin du nom n'est là que pour rassurer les programmeurs vieillissants engoncés dans leurs mauvaises pratiques de programmation au rabais. Objective-C, c'est le futur.

HelloWorld.h

#import <Foundation/Foundation.h>

@interface HelloWorld : NSObject {
  // no instance variables
}

// methods
- (void)sayHello;

@end

HelloWorld.m^[1]

#import "HelloWorld.h"

@implementation HelloWorld

- (void)sayHello
{
  NSLog(@"Hello, world, at %@", [NSCalendarDate calendarDate]);
}

@end

main.m

#import <Foundation/Foundation.h>
#import "HelloWorld.h"

int main (int argc, const char * argv) {
  NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

  // my stuff
  HelloWorld *hw = [[HelloWorld alloc] init];
  [hw autorelease];

  [hw sayHello];

  [pool release];
  return 0;
}

C'est quand même bien plus clair que le même programme écrit en C, n'est-ce pas ?

Des documents de partout!

Prenons le fabuleux darwinbuild, un outil permettant entre autre le développement de modifications dans le kernel XNU (la base Open Source de Mac OS X ; oui, la base est Open Source. Mais le kernel d'un Mac OS X n'est pas Open Source. Chez Apple, on est pas des sales communistes. On préfère nettement récupérer les modifications des utilisateurs, les incorporer dans un système propriétaire, et fermer le tout en empêchant toute modification ultérieure. Il ne faut pas exagérer non plus: l'Open Source est dangereux pour les vendeurs de logiciels). Les derniers mots de la page d'accueil de cet outil sont :

If you are interested in building and modifying Darwin projects, the documentation on this website, and the DarwinBuild tools, will prove to be an invaluable resource.

Et c'est vrai ! La documentation de ce site web (c'est à dire, cette page d'accueil et la page d'accueil du wiki) sont claire et concise - une prouesse, quand on connait la complexité du système ! Le système Mac étant un système simple, il est vrai qu'un outil aussi complet que darwinbuild ne pouvait être que simple d'utilisation. Et bien évidemment, c'est le cas : seules 15 options de ligne de commande possible. Seules les plus compliquées sont documentées, parce que les autres parlent d'elle même (franchement, il faut être un peu lent d'esprit pour ne pas comprendre ce que darwnibuild -nochroot -build=bname project va faire).

En conclusion

Mac OS X est un excellent système, particulièrement étudié pour que vous ne puissiez pas vous y retrouver si vous avez ne serait-ce que 3 minutes d'expérience avec un autre système d'exploitation. Il est très simple d'utilisation, surtout si vous ne voulez pas faire autre chose que regarder le magnifique écran aux chatoyantes couleurs. Il épouse parfaitement le paradigme de simplicité offert par le hardware le supportant.

Et dire qu'il y a quelques mois, j'ai failli acheter un mac...

Notes

[1] '.m' est l'extension des fichiers d'implémentation de Objective-C. Ca vient de... En fait, je sais pas d'où ça peut venir.

Implémentation d'un système de règle pour un jeu de rôle - Retour à nos problèmes

Emmanuel Deloget — Sun, 06 Dec 2009 15:30:00 +0000

Après avoir bien étudié les possibilités qui s'offrent à nous pour éviter de tomber dans le piège terrible des références circulaires, nous pouvons reprendre notre petit bonhomme de chemin et étudier un peu plus les besoin liés à l'implémentation d'un système de règle pour un jeu de rôle, et même commencer à proposer des solutions.

Mise à jour : le code source qui met en oeuvre la technique présentée dans ce billet est disponible. Gardez en mémoire qu'il ne s'agit pour l'instant que d'un début - il est fort possible que l'ensemble évolue très rapidement. Le code source est compilable sous linux (./configure && make && make check) et sous Windows avec Visual Studio 2008 (au moins ; quelques warnings subsistent). Bien évidemment, il s'agit de C++, et l'ensemble du système de gestion de message est basé sur des classes template - de manière à maximiser sa réutilisation future. Amusez vous bien avec ce code source !

Petit rappel

Vous vous rappelez de ce schéma, publié dans le second article de cette série ?

L'article précédent nous a donné les outils qui vont nous permettre de casser une partie de ces liens et ainsi nous donner la possibilité d'implémenter ce système - et même plus.

Cet article continue de considérer le personnage comme étant un système fermé, de manière à ne pas s'encombrer des difficultés supplémentaires liées à son intégration dans un environnement encore plus complexe que lui. On verra dans les articles suivants que cette approche ne fait que nous donner une base de travail, sans pour autant nous fournir la solution correcte au problème pris dans son ensemble.

Le livreur de lait - du producteur au consommateur

Ceux qui lisent régulièrement ces pages savent qu'il existe des solutions efficaces pour répondre au problème de la transmission de messages. Le sujet a été traité en particulier dans la série Du contrôle des fenêtres, et notamment dans la première partie de cette série. Cependant, la solution mise en œuvre était à ce moment très liée à l'architecture des messages Windows - principalement pour des raisons de simplicité. Nous avons besoin d'un système plus générique, offrant les fonctions suivantes :

N'importe qui peut envoyer un message ; le monde des producteurs est ouvert.

N'importe quelle classe d'objet peut enregistrer une ou plusieurs fonctions de réception de message ; je ne dois pas demander à une classe de dériver d'une classe spécifique dès lors que je souhaite déclarer une fonction de réception de message. Mon but est de présenter un système générique d'envoi/réception de messages. Idéalement, il devrait même m'être possible de créer une fonction libre (hors classe) et de l'enregistrer en tant que fonction de réception de message. Plus formellement, le monde des consommateurs est ouvert.

Plusieurs fonctions de réception de message peuvent réceptionner le même message ; un message n'a pas nécessairement un seul destinataire, car j'ai une relation n/n entre les producteurs et les consommateurs ( ce qui signifie que Np producteurs peuvent envoyer un message particulier, et chaque message peut être traité par Nc consommateurs).

Parmi ces trois points, c'est bien évidemment le second qui est le plus important. En substance, il nous empêche de mettre en place une solution similaire à celle mise en place dans le cadre de la série Du contrôle des fenêtres puisque cette dernière s'appuie principalement sur le fait que tous les objets réceptionnant des messages sont des fenêtres, qui dérivent d'une classe unique window.

Formalisation

Qu'est-ce qu'une fonction de réception de message ? Au niveau formel, il s'agit d'une fonction de rappel donc avant tout d'une entité qu'on peut exécuter.

Définition : FRM, fonction de réception de message
Une fonction de réception de message une fonction de rappel typée, aussi appelée fonction déléguée

Selon les langages, plusieurs possibilités nous sont offertes^[1] :

une méthode de classe
une fonction libre (uniquement dans les langages permettant l'utilisation du paradigme procédural; par exemple, C++)
un objet fonction (certains langages orientés objet ne supporte pas la création de foncteurs)
une fonction anonyme (uniquement dans les langages permettant l'utilisation du paradigme fonctionnel ; par exemple, C#, Java).^[2]
une fermeture (uniquement dans les langages supportant cette fonctionnalité ; par exemple C#, Java, JavaScript)^[3]

Les FRM traitent des messages.

Définition: fonction reduction et messages
Soit T l'ensemble des types de donnée qu'il est possible de décrire avec un langage L, et K un sous-ensemble de T sur lesquelles l'opérateur == est défini. On définit la fonction reduction de T vers K telle que quelque soit t1, t2 de T, reduction(t1) == reduction(t2) si et seulement si t1 et t2 sont identiques.
Un message est une instance d'un type M de T.

Vous devez vous demander pourquoi est-ce que je parle de fonction reduction - quelle espèce de lien peut-elle avoir avec notre problème ? Si vous vous rappelez de cette histoire de bouteille de lait et d'étiquettes, alors vous ferez sans doute le rapprochement : la fonction reduction n'est rien d'autre que le système d'étiquetage des messages, qui transforme les informations fournies par le producteur (le message lui même) en un code compréhensible par l'entreprise de livraison de lait.

Histoire d'être complet, on termine notre formalisation du problème avec quelques définitions supplémentaires.

Définition : fonction traduction
Soit T l'ensemble des types de données qu'il est possible de décrire avec un langage L. Soit A, M des sous-ensembles de T. On définit une fonction traduction de M vers A, ou M est un type de message et A est le type d'argument d'une FRM.

Pourquoi a-t-on besoin d'une fonction traduction ? Celle-ci n'entre pas vraiment dans le schéma décrit dans la métaphore du livreur de lait. L'utilité de cette fonction est plus avancée, et peut se comprendre en augmentant légèrement la métaphore sus-dite.

Supposons que notre livreur de lait soit non pas une entreprise locale mais une entreprise mondiale. Elle reçoit des bouteilles de lait en provenance de producteurs du monde entier, et les distribue à ces clients qui peuvent être située à des milliers de kilomètres de l'usine du producteur. Chaque bouteille de lait présente des informations utiles au livreur (qui les exploite après passage dans la fonction reduction) et des informations qui sont utiles au consommateur. Le consommateur est (comme tout consommateur qui se respecte) un peu tatillon, et il s'attend à récupérer ces informations sous une certaine forme. Pour notre producteur, c'est un problème, car ne sachant pas quel client va recevoir la bouteille, il ne peut pas anticiper la façon dont les informations doivent être arrangée. Le livreur passe donc par des petites entreprises locales, sises près des consommateurs, et dont le but et de transformer les informations figurant sur les bouteilles de lait dans le format attendu par les consommateurs. Ainsi, ces derniers ont accès aux informations dont ils ont besoin, sans pour autant que ça n'ai d'impact sur le travail du producteur et du livreur. C'est le rôle de la fonction traduction.

C'est bien beau tout ça, mais concrètement...

La section précédente nous a donné des informations sur les opérations que nous devons supporté, mais ne nous a pas vraiment aidé à concevoir notre système de gestion de messages.

Quels sont les collaborations que nous allons devoir prendre en compte ? Les extrémités du processus sont évidentes : nous allons avoir une entité qui va envoyer le message (le producteur) sous une forme connue F1, une entité qui va réceptionner le message (le consommateur) sous une forme F2. Entre temps, le message au format F1 aura été traité par le livreur grâce à la fonction reduction, et un prestataire l'aura transformé grâce à la fonction traduction. Le producteur n'est pas vraiment partie prenante du système - il en est l'utilisateur. Nous le laissons donc de coté. De même, le consommateur est lui aussi un utilisateur.

Dans notre architecture, nous allons donc déclarer les classes suivantes :

message, notre type M.
key, le type K de retour de la fonction reduction
message_dispatcher, l'équivalent de notre livreur de lait (connait les types M, K et R, type de retour des FRM)
marshaller, l'équivalent de notre prestataire local (connait les types M, A - type de retour de la fonction traduction - et R)
delegate, qui encapsule une FRM (connait A et R)

En temps normal, les opérations suivantes prennent place :

Les consommateurs enregistrent les FRM (sous la forme d'un delegate associée à une valeur de type key et à un marshaller) auprès de l'instance de message_dispatcher.
Lorsqu'un producteur envoie un message au message_dispatcher, ce dernier le transforme en instance de key de manière à récupérer la liste des FRM destinataires du message.
Le message est transformé par le marshaller associé au delegate en un argument d'un type connu par ce dernier.
Le delegate est alors exécuté et appelle le FRM.

Selon le langage de programmation utilisé, quelques complications peuvent arriver lorsqu'on souhaite effectuer des opérations qui paraissent triviales mais ne le sont pas (notamment, en C++, le fait de désinscrire un FRM - il nous faut alors trouver le moyen de retrouver ce FRM particulier dans la liste des FRM enregistrés. Je vous laisse gérer ce point particulier en forme d'exercice).

Pour finir, je vous livre le diagramme de classe correspondant à cette architecture. Le code source C++ documenté lié à ce projet devrait faire l'objet d'une annonce d'ici le début de la semaine prochaine.

A bientôt !

Notes

[1] Je ne vous cache pas que malgré cette envie dévorante de vous présenter un code source adaptés à vos besoins, je ne vais pas (dans cet article et dans les suivants) vous livrer de fichier écrits dans un autre langage que le C++ - par goût pour ce langage imperméable, et parce que je dois bien faire un choix. Je proposerai toutefois de temps en temps des exemple de code dans d'autres langages.

[2] La prochaine version de C++ supporte les fonctions anonymes.

[3] La prochaine version de C++ supporte les fermetures.

Anniversaire III (et demi)

Emmanuel Deloget — Tue, 01 Dec 2009 19:00:00 +0000

Ce blog est né en 2006. En 2007, je fêtais son premier anniversaire, en 2008 le second. Et en 2009, et bien j'ai tout simplement oublié de le faire. Tâchons de réparer cette odieuse injustice, et de donner quelques chiffres...

Des tas de problèmes

Du quatrième trimestre 2008 à la fin du troisième trimestre 2009, j'ai du lutter contre moi-même pour dépasser plusieurs problèmes - et en particulier quelques problèmes de santé importants. Bien évidemment, le rythme des publications s'en est ressenti. Je commence à revenir à un rythme plus normal, même si on remarque que ce n'est toujours pas très reluisant. Quoi qu'il en soit, je récupère bien, donc vous pouvez vous attendre à avoir de plus en plus d'articles sur différents sujets.

Ainsi, en plus d'un an (en fait, depuis le 21/07/2008), seul 9 articles ont été postés sur ce site. Pas grandiose... Dans l'ordre chronologique de parution, le nombre de visites (à ce jour) pour chacun de ces billets :

Anniversaire II : le retour de la mort se venge : 747 visites
Paris GDC'08 - Conference Coverage (Frank Hauselmann) : 786 visites
Le futur standard C++ : concepts: 1206 visites
Le futur standard C++ : concepts, deuxième prise : 1086 visites
Etude du C++ Technical Report 1 - reference_wrapper : je confirme, c'est tordu. : 1151 visites
Plugin pour DotClear 2.1.6 : 212 visites
Implémentation d'un système de règle pour un jeu de rôle - Introduction : 268 visites
Implémentation d'un système de règle pour un jeu de rôle - Analyse des besoins : 248 visites
Une nouvelle console de jeu : la Freebox HD (?!) : 40 visites
Implémentation d'un système de règle pour un jeu de rôle - Cassons la circularité ! : 56 visites

Soit un total de 5800 visites sur la période.

On notera qu'entre le billet 5 et le billet 6 de cette liste, il y a un trou d'une année - ce qui explique les différences en terme de nombre de visites - et que les deux derniers articles datent de la fin du mois de novembre, ce qui explique le nombre de visite encore plus bas - ils viennent de paraître.

La fréquentation du site

Les chiffres sont donnés par Google Adsense. Bien entendu, les visiteurs ayant activés AdBlock ou un programme similaire ne sont pas comptés dans ces chiffres, mais ce n'est pas grâve pour moi, puisqu'ils ne participent pas vraiment à l'effort de guerre autrement qu'en en faisant la publicité (ce qui est déjà pas mal, je vous le concède).

aou-08       2 386
sep-08       2 572
oct-08       3 100
nov-08       2 591
dec-08       2 748
jan-09       2 392
fev-09       2 980
mar-09       2 714
avr-09       2 464
mai-09       2 454
juin-09      2 083
juil-09      1 664 	
aou_09       1 367
sep-09       1 661
oct-09       3 422
nov-09       2 879
total       39 477

On voit un trou évident qui arrive dès Juin 2009 - après déjà plusieurs mois sans nouvelles de ma part. J'en conclus que vous êtes globalement fidèles, et c'est plutôt une bonne chose pour moi.

Ces près de 40,000 visites se sont transformées en 104 clics sur les annonces Google - pas de quoi faire vivre ce site (loin de là ; il en faudrait 3 fois plus !) avec un record de fréquentation (et de nombre de clics) le 27 octobre 2009 (341 visites, 6 clics).

Source des visites

Chose importante : la part des visites en provenance d'un autre site a plus que doublé (en pourcentage), passant de moins de 10% pour [juillet 2007 - juillet 2008] à près de 23% pour les 15 mois écoulés. Sans surprise, on retrouve les classiques :

developpez.com, avec plus de 1700 visites
siteduzero.com avec près de 1200 visites
gamedev.net avec 230 visites environ
netvibes.com avec un peu plus de 100 visites
geekzone.fr, source d'une quarantaine de visites.

Au niveau des moteurs de recherche (63.74% des visites), on compte bien évidemment google (98% des recherches proviennent de google) suivi par yahoo (0.82%) puis live/bing (0.48%). Les mots-clef les plus cherchés sont :

architecture logicielle (3,6% des recherches) ; (remarque : pour cette recherche, j'apparais très haut sur la première page de résultats sur google).
std::auto_ptr (même remarque)
raii
emmanuel deloget
xna isfixedtimestep

Au niveau des browsers, on ne sera pas surpris de voir que FF est le browser le plus représenté - 68% des visiteurs. C'est principalement du au fait que les visiteurs sont très souvent des personnes ayant des connaissances informatiques poussées, et qu'ils ont fait le choix d'un navigateur qui correspond à leurs attentes. Enfin je crois... :)

Commentaires et notes

Durant cette année et demi, 33 commentaires ont été postés. Ce nombre n'est pas particulièrement élevé, mais il reste correcte (environ 2 commentaires par mois, sachant que je n'ai pas été présent pendant plus d'un an, c'est déjà pas mal). Plus intéressants, vous vous êtes un peu plus lâchés sur les notes : aujourd'hui, vous avez posés 153 notes aux différents articles de ce blog, pour une moyenne très honorable de 3.87 / 5 (la moyenne étant à 3, puisque la note de 0 est impossible). Les billets les mieux notés :

Titre du billet										note	nb
Exploration de XNA : les sprites animés							5.00	2
Exploration de XNA : la gestion du clavier						5.00	2
Du contrôle des fenêtres, seconde partie						5.00	2
Implémentation d'un système de règle pour un jeu de rôle - Cassons la circularité !	5.00	3
Exploration de XNA : Anatomie d'un projet XNA						5.00	5
Exploration de XNA : Introduction							4.86	7
Implémentation d'un système de règle pour un jeu de rôle - Introduction			4.75	4
Exploration de XNA : affichage de sprites						4.75	4
std::auto_ptr<> et fuite de mémoire							4.67	3
Exploration de XNA : les planches de sprites						4.50	2
L'hérésie des variables globales							4.50	2
Du contrôle des fenêtres, première partie						4.33	3
Le futur standard C++ : les classes d'énumérations					4.33	3
Implémentation d'un système de règle pour un jeu de rôle - Analyse des besoins		4.20	5
Exploration de XNA : Les machines à états						4.00	4

Seuls les articles ayant reçu plus de 1 vote (nb > 1) et ayant une note >= 4 sont présents dans cette liste. On remarque toujours que la série XNA continue d'avoir un certain succès, mais que les nouveaux venus (notamment la série Implémentation d'un système de règle pour un jeu de rôle) sont relativement bien perçus. C'est gentil de votre part - je vais continuer dans cette direction.

A l'année prochaine pour une autre étude des résultats de ce site web !

Implémentation d'un système de règle pour un jeu de rôle - Cassons la circularité !

Emmanuel Deloget — Mon, 23 Nov 2009 18:00:00 +0000

Dans l'article précédent, on a vu que l'implémentation d'un système fermé ayant pour put la gestion d'un personnage dans un jeu de rôle modérément complexe avant des conséquences pour le moins inattendues, et notamment le fait que de nombreuses entités se retrouvait dans un état d'interdépendance complexe. Cet article, plus général que le titre ne le montre, essaie de donner quelques pistes pour casser ces dépendances circulaire dans le but de nous permettre la création d'une architecture simple, ouverte et efficace.

Qu'est-ce qu'une dépendance circulaire ?

Bien évidemment, je pose la question alors que je sais que vous connaissez la réponse. Une dépendance circulaire existe à partir du moment ou une classe A dépends d'elle même de manière indirecte, par opposition à une dépendance directe qui (en termes de design) n'est pas dommageable. Cela signifie que A dépends d'une classe B qui elle même dépends de A.

La conséquence logique est que A et B sont fortement couplées. Ce couplage a un impact non désirable sur à la fois le code et l'architecture.

Sur l'architecture, ce fort couplage implique que A et B sont nécessairement utilisées ensemble ; ni l'une ni l'autre n'est réutilisable sans l'autre. Si A dépends aussi de plusieurs classes A1, ..., An, alors l'utilisation de B dans un projet nécessite la connaissance de A, A1, ..., An - ce qui n'a pas vraiment de sens. L'architecture est fortement complexifiée du fait même de ce couplage fort.

Sur le code, une modification dans l'un des deux classes a de grandes chances d'impliquer une modification dans l'autre classe - de manière plus formelle, A est une responsabilité de B qui est une responsabilité de A. En vertu du principe de responsabilité unique, cela signifie que ni A ni B ne peuvent avoir d'autre responsabilité ; conceptuellement, on voit bien qu'il y a un problème, parce que ça voudrait dire que ni A ni B ne font quoi que ce soit.

Certaines personnes semblent penser que dès lors que deux classes présentent une forte cohésion (c'est à dire qu'elles traitent de sujets très similaires et qu'il y a de fortes chances qu'elles soient utilisées dans le même cadre applicatif) alors le fait qu'elles soient en plus fortement couplées n'a pas véritablement d'incidence sur la qualité du design ou sur le code. Ce n'est pas vrai, pour une simple et bonne raison : tôt ou tard, un couplage fort entraine l'utilisation dans un module de dépendances qui n'ont pas de lien de cohésion avec les autres parties du module. La cohésion globale est donc réduite d'autant. A terme, plus le couplage est fort, plus la cohésion du module sera faible. Seul un couplage faible permet de s'assurer d'une forte cohésion entre les différentes classes d'un module.

Soit ; que faire alors ?

Nous ne connaissons hélas pas beaucoup de manières différentes pour casser ce type de relation malsaine, d'autant que dans notre cas cette relation n'est pas seulement une vue de l'esprit mais bel et bien une réalité liée à l'architecture des règles elle-même.

La première technique est l'ajout de niveaux d'abstraction supplémentaires. Cette technique consiste à découpler deux classes A et B en rajoutant une classe intermédiaire C telle que ("x -> y" signifie "x dépends de y")

avant la modification : A1 -> B1 -> A1
après la modification : A2 -> B2, A2 -> C2 et B2 -> C2 (généralement, C2 est une super-classe de A2).

Dans la famille "Avant - Après", je veux le diagramme de classe

Cette technique est efficace dans de nombreux cas. Pour notre cas particulier, on s'aperçoit rapidement que cette solution n'est pas envisageable - compte tenu du nombre d'interactions entre les différentes classes. En effet, si il est aisé de casser une dépendance circulaire entre deux classes, il est beaucoup plus complexe avec cette technique de casser la dépendance circulaire entre N classes fortement interdépendantes.

L'autre solution est un peu plus complexe à visualiser dans sa version complète, mais elle convient parfaitement à notre cas : c'est l'application de la métaphore livreur de lait^[1]. Le livreur de lait travaille pour le distributeur lactus, connue par tout les producteurs et consommateurs de lait du monde entier ou presque. Lactus prends à sa charge les livraisons de lait partout : un producteur envoie son lait à Lactus, qui l'envoie aux clients qui souhaite boire ce lait spécifique.

Dans ce monde parfait, Lactus n'a pas besoin de connaître la composition exacte de chaque bouteille de lait qui transite par ses locaux. Elle pourrait ne rien connaître du tout, mais ça la forcerait à envoyer le lait à tout le monde si elle souhaite être sûre de n'oublier personne. Afin d'optimiser ses ressources humaines, elle a donc imposé un système simple : chaque bouteille possède une étiquette particulière avec la marque du fabricant. Les consommateurs demandent alors les bouteilles de lait de tel ou tel fabricant.

Les avantages de ce système sont certains : celui qui envoie le lait n'a pas à savoir qui va le recevoir ; celui qui reçoit le lait se moque de qui est vraiment le producteur ; et enfin, Lactus n'a pas besoin de connaître quoi que ce soit à propos du lait échangées ou à propos de ses clients, si ce n'est le strict minimum - la marque du lait et l'adresse du client.

On voit clairement que ce système est fort bien adapté à notre problème : avec une telle vision, il devient possible de regrouper beaucoup d'entités qui autrement serait interdépendantes pour en faire des entités qui sont complètement indépendantes. A noter que vous pourriez croire que si cette technique marche bien dans ce cas, il n'y a pas de raison qu'elle ne marche pas dans le cas simple (A -> B -> A). Il est évident qu'elle fonctionnera - mais à quel prix ? Alors que l'ajout d'une abstraction supplémentaire ne coute quasiment rien, un système de message tel que celui décrit ici nécessite une boite à lettre, des objets messages et tout une ribambelle de petites considérations qui rendent le design non trivial. De fait, il convient de réserver cette solution aux cas ou elle correspond vraiment bien - d'autant que dans la grande majorité des cas, c'est le problème simple qui se pose, et ce problème simple bénéficie grandement de l'ajout d'une abstraction.

A bientôt pour de nouvelles aventures...

Notes

[1] en fait, je l'appelle comme ça, mais elle n'a probablement aucun nom...

Une nouvelle console de jeu : la Freebox HD (?!)

Emmanuel Deloget — Mon, 23 Nov 2009 14:00:00 +0000

Pour les propriétaires de cet objet, c'était évident : vu la forme de la télécommande, il était prévu depuis longtemps que la Freebox HD puisse être utilisée comme console de jeu. Bien sûr, on ne parle pas ici de jeux de dernière génération - point de Modern Warfare 2 ou de Batman - Arkham Asylum. Non, juste des petits jeux amusants et plein de fun, qui passent le temps. Quoi que... C'est maintenant le cas : depuis le 19 novembre, la Freebox HD accueille un nouveau menu (Jeux) et de nouvelles possibilités. Encore mieux, camarades programmeurs : vous pouvez vous même proposer vos créations à Free...

Tout est basé (encore une fois, c'est une habitude chez Free) sur un framework libre - Elixir, un binding Javascript à l'ensemble de librairies Enlightenment Foundation Library (EFL). EFL a été développé pour Enlightenment DR17, afin de le rendre encore plus personnalisable tout en gardant des performances haut de gamme, même sur des machines relativement anciennes.

C'est quoi, EFL ? Pour reprendre le texte officiel :

The EFL contains solutions for almost any graphical interface task, far beyond just rendering images. EVAS provides a highly optimized canvas library. Ecore provides a simple and modular abstraction interface and advanced event management including timers. EDB provides a compact database format for intuitive and easy configuration management, including the storing of binaries. EET provides an integrated and flexible container that ends the traditions of providing themes in tarballs. Edje provides a revolutionary library and tool set for completely abstracting application interfaces from their code, including a complex and flexible method of designing interfaces. EWL provides a complete widget library built on all the other components of the EFL.

Ou, en version française :

EFL contient des solutions pour presque toute les tâches graphiques, bien au delà du rendu d'images. EVAS offre un canvas hautement optimisée. Ecore propose une interface d'abstraction simple et modulaire et un gestionnaire d'évennement avancé incluant les timers. EDB est un format de base de données compact incluant le stockage de binaires pour une configuration simple et intuitive. EET offre un conteneur intégré et flexible qui en termine avec la tradition des thèmes stockés en archives TAR. Edje est une librairie et un ensemble d'outil révolutionnaires pour abstraire complètement l'interface du code, comprennant entre autre une méthode complexe et flexible de définition d'interfaces. EWL est une librairie de widget complète bâtie sur les autres composants de EFL.

Cette architecture EFL + Javascript a de nombreux avantages. Le premier est que vous êtes globalement indépendant de l'architecture système - vous programmez en Javascript. Le second est que l'ensemble est relativement rapide - assez à mon avis pour faire des petits jeux type cartes, shooter ou plateforme (je pense même qu'un jeu comme World of Goo aux fonctionnalités un peu réduite est réalisable sur la Freebox HD). Et c'est tant mieux parce que c'est globalement ce qu'on lui demande à cette "console".

En tout cas, voilà une nouvelle plateforme intéressante, notamment pour les développeurs d'applications mobiles qui devraient y trouver un intérêt certain (et quelques millions de consommateurs potentiels). A noter que free mettra en place courant 2010 un système type App Store pour acheter et télécharger des applications fonctionnant sur la Freebox HD.

Pour plus d'information, c'est ici. Amusez vous bien !

Implémentation d'un système de règle pour un jeu de rôle - Analyse des besoins

Emmanuel Deloget — Mon, 26 Oct 2009 16:00:00 +0000

L'article précédent ne donne guère de solution - il se contente de présenter une problématique qui se résume à : pour transformer un système de règle complexe en code, de nombreux problèmes liés à l'architecture logicielle doivent être résolus. Si j'ai pris l'exemple de Dungeons & Dragons (4ème édition), c'est que ce système est un exemple typique représentatif d'un système de règle complexe. Et nous allons voir dans ce billet dans quelle mesure il peut être complexe.

Les besoins

Il est impossible de prévoir une architecture logicielle si on ne fixe pas auparavant les besoins à laquelle cette architecture doit répondre. Si ce point peut paraître évident à certain, de nombreuses entreprises ne l'ont semble-t-il pas encore intégré. Je le répète donc : la connaissance des besoin est impérative à l'élaboration d'une architecture logicielle.

Supposons que nous souhaitons adapter les règles de Dungeons & Dragons 4ème édition pour les intégrer dans un programme^[1]. Le besoin principal est d'implémenter les règles générales de base ; le second besoin est de permettre l'implémentation de règles particulière arbitraires.

Dans l'ordre :

le joueur doit pouvoir sélectionner une race et une classe ; les races ont un effet sur les caractéristiques, les compétences, les talents, les pouvoirs et l'équipement accessible au joueur.
le joueur doit pouvoir sélectionner une classe ; les classes ont un effet sur les caractéristiques, les compétences, les talents, les pouvoirs et l'équipement accessible au joueur.
le joueur doit avoir accès à plusieurs méthodes pour déterminer ses caractéristiques ; les score des caractéristiques ont un effet sur les compétences, les talents, les pouvoirs et l'équipement accessible au joueur.
le joueur doit pouvoir choisir ses compétences.
le joueur doit pouvoir sélectionner ses pouvoirs.
le joueur doit pouvoir acheter son équipement ; l'équipement a un effet sur les caractéristiques, les compétences, les talents et les pouvoirs du joueur.

Je n'ai pas détaillé l'effet que les pouvoirs peuvent avoir sur le jeu - et pour cause : le pouvoir est activé lorsque le personnage agit, et peut avoir un effet arbitraire sur son environnement. Il ne s'agit même plus d'effet sur le personnage lui-même, mais bien d'effet sur le jeu en cours. Ainsi, un pouvoir d'attaque peut avoir une influence sur les actions qui peuvent être entreprises par un autre personnage. Le problème des compétences est autre : l'utilisation d'une compétence a aussi un effet sur l'environnement - un bluff réussi peut aider lors d'une négociation, ... De fait, l'environnement est aussi impacté par les compétences, mais dans une mesure moindre que par les pouvoirs.

En fait, si on supprime cette possibilité d'agir sur l'extérieur en utilisant un pouvoir ou une compétence, il reste que le personnage peut être représenté par un système fermé que nous pouvons étudier aisément.

Le personnage en tant que système fermé

La liste ci-dessus peut être représentée par le diagramme ci-dessous.

Le diagramme montre clairement les éléments qui ont un impact sur les autres éléments du système^[2] :

Race -> caractéristiques, compétences, pouvoirs & talents, équipement
Classe -> caractéristiques, compétences, pouvoirs & talents, équipement
Caractéristiques -> compétences, pouvoirs & talents, équipement
Compétences -> pouvoirs, équipement
Pouvoirs & talents -> caractéristiques, compétences, pouvoirs & talents, équipement
Équipement -> caractéristiques, compétences, pouvoirs & talents, équipement

On peut déjà noter que deux informations (groupe 1) sont indépendantes des autres (la Race et la Classe). Deux autres informations sont des groupes (groupe 2) de grandeurs (les Caractéristiques et les Compétences). Suivent trois autres informations (pouvoirs, talents, équipement, formant le groupe 3) qui implémentent des règles particulières. Explorons ces groupes plus en profondeur.

Le groupe 1 est utilisé pour l'initialisation d'un personnage. Il n'a d'autre fonction que de fournir un cadre de base - autoriser ou interdire un équipement particulier, fournir une liste de compétence, décrire une liste de pouvoirs disponibles, etc. De nouveaux manuels peuvent ajouter de nouvelles races et de nouvelles classes.

Le groupe 2 contient des informations qui sont similaires, mais pas identiques. Caractéristiques et compétences sont est grandeurs chiffrées qui peuvent être affectées par des modificateurs et qui servent à générer d'autres modificateurs ayant un impact sur des jets de dés. Les différences majeures résident dans l'initialisation de ces grandeurs et la génération du modificateur associé, mais dans l'essence, ce sont des scores auxquels sont associés des noms. La liste des compétences et des caractéristique est fixée, toutefois la liste de leurs utilisations est étendue régulièrement.

Le groupe 3 défini une corpus de règles particulières qui ont un impact sur le personnage dans son ensemble. De nouveaux talents, pouvoirs et objets sont publiés régulièrement, rajoutant de nouvelles règles particulières à ce corpus déjà fournit.

Notes

[1] ATTENTION : cet article utilise Dungeons & Dragons 4ème édition car ce système de règle présente des difficultés représentatives des systèmes de règle complexe des jeux de rôle modernes ; je rappelle que selon la GSL §3 et §5.5, il est interdit d'effectuer une telle adaptation.

[2] on a regroupé pouvoir et talents du fait de leurs similitudes

Implémentation d'un système de règle pour un jeu de rôle - Introduction

Emmanuel Deloget — Mon, 19 Oct 2009 16:00:00 +0000

Même si ça peut paraître relativement simple, l'implémentation d'un système de règle pour un jeu de rôle est une tâche complexe. Il existe de nombreuses raisons à ça :

les règles elles même ne sont pas hiérarchisées : dans un système parfait, une règle particulière ne fait pas référence à une règle plus générale ; au mieux, elle se substitue à la règle générale. Dans le cas des jeux de rôle, ça n'est pas le cas. Les règles particulières peuvent non seulement se substituer aux règles générales, mais elle peuvent aussi les étendre ou les modifier de manière plus fine.
le nombre de cas à gérer n'est pa connu par avance : un jeu de rôle est un produit vivant. Un supplément va nécessairement étendre le système de jeu pour ajouter de nouvelles options. Avant sa parution, il est impossible de savoir quelle modification va avoir un impact sur l'architecture du code. Il convient donc d'ouvrir l'architecture au maximum, sans pourtant tomber dans le travers de la sur-ingénierie qui serait contre-productive.

L'ouverture impossible à prévoir ainsi que les références circulaires sont deux grand ennemis de l'architecte.

On a vu il y a déjà quelques années que le principe OCP (Open Close Principle), principe à appliquer afin d'ouvrir son code de manière à autoriser les extensions futures, nécessite de faire des choix dans son design. Puisqu'il est impossible d'ouvrir complètement le code, il convient de choisir de manière stratégique quelles sont les parties qui risquent d'être étendue. Une fois ces parties décidées, il devient possible de prévoir l'ouverture de code nécessaire à la gestion de futures évolutions. Mais si il est impossible de prévoir dans quel sens les règles d'un jeu peuvent être modifiées, comment faire pour ouvrir son code de manière stratégique ?

Les références circulaires posent en plus un autre problème : celui du couplage du code. Dans l'idéal, on devrait pouvoir arranger les classes d'un projet en strates. Plus on descend dans les strates, moins on est abstrait. Bien évidemment, les classes d'une strate ne peuvent dépendre que des classes de la même strate ou d'une strate supérieure, jamais des classes d'une strate inférieure. Il y a bel et bien une relation hiérarchique entre les classes. Dans le système de règle d'un jeu de rôle, il est relativement fréquent qu'une règle particulière très concrète modifie une règle plus générale et plus abstraite. Dans ces conditions, il devient difficile de générer un diagramme de classe élimine les références circulaires.

Bien sûr, difficile ne veut pas dire impossible.

Allez, on réfléchi un peu

D'un point de vue personnel, j'utilise principalement deux systèmes de jeu : le système D20 mis en place par Wizard of the Coast comme support du jeu de rôle Dungeons & Dragons, et le système BASIC utilisé par les jeux publiés par la société Chaosium, éditrice entre autre de l'Appel de Cthulhu (dont je vous recommande chaudement la 6ème édition française, qui étonnamment est légèrement meilleure que la 6ème édition en version originale). Le système BASIC est très simple : en fait, la création des personnages est rationalisée et ne nécessite aucune règle particulière qui aurait un effet quelconque sur une règle plus générale. Chaque personnage est défini par un certain nombre de caractéristiques et un certain nombre de compétences (qui peuvent dépendre des caractéristiques). L'équipement peut fournir des bonus lors de l'utilisation d'une compétence. Au niveau social, un personnage est défini par son occupation, son métier et les cercles d'influences sur lequel il a un impact. En terme d'architecture logicielle, on a un système purement descendant : on va toujours soit du général vers le particulier, soit du particulier vers le général. Le seul point qui échappe à cette règle concerne le métier du personnage - le personnage choisi ses compétences en fonction de son occupation professionnelle, et son métier en fonction de ses scores de compétence. Toutefois, ce système peut quand même être modélisé simplement par strates.

En terme d'ouvertures, l'ensemble est aussi relativement simple : les options de jeu autorise les joueurs à utiliser des compétences non prévues, ou du nouveau matériel, ou à choisir une nouvelle occupation ; de manière générale, un nouvel élément de règle peut être symbolisé par une nouvelle classes à une strate donnée. Il est donc relativement aisé de prévoir de manière stratégique les strates de classes qu'il faudra ouvrir afin de permettre d'éventuelles extensions des règles.

Dungeons & Dragons se révèle très différent. Même si les règles de la quatrième édition ont été retravaillée pour être plus simples et plus accessible, de nombreux points peuvent poser problème à l'architecte logiciel.

Si on ne prends en compte que les règles générales, on se retrouve dans une situation proche de celle présentée dans les paragraphes précédents et qui concerne l'Appel de Cthulhu. Un joueur choisi sa race et sa classe, puis détermine les caractéristiques de son personnage et ses compétences, puis choisit ses talents, ses pouvoirs et son équipement. Dans l'ensemble, le système reste descendant et peut être arrangé en strate. Le problème est posé par une simple petite phrase résumant la philosophie des règles : le particulier prends le pas sur le général. De fait, il est possible d'imaginer un talent qui ne peut être pris que si une compétence particulière a été sélectionnée au moment de la création du personnage et qui modifie une autre compétence.

Exemple de talent : persuasif
Condition : entraîné en Intimidation
Effet : le personnage bénéficie d'un bonus de +2 à la compétence Diplomatie.

Ce talent affecte la liste des compétences tout en étant dépendante d'elle. Mathématiquement, on se retrouve avec une référence circulaire évidente (les compétences affectent le talent qui affecte les compétence).

En ce qui concerne l'ouverture, de nombreux problèmes se posent. Quel que soit la strate de classes considérée, elle peut avoir un effet quelconque sur une autre strate de classes. Ainsi, un objet peut avoir un effet sur les caractéristiques, les compétences, les pouvoirs à disposition, les talents, etc. Un talent peut de même avoir un effet sur l'équipement accessible, les compétences, les caractéristiques, les pouvoirs à disposition, etc. De plus, en considérant bien le système de règle existant, il est tout à fait possible d'imaginer que la définition même des caractéristiques et des compétences puisse être modifiée. C'est déjà arrivé : ainsi, une compétence particulière peut voir son cercle d'action élargi par de nouvelles règles.

On le voit, l'architecture logicielle à même d'encoder un tel système regorge de pièges et sera difficile à mettre en place. D'une part, elle doit luter pour préserver le plus possible la notion de système en strate qui est nécessaire à l'application correcte de plusieurs des principes fondamentaux de l'architecture orientée objet déjà discutés dans ces pages ; d'autre part elle doit aussi permettre un accès à toute donnée modifiable, puisqu'elle ne peut prévoir la variété infinie des modifications au corpus de règle pouvant subvenir. Et comme ces deux désidérata vont dans le sens contraire, il va falloir réfléchir pour trouver des solutions acceptables...

La suite dans quelques jours...

Etude du C++ Technical Report 1 - reference_wrapper : je confirme, c'est tordu.

Emmanuel Deloget — Mon, 01 Sep 2008 14:00:00 +0000

Souvenez vous : il y a près de deux ans, j'essayais avec grand peine d'implémenter la classe std::tr1::reference_wrapper<>, et j'ai du abandonner.Tout content de pouvoir installer l'implémentation du TR1 de Microsoft Visual C++ 2008 SP1, j'ai tenu à vérifier que mon échec épique n'était pas du à ma stupidité, mais à (comme je le pense sincèrement) une mauvaise formulation du texte du TR1.

Le problème se situe dans le document ISO/IEC DT 19768 (pdf), section 2.1.2, paragraphes 2, 3, 4.

2. reference_wrapper has a weak result type (3.3).

3. The template instantiation reference_wrapper<T> shall be derived from std::unary_function<T1, R> only if the type T is any of the following:
-- a function type or a pointer to function type taking one argument of type T1 and returning R
-- a pointer to member function type with cv-qualifier cv and no arguments; the type T1 is cv T* and R is the return type of the pointer to member function
-- a class type that is derived from std::unary_function<T1, R>

4. The template instantiation reference_wrapper<T> shall be derived from std::binary_function<T1, T2, R> only if the type T is any of the following:
-- a function type or a pointer to function type taking two arguments of types T1 and T2 and returning R
-- a pointer to member function with cv-qualifier cv and taking one argument of type T2; the type T1 is cv T* and R is the return type of the pointer to member function
-- a class type that is derived from std::binary_function<T1, T2, R>

Des paragraphes 3 et 4, il découle que si la class C1 dérive à la fois de std::unary_function<> et std::binary_function<>, alors reference_wrapper<C1> doit dériver de ces deux types.

Le paragraphe 2 nous renvoie à la section 3.3, paragraphe 3.

3. If a call wrapper (3.1) has a weak result type the type of its member type result_type is based on the type T of the wrapper’s target object (3.1):
-- if T is a function, reference to function, or pointer to function type, result_type shall be a synonym for the return type of T;
-- if T is a pointer to member function, result_type shall be a synonym for the return type of T;
-- if T is a class type with a member type result_type, then result_type shall be a synonym for T::result_type;
-- otherwise result_type shall not be defined.

Puisque std::unary_function<> et std::binary_function<> définissent tous les deux le type result_type, C1 hérite de ces types. Dans ce contexte, faire référence à C1::result_type provoque une erreur du à l'ambiguïté. Dans ce contexte, il est normalement impossible de définir reference_wrapper<C1>::result_type.

Je suis rassuré par le fait suivant: l'implémentation du TR1 fournie par Microsoft dans Visual C++ 2008 SP1 butte sur ce problème. L'implémentation présente dans GCC élimine le problème en considérant que C1 ne définit pas de type result_type (ce qui n'est pas illogique, mais la technique de découverte de cette information n'est pas portable de GCC à Visual C++ -- et le compilateur Comeau se comporte encore de manière différente vis-à-vis de ce problème).

Mon échec n'était donc pas si épique. Ou alors, il l'est encore plus que ce que j'imaginais (à savoir que le cas cité n'est même pas censé se présenter dans votre code si vous êtes un tant soit peu respectueux des autres personnes qui travaillent avec vous...).

Architecture Logicielle & Développement

Passage à Dotclear v2.1.6

webvcs - vérification de l'identité en ligne sans transfert du mot de passe

Implémentation

Considérations de sécurité

Conclusion

Notes sur l'implémentation sur un client léger

Plugin pour DotClear 2.1.6

Installation

Utilisation

Versions

webvcs - un système de contrôle de version sans serveur

Le fonctionnement, coté web

Le fonctionnement, coté client

Beta-testeurs ?

Le futur standard C++ : les templates variadiques

L'Existant

Variadic templates : la proposition N1603 (pfd)

Conclusion

const X& x ou X const& x ? (et autres amusements)

Notes

const X& x contre X const& x

Je mets virtual ou pas?

v++ contre ++v

Notes

Visual Studio .Net 2010 (beta 2)

gcc sous Windows ? C'est possible, mais...

Cygwin

Installation

/bin/sh, ou la lenteur faite programme.

Des soupçons sur la stabilité ?

Une documentation peu explicite...

Mingw

Installation

/bin/sh... ok, on sait déjà.

"Faire semblant" et "faire semblant"

Conclusion

Noel, joyeux

Quelques petites modifications...

Sortie prochaine de XQual XStudio v1.1

template struct do_not_misuse

Je code générique, donc je suis

Redéfinir les types paramètre

N'oubliez pas les exceptions

Élargissez l'utilisation de votre template au maximum

Respectez le principe de moindre surprise

Notes

Mac OS X - je t'aime !

L'auguste machine : le rêve des programmeurs

Un système en avance sur son temps

Des documents de partout!

En conclusion

Notes

Implémentation d'un système de règle pour un jeu de rôle - Retour à nos problèmes

Petit rappel

Le livreur de lait - du producteur au consommateur

Formalisation

C'est bien beau tout ça, mais concrètement...

Notes

Anniversaire III (et demi)

Des tas de problèmes

La fréquentation du site

Source des visites

Commentaires et notes

Implémentation d'un système de règle pour un jeu de rôle - Cassons la circularité !

Qu'est-ce qu'une dépendance circulaire ?

Soit ; que faire alors ?

Notes

Une nouvelle console de jeu : la Freebox HD (?!)

Implémentation d'un système de règle pour un jeu de rôle - Analyse des besoins

Les besoins

Le personnage en tant que système fermé

Notes

Implémentation d'un système de règle pour un jeu de rôle - Introduction

Allez, on réfléchi un peu

Etude du C++ Technical Report 1 - reference_wrapper : je confirme, c'est tordu.

`const X& x` contre `X const& x`

Je mets `virtual` ou pas?

`v++` contre `++v`