Vue d’ensemble

Avant de commencer, une remarque sur Windows. À priori, il est possible de travailler sur Windows. Cependant, les binaires Qt pour Android ne sont disponibles que pour Linux. Comme la compilation de Qt pour Windows est pénible et que je ne l’ai pas faite depuis longtemps, je présente seulement l’utilisation de Linux. Pour ceux qui aimeraient pouvoir utiliser Windows… tant pis pour vous

Je n’avais pas testé Qt sur Android depuis quelques temps, en fait depuis Qt 4.8 et Necessitas. Du coup, j’ai découvert le portage Android dans Qt 5.1 en même temps que je prenais des notes pour cet article. Comme base de travail, je suis parti des pages des pages de documentation de Qt : Qt – Android support.

L’utilisation de Qt sur Android nécessite l’installation de plusieurs outils :

• la version de Qt 5.1 pour Android : ok, on s’y attendait un peu. Contient la bibliothèque complète et Qt Creator ;
• le kit de développement (SDK) pour Android : permet de créer des applications Java pour Android et un simulateur pour tester ses applications ;
• le kit de développement natif (NDK) pour Android : permet de créer des applications C++ pour Android ;
• l’environnement d’exécution de Java (JRE) : nécessaire pour le SDK Android ;
• Apache Ant : pour faire beau. (bon ok, ce n’est pas que pour faire beau, ça sert au déploiement. Mais comme c’est un outil Java, je ne connais pas du tout).

Dans ce tutoriel, je vais montrer l’utilisation de Qt Creator, mais il doit être possible d’utiliser d’autres outils.

Installations

Installation de OpenJDK 7

Pour commencer, il faut installer l’environnement d’exécution de Java. Il est fort possible qu’il soit déjà installé. Dans la documentation, il est indiqué qu’il faut par exemple OpenJDK en version 6 ou plus récente.

Personnellement, j’avais la version 7. Cependant, j’ai eu des problème avec Apache Ant, qui me retournait une erreur. J’ai donc dû installer la version 6 en plus. Comme j’ai pas mal bidouillé, je ne suis pas sûr de la procédure. Si des personnes testent et remarquent des problèmes, n’hésitez pas à me le signaler.

Merci à rotoOm qui m’a indiqué l’origine du problème. Il suffit en fait d’installer le JDK en plus du JRE. Merci à lui pour l’information.

Vous pouvez tester si Java est installé avec la ligne de commande suivante :

Pour l’installation, j’ai donc utilisé les paquets fournis par Ubuntu. Il faut donc juste taper ces lignes de commande :

Pour les autres systèmes Linux, vous pouvez consulter la page de documentation d’OpenJDK : How to download and install prebuilt OpenJDK packages.

Installation d’Apache Ant

Pour l’installation d’Apache Ant, même méthode, j’utilise les paquets Ubuntu :

Pour tester l’installation d’Apache Ant, vous pouvez taper la ligne de commande suivante :

Installation du SDK Android

Pourquoi installer le kit de développement Java ?

Pour commencer, on ne peut se poser une question : pourquoi installer le kit de développement Java et le kit de développement natif et pas simplement ce dernier ? La réponse est simple : parce qu’on ne peut développer que en Java pour Android !

Ok…

Donc cela veut dire qu’il faudra utiliser le binding Java de Qt ? On parlait pas de développement C++ dans ce tutoriel ?

Oui, pas d’inquiétude En fait, il y a un point à savoir sur les applications natives C++ sur Android. C’est une application Java qui appelle un « module » écrit en C++ (on utilise le terme « activité » en Java). Avec Qt, on va donc simplement créer notre code C++/Qt et Qt Creator va s’occuper de créer l’application Java qui appelle notre code.

Ouf !

Installation

L’installation du SDK Android est simple aussi… puisqu’il n’y a pas d’installation à faire. Vous devez simplement télécharger le kit de développement pour Android et décompresser l’archive. Ce SDK contient les outils de développement Android, des plateformes de compilation, l’éditeur Eclipse ADT (Android Developer Tools, configuré spécialement pour Android), un simulateur Android pour tester ses applications.

Pour installer d’autres outils, par exemple d’autres versions de plateforme, vous pouvez utiliser le SDK Manager. Dans Eclipse ADT, allez dans le menu Windows puis Android SDK Manager.

Tester Eclipse

Comme je suis curieux et que j’ai envie de voir un peu comment fonctionne une application Java sur Android, j’ai testé un peu Eclipse et Java. Ceux qui ne sont pas intéressés, vous pouvez passer directement à l’installation du NDK.

Pour cela, j’ai simplement suivi le tutoriel : Building Your First App (il faut reconnaître que la documentation est très claire et simple à suivre, même pour un développeur C++ comme moi).

Allez dans le répertoire d’installation du SDK Android puis dans le répertoire eclipse/. Celui-ci contient un binaire eclipse, que vous lancez. Si c’est la première utilisation d’Eclipse, il va falloir faire quelques réglages de configuration. En premier le Workspace (l’espace de travail d’Eclipse, dans lequel il range les fichiers). Personnellement, j’ai accepté toutes les valeurs par défaut.

Une fois qu’Eclipse est lancé, créez un nouveau projet de type « Android Application Project » dans Fichier puis Créer un projet. Un dialogue permet de donner un nom à votre application (c’est le nom qui apparaîtra sur le téléphone), la version minimale d’Android à prendre en charge et la version Android de destination. J’ai laissé par défaut. Vous pouvez ensuite choisir l’icône de l’application et le type d’activité. Choisissez BlanckActivity, qui va créer une activité « hello world ».

Après quelques minutes (je vais rien dire que la lenteur d’Eclipse…), un projet est créé, qui contient quelques fichiers et répertoires. Les plus importants sont :

• le fichier AndroidManifest.xml : contient les informations sur l’application, en particulier les versions minimale et ciblée de la plateforme ;
• le répertoire res/layout/ : contient les interfaces de l’application, décrites dans des fichiers XML ;
• le répertoire src/ : contient les sources Java du projet. Dans ce projet par défaut, il lance simplement une activité, qui affiche l’interface décrite dans le fichier XML de layouts/ ;
• les répertoires res/drawable-xxx/ : contient les images de l’application.

Comme c’est une application Android, vous ne pouvez pas simplement la lancer comme une application de Bureau classique. Il existe deux méthodes pour la lancer : utiliser un simulateur ou déployer sur un téléphone.

Tester l’application sur simulateur

Pour cela, il faut dans un premier temps créer un simulateur. Le SDK Android est fournit avec un gestionnaire, permettant de créer différentes configurations pour le simulateur, permettant ainsi de tester l’application sur plusieurs types de téléphone.

Allez dans le menu Windows puis Android Virtual Device Manager. Dans le dialogue, créez un nouveau périphérique en cliquant sur « New », puis configurez selon le type de téléphone que vous voulez tester. Par exemple, comme j’ai un téléphone Samsung Galaxy S1, j’ai choisit un écran 4″ en 480*800. Après la création du périphérique, lancez-le.

Lancez ensuite l’application en ouvrant le fichier java (dans src/) puis en cliquant sur le bouton Run. Un dialogue « Run As… » s’ouvre pour choisir comment exécuter l’application. Choisissez Android Application. Normalement, l’application devrait se lancer.

Tester l’application sur téléphone

Bon, un simulateur, c’est bien, mais on aimerait avoir l’application sur un vrai téléphone pour tester. Ce n’est pas très compliqué non plus, mais il va falloir faire une manipulation sur le téléphone. Celle-ci permet d’activer les fonctionnalités de développement du téléphone, en particulier le Debug Mode USB, qui permet de déployer des applications via un cable USB.

Pour Android 4.2, allez dans les paramètres puis dans le menu À propos du téléphone. Cliquez plusieurs fois sur Numéro de build par activer le mode développeur. Vous allez avoir un message confirmant le passage en mode Debug. Revenez ensuite à l’écran précédent et allez dans les options de développeur. Activez le mode Debug USB. Pour les autres versions d’Android, vous pouvez consulter la page suivante : Run on a Real Device.

Pour terminer, il suffit de brancher le téléphone sur l’ordinateur avec un câble USB puis de lancer l’application comme précédemment. L’application devrait se lancer sur le téléphone.

Installation du NDK Android

Rien de compliqué ici non plus, il n’y a pas d’installation à faire, il faut simplement décompresser l’archive.

Installation de Qt Android

Le plus simple, comme indiqué au début de ce tutoriel, est d’utiliser les binaires fournis de Qt 5.1 pour Android. Si vous n’utilisez pas Ubuntu, il vous faudra compiler Qt vous-même. Bon courage

Lancez le binaire Qt pour Android. Le processus d’installation est classique, avec une particularité : le SDK propose par défaut l’installation de Qt Desktop, mais pour Android (versions ARM ou x86), il faut l’activer soi-même. Une fois l’installation finie, allez dans les répertoires Tools, QtCreator, bin puis lancez qtcreator.

La première étape va être de configurer Android. Pour cela, allez dans le menu Outils puis Options. Dans la liste de gauche, allez dans Android, puis configurez les répertoires du SDK et du NDK. Cochez la case pour laisser Qt Creator créer automatiquement les kits de compilation.

Il faut ensuite créer un périphérique pour le simulateur si ce n’est pas encore fait. Pour cela, cliquez sur le bouton Start Android AVD Manager.

Cliquez sur New pour créer un nouveau périphérique. Choisissez le type de Device (pour simuler mon Galaxy S, j’ai donc choisit un 4″ en 480*800). N’oubliez pas d’activer la prise en charge du GPU (Use Host GPU) pour que Qt puisse utiliser OpenGL ES.

Pour créer une application Qt, allez dans le menu Fichier puis Nouveau projet. Choisissez un projet compatible avec Android (par exemple Application Graphique Qt ou Application Qt Quick 2 (élément de base)).

Dans un premier temps, le simulateur se lance.

Puis l’application à la fin du déploiement.

Pour déployer sur un téléphone (préalablement passé en mode Debug USB, voir au début), il suffit simplement de le brancher, Qt Creator lancera alors l’application dessus.

Conclusion

Rien de très compliqué finalement. Le déploiement est relativement simple une fois que les outils sont configurés. Reste plus qu’à tester les performances.

Pour ceux qui sont intéressés par Qt Quick, je rappelle le livre auquel je participe : Créer des applications avec Qt 5 – Les essentiels. J’ai en particulier participé à la rédaction de Qt Quick. C’est encore une pré-version du livre final, mais il y a déjà pas mal de choses sur Qt Quick. Et n’hésitez pas à me dire s’il y a des points que vous souhaiteriez voir abordés dans ce livre.

Si vous êtes intéressé par Qt Quick sur mobile, je fais une présentation le 5 juin à Paris. Contactez-moi par MP pour plus d’informations.

Merci à prgasp77 et winjerome pour leur relecture orthographique.

N’hésitez pas à commenter cet article sur le forum.

Il nous est apparu qu’une faille dangereuse et non détectée par le compilateur résultait de l’utilisation conjointe de la déduction automatique de type retour des lambdas et des std::function<const A&()> qui retournent une référence constante.

Le code suivant compile parfaitement sans aucun warning sous g++4.8 et clang++3.2 avec les flags -pedantic -Wall -Wextra.

Or le résultat obtenu en commentant cette ligne est :

Pour les rapides, oui aref est totalement corrompue, et son utilisation résulte en un crash sauvage et sans pitié du programme lorsqu’on a de la chance. Pour les autres, voici l’explication.

Savez-vous quel est le type de retour implicite de la lambda ci-dessous ?

Si comme moi, à première vue vous répondez A&, vous vous en mordrez les doigts.
La réponse est A.

En effet, comment se déduit automatiquement le type de retour d'une lambda ? Eh bien de la même façon que decltype. C'est à dire tel que la variable a été déclarée. Ici, a étant déclaré comme A, c'est donc A qui est le type du retour de la lambda.

Si l'on capture cette fois une référence vers A :

Ici refTo_a est déclarée comme une A&, c'est donc A& qui sera déduit.

Reprenons notre cas initial. Bon, à priori ce n'est pas une grande perte, on fait une simple copie.

Ainsi, le code suivant est parfaitement sain si on reconnait la légitimité de la copie :

La prise par référence constante allonge bien la durée de vie de la temporaire retournée par la lambda jusqu'à la fin de la vie de la référence, ainsi que la norme le demande.

Oui mais…

Que se passe-t-il lorsque notre lambda est encapsulée dans une std::function<const A&()> ?

Ainsi que cela a été révélé plus haut, mais en ajoutant l'indication du constructeur de copie et un id aux objets la sortie est :

Lors de l'appel à f(), une copie est donc faite, conformément à ce qu'on a vu précédemment avec la déduction automatique du type de la lambda. Mais elle est détruite immédiatement !

Pourtant on récupère bien une const A&, pourquoi ne fait-elle pas prolonger de la copie temporaire comme précédemment ?

Un petit code montrant le mécanisme du avec std::function<const A&()> en détail :

On note à nouveau un silence total du compilateur. Le résultat est :

Là où ça devient tordu c'est que l'extension de durée de vie d'une temporaire par référence constante est limitée à une seule fois.

En effet, une fois récupérée dans une const A&, la copie temporaire n'a plus du tout le statut de temporaire : aussi on ne peut donc plus étendre sa durée de vie de cette façon !

Voici donc le pourquoi du comment. En conclusion il est donc dangereux soit de jouer avec les std::function<const A&()> soit de laisser faire la déduction automatique du type retour des lambdas. En l'absence d'arguments forts pour pencher la balance, la vigilance est donc de mise lorsque l'on joue avec les deux règles responsables du problème ici :

1. Un type de retour automatiquement déduit est équivalent à un decltype(expression_de_return), soit le type de l’expression telle qu’elle a été déclarée, la capture par référence n’y fait rien, ça reste le type de la variable avant sa capture.
2. Si une lambda a vocation à être stockée dans une std::function, alors il faut veiller à ce qu’elle ne renvoie pas une temporaire et que le type de la std::function corresponde au comportement souhaité.

Un grand merci à Flob90 qui a pris le temps de faire beaucoup de tests que vous pouvez consulter ici : lien pastebin. Merci à gbdivers pour sa relecture attentive.

Vous pouvez commenter ce billet de blog sur le forum.

• utiliser deux boucles for imbriquées pour parcourir chaque pixel du widget et calculer la couleur correspondante, en faisant varier les paramètres S et V dans l’espace colorimétrique HSV ;
• utiliser deux gradient (à l’aide de la classe QLinearGradient), le premier, horizontal, allant du blanc à gauche à la teinte choisie à droite, et le second, vertical, allant du transparent en haut au noir en bas.

Je vais présenter ici comment implémenter un benchmark avec Qt pour tester la rapidité de ces différentes méthodes et présenter deux autres méthodes pour accélérer le rendu : l’accès direct au tampon mémoire contenant l’image finale et l’accélération matériel sur carte graphique.

Création du programme Benchmark

Qt offre différents outils facilitant la création de tests unitaires et de benchmarks, rassemblés dans le module QtTest. Différents tutoriels permettent de se familiariser progressivement avec ce module.

Benchmark.pro

Pour créer notre programme Benchmark, commençons par créer un fichier de projet Benchmark.pro. Ce fichier de projet contient les déclarations de base suivantes : la liste des modules utilisés (core, gui puisse que l’on teste les fonctions de dessin et testlib) et le nom et le type de binaire généré (une application Benchmark dans notre cas) :

On ajoute ensuite la liste des fichiers à inclure dans notre projet. On va simplement créer une classe Benchmark : on ajoute donc les fichiers d’en-tête et d’implémentation :

benchmark.h

La classe Benchmark hérite de QObject (pour pourvoir utiliser le système de signaux et slots) et contient deux slots privés, un pour chaque méthode que l’on souhaite tester. Ces slots seront automatiquement appelés à l’exécution du programme. A part cela, le contenu de la classe est minimaliste :

benchmark.cpp

Dans le fichier d’implémentation, on ajoute chaque méthode dans les slots correspondants :

Il faut également ajouter la macro QTEST_MAIN, qui crée une fonction main, qui aura pour fonction de créer une instance de la classe Benchmark et d’exécuter les slots privés :

Méthode des deux boucles for

Pour mesurer le temps d’exécution d’une méthode, on utilise la macro BENCHMARK. Le temps du reste du code contenu dans le slot mais en dehors du bloc précédent la macro n’est pas évalué. Pour vérifier que le code généré correctement les nuances de gris, on enregistre les images produites :

Méthode des deux gradients linéaires

Le code étant expliqué dans la solution de l’exercice, je n’entre pas dans le détail ici.

Résultat du benchmark

Lorsque le programme est exécuté, des messages sont générés automatiquement à chaque étape du processus. L’en-tête décrit simplement le nom du programme et les versions de QtTest et de Qt utilisées :

Le premier slot que lance le programme est un slot spécifique, initTestCase, généré par défaut et ne faisant rien. Ce slot permet, si on le souhaite, d’initialiser des objets pour l’ensemble du programme :

Vient ensuite les différents slots que l’on a créé. Le premier est hsvGradient. Lorsque le temps d’exécution du slots est trop petit, la mesure risque de ne pas être précise. Pour palier à cet inconvénient, le code contenu dans le bloc de code suivant la macro BENCHMARK peut être exécuté plusieurs fois, le temps indiqué correspondant au temps moyen mesuré. Ici, le slot hsvGradient a été exécuté deux fois et le temps moyen est de 47 millisecondes :

Pour le slot doubleLinearGradient, le code a été exécuté une seule fois et le temps mesuré est de 57 millisecondes. On voit donc ici que cette méthode est plus lente que la première version (sur le système testé ! C’est à dire Linux dans mon cas. Sous Windows ou Max OS X, il est possible que les résultats soient différents). Cette différence peut s’expliquer par le fait que la génération de deux gradients et la gestion de la transparence est plus lente que l’accès directe aux pixels, sur le système de rendu par défaut (le système Raster) :

Le programme exécute ensuite un slot pour libérer les ressources initialisées dans la fonction initTestCase :

Pour terminer, le programme indique le nombre de slot exécutés sans incident (passed), ceux qui ont échoué (failed) et ceux qui n’ont pas été exécutés (skipped) :

Rendu dans un tampon mémoire

Dans la première méthode, on utilise la fonction Qimage::setPixel pour modifier chaque pixel un par un. Cette méthode permet d’utiliser une interface sécurisée et simple. Malheureusement, les calculs (calcul de l’adresse mémoire correspondant au pixel, conversion de l’espace colorimétrique HSV en RGB) et tests effectués en interne (la position du pixel est bien dans l’image ? Les valeurs de la couleurs sont-elles correctes ?) peuvent ralentir fortement l’exécution.
Il est alors possible d’optimiser le rendu en accédant directement à la mémoire à l’aide de pointeurs : on créer un bloc mémoire de taille suffisante que l’on alloue à une image puis on accède à chaque octet un par un.

ATTENTION : ce type d’approche peut comporter certains risques : en cas d’erreur dans le code, il est possible que l’on écrive dans une zone mémoire qui ne correspond pas à l’image. Aucun test n’est effectué pour vérifier que le pointeur pointe vers une zone valide. L’application peut devenir instable. De plus, il est possible que le code ne soit pas portable et donne des résultats différents en fonction des systèmes d’exploitation utilisés (je l’ai testé uniquement sur Linux, pensez à bien enregistrer tous vos documents avant de lancer le programme sur un autre système:) ).

La première chose a faire est de créer une zone mémoire de taille suffisante : un pixel étant codé sur 32 bits (un octet par composante de la couleur et quatre composantes : rouge, vert, bleu et alpha), il faudra donc réserver un bloc mémoire de width * height * 4 pour contenir toute l’image :

Il n’est pas nécessaire d’initialiser chaque octet du bloc mémoire (avec memset par exemple) puisque l’algorithme utilisé garanti que chaque octet sera initialisé durant l’exécution de celui-ci.

Pour commencer, on crée un pointeur pointant vers le premier octet du bloc mémoire :

On utilise deux boucle for, comme dans la première méthode, pour parcourir chaque pixel (en fait, on parcourt le bloc mémoire linéairement, en « déplaçant » le pointeur octet par octet et non en accédant aux coordonnées (x, y) comme dans le cas d’une image) :

Les valeurs de composantes RGB sont calculés par la méthode présentée dans la version QML de la solution de l'exercice :

Ensuite, pour chaque composante, on affecte la valeur calculée (sous forme de uchar pour être sur qu'elle occupe bien à un octet en mémoire) à l'octet pointé par le pointeur (en dé-référençant celui-ci) puis on « avance » le pointeur d’un octet :

On fait de même pour les autres composantes :

Pour terminer, on enregistre l’image générée :

Résultat du benchmark

Les messages de sortie d’application générés par le slot drawInBuffer indique que cette méthode est plus rapide d’un facteur 10 que les deux autres méthodes, avec un temps d’exécution moyen de 3,9 millisecondes :

Optimisation de l’algorithme

Jusqu’à présent, nous avons simplement travailler sur l’implémentation pour optimiser le rendu des nuances de gris. Une autre approche consiste à travailler sur l’algorithme utilisé et d’essayer de diminuer les calculs effectués.
Quelque soit l’approche utilisée, il sera nécessaire de parcourir l’ensemble des pixels du widget, soit explicitement, comme dans le cas de la première méthode présentée, soit implicitement, comme dans le cas des deux QLinearGradient. On ne pourra donc pas optimiser cette partie (on peut au mieux éviter de parcourir plusieurs fois chaque pixel, comme on fait avec la méthode avec les deux QLinearGradient).
On peut remarquer que, dans chaque méthode présentée jusqu’ici, on travaille avec des nombres réels, ce qui n’est pas optimal. L’idéal serait de travailler qu’avec des nombres entiers, mieux gérés par les processeurs, et d’effectuer que des opérations élémentaires : addition, soustraction et multiplication.

Regardons en détail ce que l’on souhaite faire lorsque l’on parcourt un ligne pour une composante en particulier. La composante est une valeur entière allant de 0 à 255 (ou de 255 à 0) pour les pixels allant de 0 à N (avec N > 256 pour être sur d’afficher toutes les nuances). Il faut donc parcourir chaque pixel et incrémenter, quand c’est nécessaire, la composante. Si on représente cela avec un graphique 2D, on obtient :

avec x, l’index des pixels, et y, la composante de la couleur (source : Wikipédia).

Le lecteur averti aura compris l’idée sous-jacente : calculer la composante de la couleur revient à dessiner une ligne dans un espace (x, y) discret. Or, il existe un algorithme très performant pour réaliser cela : l’algorithme de Bresenham. Il suffit juste de remplacer y par la composante de la couleur. Le lecteur se reportera à l’article de Wikipédia pour l’explication du principe de cet algorithme.

L’implémentation de l’algorithme est assez triviale à partir du pseudo-code. On fera attention aux notations utilisées, qui correspondent au pseudo-code, c’est à dire que y1 correspondent à la composante de la couleur et non à la position verticale du pixel. La variable i est utilisée pour parcourir verticalement l’image dans une boucle for :

L'image générée est un gradient allant du noir au blanc :

Pour générer toutes les nuances, il va falloir imbriquer deux fois algorithme, le premier allant du blanc à la teinte choisie (première ligne de pixels) et le second allant de la teinte (pixel de la première ligne) au noir (pixel de la dernière ligne). Il faut également gérer chaque composante indépendamment.

Pour terminer, il est possible de combiner cette méthode avec la méthode utilisant un tampon mémoire. Le code est très proche du précédent.

Résultat du benchmark

La méthode utilisant l’algorithme amélioré permet de gagner un facteur 3 à 4 par rapport aux premières méthodes :

La version combinant les deux approches permet un gain de performance d’un facteur 4 par rapport à la méthode utilisant un tampon mémoire et un facteur 50 par rapport au premières méthodes :

Accélération matériel sur carte graphique

Pour réaliser le rendu des nuances de gris sur carte graphique, on utilise une classe dérivée de QGLWidget. Il suffit de dessiner un rectangle s’adaptant à la taille du widget, le reste du travail de rendu est réalisé dans le fragment shader : on calcule le rapport entre la position du pixel et la largeur du widget (passé en paramètre) pour calculer la nuance de gris correspondante :

Pour que le fragment shader soit appliqué sur chaque pixel du widget, il suffit de dessiner un quadrilatère sur la totalité de la surface :

Les différents paramètres utilisés dans le fragment shader sont définis à l’aide des fonctions uniformLocation et setUniformValue. Par exemple, pour mettre à jour la taille du widget :

Par contre, je n’ai pas réussit à utiliser les fonctions de benchmarks de Qt Test pour tester la rapidité du rendu par cette méthode. Pour pouvoir mesurer le temps, j’ai ajouté un calcul du nombre de FPS (frame par seconde) avec un simple compteur, incrémenté à chaque cycle et remis à zéro toutes les secondes :

Pour mettre à jour la widget, j’utilise un QTimer avec un délai de 0.

ATTENTION : Il en faut pas laisser le programme tourner trop longtemps avec cette méthode. Le programme tourne en boucle et utilise la carte graphique au maximum de ses capacités, ce qui augmente progressivement sa température. Personnellement, je n’ai pas pris le risque de tester si cela pouvait endommager la carte graphique.

Performances

J’ai réalisé le test sur un ordinateur portable équipé d’une carte Nvidia 8600M GT avec 512 Mo et un widget de 256 x 256 pixels. Avec cette configuration, les mesures donnent un FPS moyen de 5000 fps avec de pointes à 5200 fps, c’est à dire des temps de rendu de l’ordre de 0,2 millisecondes (soit 250 fois plus rapide que les premières versions).

Les sources

Télécharger les sources des benchmarks.

Télécharger les sources de la version OpenGL.

L’objet QML ColorPicker

L’objet ColorPicker permet d’afficher les nuances de gris d’une couleur et de sélectionner une nuance directement en cliquant dans l’item. Les composantes des couleurs sont manipulées directement puisqu’il n’est pas possible d’extraire les composantes d’une couleur donnée en QML.
La couleur principale est définie par les variables main_red, main_green et main_blue. La couleur sélectionnée est récupérée grâce aux variables selected_red, selected_green et selected_blue dans le contexte ColorPickerContext.

La taille de l’item est fixée à 256×256 :

Pour dessiner les nuances de gris, on va utiliser deux gradients linéaires :

• le premier, horizontal, va du blanc à la couleur principale ;
• le second, vertical, va du transparent au noir.

Pour créer les gradients, on commence par définir un rectangle ayant les mêmes dimensions et position que l’item :

On utilise ensuite l’objet gradient pour remplir le rectangle avec le dégradé. Par exemple pour le second gradient :

On obtient ainsi un gradient vertical allant du transparent au noir. Pour le premier gradient, il faut donc effectuer une rotation du rectangle de 90° après l’avoir correctement dimensionné et positionné :

Pour visualiser la position de la couleur sélectionnée, on va afficher un cercle entourant la dernière position connue. Cependant, dessiner un cercle en QML est un peu complexe (il faut créer des objets path pour dessiner des courbes quadratiques et constituer le cercle). Pour simplifier, on va afficher une image de taille 8×8 pixels représentant un cercle avec le fond transparent :

On crée un objet image en indiquant la source du fichier. Par défaut, la taille de l’image est celle du fichier chargé :

Par défaut, on souhaite que le curseur soit placé au centre de l’item. Pour cela, on utilise les variables x et y :

Pour déplacer, le curseur en fonction de la position de la souris, il faut pouvoir identifier cette image :

On pourra alors déplacer l’image en modifiant les variables x et y, en ajoutant le code suivant n’importe où dans notre item :

Pour terminer, il faut pouvoir récupérer les évènements souris survenant sur notre item. Cela est réalisé en créer un objet MouseArea de même dimension que l’item :

Il faut ensuite demander à cette MouseArea de récupérer les clics sur le bouton gauche de la souris :

On va réagir à deux types d’évènements : un clic sur le bouton gauche, qui déclenche un évènement de type onPressed, et le déplacement de la souris avec le bouton enfoncé, qui déclenche un évènement de type onPositionChanged.
Lors de ces évènements, on récupère la position de la souris grâce aux variables mouseX et mouseY que l’on affecte aux positions de l’image avec cursor.x et cursor.y. Cependant, il ne faut pas oublier que la position de cursor correspond au coin en haut à gauche de l’image alors que la souris correspond au centre de l’image. Il faut donc corriger en fonction des dimensions de l’image :

Pour terminer, après un changement de la couleur sélectionnée, il faut recalculer les variables selected_red, selected_green et selected_blue. Pour cela, on appelle un fonction JavaScript updateSelectedColor(), qu’il faudra créer :

Pour connaître la couleur sélectionnée, on ne dispose pas de fonction équivalente à Qimage::pixel(). Les seuls éléments que l’on dispose sont : la position (x, y) de la couleur sélectionnée dans le widget de taille (width, height) et les composantes RGB de la couleur principale.
Il faut donc calculer les composantes RGB de la couleur sélectionnée à partir de ces éléments et de la méthode utilisée pour dessiner l’item.

Lorsque l’on dessine le premier gradient, on va du blanc (1, 1, 1) à la couleur principale (R, G, B). Le rapport entre la position cursor.x et la largeur est équivalent au rapport entre la composante de la couleur principale et le blanc :

On obtient alors l’équivalence suivante :

{r – 1} over {X} ~ = ~ {R – 1} over {width} ~ = ~ pente de la droite

Alors :

r ~ = ~ 1 ~ + ~ (R-1) {X} over {width}

De même pour les autres composantes :

g ~ = ~ 1 ~ + ~ (G-1) {X} over {width} newline
b ~ = ~ 1 ~ + ~ (B-1) {X} over {width}

Lorsque l’on dessine le second gradient, on va du transparent (alpha = 0) au noir (0, 0, 0, 1). La couleur final s’écrit :

couleur finale ~ = ~ couleur initiale * (1 – alpha) ~ + ~ noir * alpha ~ = ~ couleur initiale * (1-alpha)

La transparence alpha est liée à la position cursor.y par :

alpha ~ = ~ {Y} over {height}

On obtient donc la formule suivante pour la composante rouge :

r’ ~ = ~ r * (1 – {Y} over {height} ) newline
r’ ~ = ~ (1 + (R-1) {X} over {width}) * (1 – {Y} over {height} )

De même pour les autres composantes :

g’ ~ = ~ (1 + (G-1) {X} over {width}) * (1 – {Y} over {height} ) newline
b’ ~ = ~ (1 + (B-1) {X} over {width}) * (1 – {Y} over {height} )

La fonction JavaScript s’écrit alors, en utilisant ces formules :

La classe GradientWidget

Pour utiliser cet item QML dans du code C++, il est nécessaire d’écrire un wrapper pour récupérer les signaux et slots de l’item. Cette classe n’est pas un widget et dérive donc de QObject (pour pouvoir utiliser le système de signaux et slots) :

Pour récupérer la couleur sélectionnée, il faut créer une variable pour chaque composante et utiliser la macro Q_PROPERTY pour la rendre accessible en QML. Il faut également définir les fonctions d’écriture (pour modifier la variable depuis le QML) et de lecture (pour lire la variable à l’extérieur de la classe) :

Après avoir mis à jour la couleur avec la fonction setSelectedColor(), il faut émettre un signal contenant la couleur créée à partir des composantes :

Il faut également définir les variables et fonctions pour les deux autres composantes :

La création de l’item ColorPicker est réalisée dans le constructeur de la classe :

Dans ce constructeur, il faut créer un objet QDeclarativeView pour afficher l’item QML puis fournir le code QML à l’aide la fonction setSource. La taille est fixée à 256×256, comme dans le code QML. Dans cet exemple, le code QML est fournit dans un fichier .qml et référencé dans un fichier ressource .qrc :

Pour permettre au code QML de transmettre les variables contenant les composantes de la couleur sélectionnée, il faut récupérer le contexte par défaut de la vue et définir une propriété ColorPickerContext dans celui-ci. Cette propriété permet d’accéder à l’objet dans le code QML à partir de la variable ColorPickerContext et permettre ainsi d’accéder aux propriétés définies ci-dessus :

Les variables view et context sont définies dans l’en-tête de la classe par :

Lors de la création de l’item, on attribue également une couleur principale par défaut à l’aide de la fonction setMainColor() :

Cette fonction setMainColor() est un slot ayant un paramètre, la couleur a attribuer :

Pour transmettre cette couleur au code QML, on utilise la fonction setContextProperty(), qui permet d’attribuer une valeur à une variable QML :

Pour terminer, il faut créer les fonctions show() et move() pour pouvoir afficher et déplacer la vue :

Le résultat final

Voici le rendu obtenu :

Télécharger les sources de cet article.

Conception

Le widget devra simplement afficher un fond (les nuances de gris d’une couleur) et gérer les évènements de la souris (clique et déplacement pour sélectionner une nuance de gris).

Il est possible de partir de plusieurs classes différentes pour créer le nouveau widget. Voyons les avantages et inconvénients de chacune :

1. QWidget est la classe parent de tous les widgets de Qt. Elle fournit l’interface de base commune de tous les objets visibles. Par défaut, elle n’affiche rien et ne fait rien.
2. QScrollArea est destinée à afficher le contenu d’un widget dans un autre, en gérant les barres de déplacement horizontale et verticale. Dans cet exercice, la présence de barre de déplacement n’est pas souhaitée et il est préférable d’ajuster la taille de la zone de dessin à la taille du widget.
3. QLabel permet d’afficher un texte ou une image sans interaction avec l’utilisateur. Même s’il est possible de surcharger les fonctions de gestion des évènements souris, utiliser cette classe pour créer noter widget revient à ne pas respecter la conception de QLabel.
4. QpushButton permet également d’afficher des images mais gère aussi les évènements souris. Mais cette classe n’est pas destiner à gérer la position précise des évènements souris et de réagir différemment en fonction de celle-ci.

Au final, même si certaine classe présentent des fonctionnalités qui seraient intéressantes (affichage d’images, gestion des clics), seule l’utilisation de QWidget respecte la conception des objets Qt.

En partant de QWidget, quels seront les fonctions qu’il faudra implémenter ?

1. L’affichage des nuances de gris sera réalisée dans la fonction paintEvent(), qui prend en charge le dessin du widget. Il suffit de dessiner les nuances de gris puis la position de la couleur sélectionnée par un petit cercle.
2. La création des nuances de gris peut être réalisée directement dans paintEvent(). Cependant, cela implique de redessiner l’image à chaque déplacement de la souris, ce qui peut rendre le widget non fluide. De plus, la récupération de la couleur sélectionnée utilisera la fonction QImage::pixel(). Au final, il est donc préférable de dessiner les nuances de gris dans une QImage et d’afficher cette QImage dans la fonction paintEvent(). Cette image sera recalculée que lors d’un changement de la couleur principale ou lors du redimensionnement du widget.
3. La fonction resizeEvent() sera utilisée pour mettre à jour l’image contenant les nuances de gris.
   Les évènements souris seront gérés par les fonctions mousePressEvent(), mouseMoveEvent() et mouseReleaseEvent().
4. Le changement de couleur principale et la sélection d’une couleur utilisera le système de signaux et slots, pour faciliter l’interaction entre les widgets.

Pour dessiner les différentes nuances de gris d’un couleur, deux méthodes sont envisageables :

1. Dessiner deux gradients superposés : un premier gradient linéaire, horizontal, allant du blanc (à gauche) à la couleur principale (à droite) ; un second gradient linéaire, horizontal, allant du transparent (en haut) au noir (en bas).
2. Faire varier les composantes S (saturation) et V (valeur) d’une couleur en fonction des coordonnées (x, y) d’un pixel. La saturation permet d’aller du blanc (S=0) à la couleur (S=255) et correspond donc à l’axe horizontal. La valeur permet d’aller du noir (V=0) à la couleur (V=255) et correspond donc à l’axe vertical.

Ces deux méthodes sont identique visuellement (mais présentent en réalité des petites différences) et permettent toute deux d’afficher toutes les nuances de gris d’une couleur.

Interface

Pour créer l’interface de notre classe, on crée une classe GradientWidget héritant de Qwidget, avec son constructeur :

Les fonctions de gestion des évènements surchargent les fonctions de même nom de QWidget :

La connexion avec les autres widgets est assurée par le signal envoyé lors de la sélection d’une couleur et le slot reçu lors du changement de couleur principale :

Les variables privées permettent de conserver les couleurs principale et sélectionnée, l’image dans laquelle on dessine les nuances de gris, la position du curseur et une variable boolean indiquant si la mouvement de la souris correspond à un clic ou non :

Les variab Pour finir, deux fonctions privées, permettant de redessiner les nuances de gris et de mettre à jour la couleur sélectionnée :

Implémentation

Commençons par l’implémentation de la fonction updateSelectedColor(). Celle-ci récupère simplement la couleur du pixel de m_gradient_image à la position m_cursor_position, émet le signal colorSelected() puis appelle la fonction update() pour mettre ajour le widget :

Création des nuances avec QLinearGradient

La première version de la fonction updateGradientImage() utilise l’approche à deux gradients :

On crée une QPixmap de la taille du widget puis un QPainter pour dessiner dedans. Par défaut, nous n’avons pas besoin de dessiner des traits donc on supprime le QPen :

Pour dessiner des gradients linéaires, Qt propose une classe QLinearGradient. Il suffit donc de préciser les positions des points du gradient et les couleurs de ces points. Pour le premier gradient, les couleurs doivent aller du blanc (Qt::white) à la position (0, 0) à la couleur m_main_color à la position (with, 0) :

Puis on dessine un rectangle de la taille du widget :

Pour le second gradient, les couleurs doivent aller du transparent (Qt::transparent) à la position (0, 0) au noir (Qt::black) couleur m_main_color à la position (0, height) :

On convertit ensuite la Qpixmap en Qimage et on la conserve dans m_gradient_image :

Pour finir, puisse que le gradient à été mis à jour, on met également à jour la couleur sélectionnée :

Création des nuances avec HSV

La seconde version de updateGradientImage() utilise deux boucles imbriquées qui parcourent l’ensemble des pixels de l’image et qui calcul la couleur en faisant varier la saturation et la valeur en fonction de la position (x, y). Pour commencer, il faut redimensionner l’image de destination si celle-ci n’est pas identique aux dimensions du widget :

La teinte est obtenue à partir de la couleur principale :

On parcourt l’ensemble des pixels de l’image à l’aide de deux boucles imbriquées :

Il reste plus qu’a dessiner un cercle à la position m_cursor_position :

Le diamètre du cercle est une constante définie en début du fichier d’implémentation :

Lors d’un évènement souris de type mousePressEvent, on teste si l’utilisateur a cliqué sur le bouton gauche :

Si c’est le cas, on active le suivi des mouvements de la souris, on récupère la positon de la souris dans m_cursor_position puis on met à jour la couleur sélectionnée :

Lors d’un évènement de type mouseReleaseEvent, on déssactive le suivi de la souris et on met à jour la couleur sélectionnée :

Les mouvements de la souris sont détectés par l’évènement mouseMoveEvent. Pour que ces événements soient pris en compte pour le widget, il faut les activer en utilisant la fonction setMouseTracking(true) dans le constructeur. Ces évènements mouseMoveEvent sont activés même lorsqu’aucun bouton n’est appuyé. C’est la fonction de la variable m_tracking d’indiquer si on déplace la souris en conservant un bouton cliqué ou non.
Lorsque l’on maintient appuyé un bouton de la souris et que l’on déplace celle-ci en dehors du widget, des évènements mouseMoveEvent continuent d’être envoyé. Si on prend en compte ces évènements, on risque de demander la couleur de pixels en dehors de la taille de m_gradient_image, ce qui provoquera des erreurs. Il faut donc tester si la position de la souris est dans le widget. Au final, le code de mouseMoveEvent sera :

Lors d’un changement de taille du widget, il suffit de remettre à jour le gradient :

Il ne reste plus qu’a implémenter le constructeur :

Ainsi que le slot setMainColor() :

Le résultat final

Voici le rendu obtenu :

Télécharger les sources de cet article.

Première partie : créer une zone de sélection avec gradient

Bonjour à tous,

Nous savons que vous attendez avec impatience le prochain défi Qt, cependant un défi de qualité prends du temps à organiser et mettre en place. Pour palier à votre envie de développer et de vous faire les dents sur un nouveau projet, nous vous proposons un nouveau concept : les exercices Qt.

Le principe

Des petits sujets réguliers pour lesquels vous pouvez apporter une solution en détaillant quelques étapes clés imposés. La durée de l’exercice dépendra de la difficulté de l’énoncé. Il est possible qu’un sujet conséquent en travail soit proposé et ainsi découpé en plusieurs parties représentant une suite d’exercices sur le même thème.

Tout le monde peut ainsi proposer une solution pour répondre à l’exercice posé. Dans le cas d’un exercice en plusieurs parties, la meilleure solution pourra être utilisée par les autres participants pour la suite de l’exercice.

Il est impossible pour l’équipe de réunir un jury et réaliser un barème aussi poussé que celui des défis Qt. La meilleure solution sera ainsi désignée d’un point de vue plus subjectif que pour les défis Qt par les responsables de la rubrique Qt, à savoir dourouc05 et moi-même et éventuellement d’autres membres de l’équipe Qt en fonction des disponibilités de chacun.

Les exercices seront ainsi proposés le vendredi (vous permettant d’y travailler dès le week end après avoir découvert le nouveau sujet). La fin du dépôt des propositions aura lieu le vendredi soir à 23h59, un certain nombre de semaines (dépendant de la difficulté de celui-ci) après la présentation du sujet et le vainqueur sera désigné dans la semaine suivante avant la proposition du nouvel exercice.

Nous essayerons de faire attention à ce qu’il n’y ait pas de copie entre les codes des participants en appliquant la règle que le premier code publié sur le forum « appartient » au membre l’ayant posté. Il existe bien sur des réponses à ces solutions sur internet, mais quel est l’intérêt pour vous de les utiliser ?

Le premier sujet !

Le thème

Ce premier exercice fait parti d’un thème qui est la réalisation d’un color picker. Ci-dessous, quelques color pickers connus mais libre à vous de faire travailler votre imagination pour nous donner une meilleure solution au final :

Ce thème est découpé en trois parties qui toutes durent deux semaines. Un nouvel énoncé d’exercice sera donc publié toutes les trois semaines (en comptant la semaine de correction).

Première partie : widget personnalisé pour affiche et sélectionner la nuance de gris d’une couleur

Création d’un widget permettant de sélectionner la nuance de gris à partir d’une couleur. Seul le widget affichant le gradient de la nuance de gris sur une couleur sera évalué mais votre fenêtre peut afficher la couleur en cours et les valeurs de celle-ci pour démontrer le bon fonctionnement de celui-ci.

Le widget peut être carré, rectangulaire, sphérique, en cercle, libre à votre imagination.

Les étapes d’explications imposées :

1. Mise en place de la structure du widget (héritage, composition…) ;
2. Réalisation du gradient ;
3. Sélection et récupération de la couleur à partir du gradient.

Vous avez donc jusqu’au vendredi 3 septembre 23h59 pour nous fournir une solution. Le dépôt des solutions ce fait sur le forum à la suite de ce message.

J’espère que l’idée vous plait, n’hésitez pas également à nous faire part de votre participation à la suite de ce message, de présenter votre solution en avant première et je finirai par dire : à vos claviers !

Seconde partie : accompagner le widget d’un sélecteur de couleur et amélioration de celui-ci

L’objectif est de continuer le widget en l’améliorant et ajoutant d’autres fonctionnalités. Pour ceux qui n’auraient pas un widget fonctionnel, voici une archive contenant la classe du widget du vainqueur de la première partie à savoir gbdivers, améliorée par mes soins pour prendre en compte les malus qui lui ont été mis à la correction !

La première amélioration requise pour la partie deux est la création d’un slider permettant la création de la couleur principale (teinte ou hue en anglais). L’image ci-jointe vous montre de quoi je parle :

Ce slider peut faire partie du widget ou être un widget indépendant. Je vous conseille de regarder la classe QSlider et les paramètres pour la personnalisée.

De plus un ensemble de champ QLineEdit respectant un certain format QIntValidator devra permettre d’afficher et de modifier la valeur de la teinte, saturation ou valeur. En cas de modification, le changement se répercutera sur le widget par le déplacement du point de sélection. Il existe donc une connexion dans les deux sens entre ces différents éléments.

Par la suite, il faudra modifier le widget existant pour permettre également d’afficher les dégradés de la saturation et de la valeur (et non plus la teinte, hue en anglais).

Exemples :

C’est tout pour les étapes imposées dans cette seconde partie qui durera deux semaines.

Pour les personnes qui ont de l’avance, vous pouvez réfléchir à n’afficher que les couleurs disponibles pour le web et la représentation des dégradés dans les autres espaces colorimétriques.

Si vous avez besoin d’explications supplémentaires, n’hésitez pas à poser des questions à la suite de ce message. De plus la correction et le code source de l’ensemble des candidats pour la première partie est disponible dans ce sujet.

Bon courage !

Vous pouvez commenter cet article sur le forum.

Complexité du langage ou de l’apprentissage

Cette partie a été écrite par JolyLoic.

Lorsque l’on compare différents langages, il existe plusieurs notions de complexité, dont la confusion est une des causes qui fait que ces comparaisons s’enflamment.

Il y a au moins :

• la complexité intrinsèque d’un langage, celle qui correspond à l’effort à réaliser pour y devenir un gourou qui connait tous les détails les plus arcanes. Cette complexité peut quasiment se mesurer au nombre de pages d’un document décrivant le langage. Sur ce plan, le C++ est beaucoup plus complexe que le C, c’est indéniable ;
• la complexité au jour le jour d’un langage, qui est liée au niveau de discipline mentale nécessaire pour coder, ainsi qu’à la puissance des abstractions que l’utilisateur peut mettre en œuvre pour l’aider. Je suis convaincu que sur ce plan, le C++ est beaucoup plus simple que le C ;
• la complexité d’apprentissage. Elle correspond à la difficulté du parcours d’un étudiant ne connaissant rien et devant apprendre assez du langage pour en devenir professionnel. Je pense là aussi que le C++ et plus simple que le C, mais la réponse est moins tranchée.

La complexité intrinsèque et la complexité au jour le jour sont bien évidemment en opposition, puisque si l’on complexifie un langage, ce n’est pas par pur plaisir masochiste, mais bien pour le rendre plus puissant, donc plus efficace au jour le jour. La complexité d’apprentissage est liée aux deux autres, mais aussi à la notion de progressivité.

Cette notion de progressivité de l’apprentissage me semble importante. À part à un haut niveau post-bac, où l’on suppose les étudiants comme des experts dans l’art d’ingurgiter des connaissances (et où à mon avis, on se trompe de méthode, mais c’est un autre sujet), l’ordre d’apprentissage n’a rien à voir avec un ordre logique, qui irait du plus théorique au plus pratique (ce qui consisterait pour notre langue maternelle à faire de la linguistique, de la grammaire et à apprendre le dictionnaire dans l’ordre, avant de dire papa-maman, et dans le programmation à préconiser l’apprentissage du théorème du point fixe, du lambda calculus et autres modélisations mathématiques des langages avant de faire un hello world), ou encore, pour parler d’informatique du plus proche du matériel au plus éloigné (qui consisterait à faire de l’électronique, puis de l’assembleur, puis du C puis du C++).

Non, l’apprentissage se fait de manière pragmatique, en parcourant le sujet à enseigner de manière en apparence erratique, mais avec pour objectifs :

• que chaque pas ne soit pas trop gros, afin de ne perdre personne ;
• que le parcours soit à chaque étape intéressant, afin de motiver les gens.

Un des points de passage de plus haute complexité du C comme du C++ est la notion de pointeurs, avec ses corollaires d’allocation dynamique de la mémoire (mais même sans ça, la notion de pointeur et de valeur pointée pose bien des problèmes). Or, en C, impossible d’écrire un programme un minimum intéressant sans utiliser explicitement des pointeurs. En C++ (ou des d’autres langages comme java ou C#), l’utilisation de ces pointeurs peut être cachée pendant assez longtemps et on a donc bien plus de liberté pour choisir un parcours le long duquel la courbe d’apprentissage ne présente pas de murs trop importants.

Apprentissage d’un langage ou de la programmation

Avant d’expliquer et critiquer les phrases indiquées dans l’introduction, il convient de préciser quel est l’objectif recherché dans l’apprentissage. Si l’on est dans le cadre de l’apprentissage d’un langage précis, par exemple dans le cadre d’un cours scolaire, dans lequel le langage à utiliser est imposé, alors bien évidemment, la question de savoir si le C++ est plus adapté pour les débutants n’a pas lieu d’être. Nous nous placeront donc dans le cas où la personne qui souhaite apprendre le C ou le C++ est libre de son choix.

Quelle est la différence entre apprendre un langage et apprendre la programmation ? Dans le premier cas, l’attention se porte sur l’apprentissage de la syntaxe du langage, ce que l’on fait de ce langage compte peu finalement. Dans le second cas, l’objectif est de savoir concevoir efficacement un programme permettant de répondre à une problématique donnée. Que ce soit dans le cadre amateur ou professionnel, ce dernier objectif est beaucoup plus intéressant et c’est dans cette optique que se place ce billet de blog.

Précisons ce que signifie ce que l’on entend par « efficacement ». Dans la création d’un programme, on pense en général à la phase de codage et l’on comprend facilement qu’entre deux langages, si le premier permet d’obtenir le même résultat que le second, mais en utilisant 10 fois moins de lignes de code, alors il sera beaucoup plus efficace d’écrire un programme dans ce langage. Cependant, la création d’une application ne se limite pas à écrire du code et l’expérience montre que l’on passe beaucoup de temps sur d’autres tâches : la conception du programme, la correction des bugs, la validation du programme (vérifier que le programme donne le résultat correct). Le terme « efficacement » doit donc être considéré en analysant le temps global de développement et pas simplement la phase de codage.

Conception impérative et objet

La comparaison entre les différents paradigmes de programmation, leurs intérêts et inconvénients respectifs, leurs efficacités, n’est pas le propos de cet article, je ne vais donc pas m’attarder sur ce point. Signalons simplement que la raison même de la création de la programmation objet est de faciliter la création d’application, on peut s’attendre à ce que la conception en C++ utilisant des objets (correctement…) sera plus efficace qu’en C.

Erreurs à la compilation et l’exécution

Problématique

Probablement tous les développeurs expérimentés ont déjà eu le problème suivant, d’un bug dont l’origine était indéterminée et qui a nécessité plusieurs heures de recherche pour le corriger. Partant de ce constat, on peut tirer la règle suivante : plus la détection des erreurs est précoce, plus il sera facile de les corriger. Autrement dit, les erreurs survenant à la compilation seront beaucoup plus simples à corriger que les erreurs survenant lors de l’exécution (et l’une des forces des templates en C++ est de pouvoir justement réaliser beaucoup de vérifications à la compilation, sans surcoût à l’exécution, mais cela sort du sujet de ce blog).

Pour être plus concret, voyons un exemple avec la vérification de la constance des variables (« const-correctness »). Le mot-clé const, utilisé pour le passage de paramètres dans les fonctions, est un contrat que passe l’utilisateur d’une fonction avec le créateur de cette fonction. Il permet de dire : cette variable ne sera pas modifiée dans cette fonction.

En théorie…

Voyons ce que cela donne en pratique. Imaginons une fonction foo() prenant une chaîne de caractères constante et pouvant modifier cette chaîne. Le respect de cette constance implique donc que la fonction ne doit pas travailler sur la chaîne passée en argument de la fonction (potentiellement non modifiable), mais sur une copie modifiable de cette chaîne.

Cas du C

Voyons par exemple le code suivant, qui convertit un simple const char* en char* (donc qui supprime le mot-clé const) :

Lorsque l’on compile avec un compilateur C, celui-ci ne donne qu’un simple avertissement sur le fait que l’on modifie une variable constante en non constante. Malheureusement, les warnings sont souvent ignorés par les débutants et le code ne sera pas corrigé. C’est une mauvaise pratique largement répandue et c’est souvent une bonne chose d’activer l’option -Werror dans gcc, pour que les warnings deviennent des erreurs). On va pouvoir observer des comportements différents en fonction du code de bar(). Si la fonction bar() ne modifie pas la chaîne, par exemple avec le code suivant, alors il n’y aura pas de problème, le programme s’exécutera sans erreur :

En revanche, si la fonction bar() modifie la chaîne, on va obtenir une erreur à l’exécution. Par exemple, le code suivant :

Ce code va générer l’erreur suivante :

Ce message d’erreur ne nous apprend pas grand-chose. Il indique simplement qu’il y a un problème d’accès sur une mémoire invalide, mais n’indique pas que l’on ne respecte pas le const-correctness et ne précise pas la ligne de code où se situe le problème. On imagine bien alors que dans un programme contenant plusieurs milliers de lignes de code, il sera difficile de trouver l’erreur.

Même si le premier code de bar() ne provoque pas d’erreur à l’exécution, il n’en reste pas moins que le code de foo() est la source du problème. Cependant, il n’y a pas de validation réalisée par le compilateur et il est facilement possible dans ces conditions d’avoir du code potentiellement problématique qui fonctionne… quelques temps. Et à l’occasion d’une modification mineure, ce code problématique va déclencher une erreur d’exécution et la recherche de l’erreur sera fastidieuse. On dit souvent, de façon humoristique, qu’un code problématique et qui fonctionne quand même « que le programme tombe en marche ».

Sans cette vérification à la compilation, il est facile de se tromper, par exemple en écrivant le nom des fonctions. Supposons que l’on a deux fonctions, une version qui ne modifie pas la chaîne et utilise donc directement la chaîne passée en argument ; une version qui modifie la chaîne, par exemple en appelant realloc(). Normalement, il faudrait récupérer le pointeur retourné par la fonction, mais comme on appelle la mauvaise fonction, on oublie de le faire :

En C, lors de la compilation, il y aura un simple warning, qui est facilement manqué. À l’exécution, le message d’erreur n’indique pas l’origine du problème. Plus que le fait que le code à écrire est plus long qu’en C++, il y aura une perte de temps très importante, plusieurs heures voir plusieurs jours, pour trouver l’origine des erreurs.

Cas du C++

En C++, la situation sera beaucoup plus simple : ce code génère une erreur suivante, indiquant que l’on essaie de convertir une variable constante en variable non constante :

L’erreur est simple (profitons-en, ce n’est pas toujours le cas en C++) et parfaitement localisée, la correction du code sera directe et rapide.

Détection des fuites mémoires

Problématique

Commençons par un rappel : qu’est-ce qu’une fuite mémoire ? Lorsque l’on alloue une variable dynamique sur le Tas, le bloc mémoire alloué doit être détruit à un moment donné, quand on en a plus besoin, pour éviter de saturer la mémoire disponible. L’adresse mémoire est sauvegardée dans un pointeur et il suffit d’appeler la fonction adéquate pour libérer la mémoire, en fonction de la fonction utilisée pour l’allouer : free() avec malloc ou calloc, delete avec new, delete[] avec new[]. Une fuite mémoire survient lorsque cette libération n’est pas réalisée, par exemple si on perd le pointeur, si on n’appelle pas la fonction de libération adéquate, voir qu’on appelle pas du tout cette fonction.

La difficulté avec les fuites mémoires est que c’est un problème qui survient exclusivement à l’exécution, on retombe sur le souci décrit dans le chapitre précédent : la localisation pourra être complexe et longue. Il existe des outils d’analyse des allocations, tel que valgrind, qui permet de rechercher ce type de problème (et il est recommandé de l’utiliser régulièrement), mais s’il est possible de minimiser les risques lors de la phase de codage, cela pourra améliorer l’efficacité.

Cas du C

Revenons sur le code précédent de foo() et corrigeons le problème de const-correctness en copiant la chaîne constante dans une nouvelle chaîne non constante. Pour simplifier le code, il est possible d’écrire deux fonctions d’aide pour gérer la mémoire : createString(), pour allouer la mémoire et copier la chaîne, et destroyString(), pour libérer la mémoire. Une implémentation de ces fonctions peut-être la suivante :

Le code de la fonction foo() est modifié de la façon suivante :

Dans un code aussi simple, il est peu probable que le développeur oublie de libérer la mémoire à la fin de la fonction foo(). Par contre, dans une situation plus complexe, dans lequel la création de la chaîne est réalisée à un endroit du programme, l’utilisation à d’autres endroits et la libération encore ailleurs, il peut être difficile de savoir si la mémoire est correctement libérée.

De plus, le code précédent n’apporte pas de garanties fortes sur la libération. Par exemple, si le code entre createString() et destroyString() contient des return, la fonction destroy() ne sera pas appelée. Il est de la responsabilité du développeur de penser à appeler destroy() avant chaque return, ce qui peut être facilement oublié. Si la fonction manipule plusieurs objets dynamiques, il faut savoir à tout moment quelles sont les variables allouées et celles qui ne le sont pas.

Plus pernicieux, le code peut allouer un nouveau bloc mémoire et attribuer l’adresse dans un pointeur, ce qui invalidera celui-ci et provoquera une fuite.

En général, on trouve deux profils sur le forum : ceux qui croient qui ne feront jamais d’erreurs aussi grossières et ceux qui savent qu’il peut arriver de faire de telles erreurs. En général aussi, les premiers viennent sur le forum parce qu’ils ont des problèmes avec leur code, les seconds viennent pour aider les premiers.
Choisissez votre camp. Et si vous faites partie du premier groupe, posez-vous peut être des questions…

Cas du C++

La situation pourrait sembler plus compliquée en C++. En effet, le C++ ajoute un système de gestion d’erreurs, absent du C : les exceptions. Ce système peut briser l’ordre séquentiel d’exécution du code et il peut être difficile de garantir la robustesse du code.

Cependant, le C++ propose également un système qui permet de transférer la responsabilité de la libération de la mémoire. En effet, grâce au RAII (acquisition de ressources à l’initialisation), la libération est sous la responsabilité d’une classe au lieu d’être sous celle de l’utilisateur. Le RAII est un principe qui peut être implémenté par les concepteurs d’une classe utilisant des ressources dynamiques, mais pour simplifier le travail, la bibliothèque standard STL fournit déjà de nombreuses classes encapsulant le RAII : std::string pour les chaînes, std::vector pour les tableaux, std::shared_ptr pour les pointeurs, etc.

Voyons par exemple une fonction utilisant une chaîne de caractères en C++ :

Ce code, en plus du fait d’être beaucoup plus simple, nous garantit que quelles que soient les lignes de code contenues dans la fonction, la chaîne de caractères str sera correctement libérée lorsque l’on sort de la fonction et quelle que soit la façon dont on sort de cette fonction (par return, par exception). L’attention du développeur peut se focaliser sur le problème à résoudre et plus sur les détails de gestion de la mémoire.

Conclusion

D’autres arguments peuvent être abordés pour justifier l’apprentissage du C avant le C++ (on parle de l’approche historique de l’apprentissage du C++), mais une analyse peut facilement les mettre à mal. Par exemple, l’argument selon lequel l’apprentissage bas-niveau en C permet de mieux comprendre ensuite la programmation plus haut-niveau en C++. Outre le fait que l’apprentissage de la gestion manuelle de la mémoire n’est pas un prérequis pour comprendre les notions d’allocation dynamique, de Pile et de Tas, la pratique montre que ceux qui abordent l’apprentissage par cette approche se perdent dans les détails et le débogage et ont plus de mal à assimiler les concepts plus haut-niveau (conception objet, encapsulation, principes de programmations objet, etc.)

On pourrait croire que mes propos sont exagérés, qu’il est rare de faire des erreurs aussi grossières, que cela n’empêche pas de comprendre les concepts de programmation objet. En pratique, on voit régulièrement sur le forum les étudiants faire les mêmes erreurs d’apprentissage (un exemple récent), mais ce n’est pas une fatalité et il est possible de corriger notre façon d’enseigner la programmation en C++.

Remerciements

Merci à JolyLoic pour la partie qu’il a rédigée et ses remarques, à Winjerome, Kalith et LittleWhite pour leur relecture et leurs remarques, à Winjerome pour ses corrections orthographiques.

Imaginons que l’on souhaite créer une classe représentant un point en 3D. On écrit alors le code suivant :

On utilise ensuite cette classe à plusieurs endroits dans notre code, par exemple dans une fonction glVertex (remarque : pour ceux, qui comme LittleWhite bloquent sur l’utilisation de glVertex, je précise que ce n’est qu’un code d’exemple ; glVertex est une fonction dépréciée et ne doit plus être utilisée) :

Jusque là, tout va bien.

(Ou presque. Si on modifie les coordonnées d’un point, on obtient un nouveau point, bien distinct du premier. Les setters sont donc contraire au respect de la sémantique de valeur et doivent être évités.)

Là où les choses se gâtent

Nos besoins évoluent. Au lieu de simplement vouloir faire de la représentation 3D sur nos points, on doit également faire des calculs pour de la simulation physique. On a la chance d’avoir une carte graphique prenant en charge l’extension fp64 et on décide donc d’utiliser double au lieu de float :

Malheureusement, le code qui utilise cette classe Point3D doit également être modifié pour pouvoir compiler. En effet, glVertex3f prend comme paramètres des float, il faut maintenant utiliser glVertex3d qui prend comme paramètres des double :

La modification est relativement facile. Maintenant imaginons que cette classe Point3D est utilisée dans des centaines de ligne de code. Imaginons aussi que toutes vos classes présentent le même problème d’exposer des détails d’implémentation interne. À chaque fois que l’on doit modifier une classe, on se retrouve avec plein de bugs à la compilation et on doit perdre du temps à corriger toutes les lignes de code utilisant notre classe. C’est un problème que connaissent beaucoup de débutants (et d’autres développeurs plus anciens… mais aiment faire des erreurs de débutants). Quelle perte de temps ! On parle de couplage fort entre deux classes quand la modification de l’une de classe implique la modification de l’autre classe. Sinon, on parle de couplage faible.

En utilisant les templates, on améliore un peu la situation. On laisse la responsabilité de choisir le type utilisé en interne à l’utilisateur de notre classe. Il sait donc quelle fonction appeler selon le contexte :

Même si le code est meilleur que le précédent, il est encore améliorable. L’idéal serait de ne plus avoir à choisir manuellement la fonction à appeler et laisser le compilateur faire le travail pour nous.

Comment corriger ce problème ?

Le premier principe qui n’est pas respecté dans ce cas est le principe de ségrégation des interfaces. Ce principe dit « Une classe ou une fonction cliente ne doit pas dépendre d’interfaces dont elle n’a pas l’utilité » (source). Dit autrement, cela veut dire que si une classe A utilise une classe B et que cette classe B utilise une classe C, A n’a pas à connaître C. Dans notre exemple, il faudrait que le code qui utilise la classe Point3D n’a pas à connaître le type utilisé en interne (float ou double).

Mais le problème est plus profond (et critique) que cela. Le problème vient en fait d’une mauvaise compréhension de ce qu’est l’encapsulation. La règle est la suivante : « On encapsule un comportement, pas des propriétés » (source). Voyons ce que cela implique en pratique pour notre classe représentant un point en 3D. Si on pense en termes de propriétés, comme on l’a fait au début, un point dans un espace 3D est effectivement un objet représenté par ses trois composantes réelles x, y et z. Si on pense en terme de comportement, l’implémentation sera différente. Quels sont les comportements attendus pour notre point ? En suivant notre code d’exemple précédant, le seul comportement que l’on souhaite implémenter est de pouvoir l’afficher. On écrit donc simplement le code suivant :

La différence par rapport au code précédant est ridicule en terme de travail à fournir pour l’implémentation. On a simplement refactorisé l’appel à glVertex dans une fonction membre de Point3D. Par contre, en terme de sémantique, la différence est énorme : le code client n’a plus besoin de connaître les détails d’implémentation, notre code est plus facilement évolutif et donc efficace. Les modifications à apporter à notre code en cas de changement est localisé : on sait que si l’on modifie une variable membre d’une classe, on n’a que les fonctions membres de la classe à modifier et rien d’autre.

Si on est paresseux (et donc intelligent), on va utiliser la version template pour plus de souplesse, par exemple avec des spécialisations :

La version template demande un peu plus de ligne de code que la version non template et peu donc demander un peu plus de travail pour le développeur. Pour autant, elle est préférable puisqu’il ne sera plus nécessaire de modifier le code en fonction des besoins du code client (respect du principe ouvert-fermé). Si on a plusieurs fonctions qui dépendent du type utilisé en interne, on peut également utiliser une classe de traits et polices :

Avec ce code, la liste des fonctions à appeler en fonction du type utilisé en interne est localisé dans une même classe de traits. Et si on souhaite ajouter un nouveau type, il suffit d’ajouter une nouvelle spécialisation pour la classe de traits, sans rien modifier au code existant.

Pour terminer, un peu de lecture
Le respect de ces principes est une méthode pour éviter les couplages trop forts entre les classes. Il existe d’autres méthodes pour découpler des classes (ie diminuer la force du couplage). Tout le monde connait par exemple la séparation du code des classes dans un fichier d’en-tête (partie la moins susceptible d’être modifiée) et un fichier d’implémentation (partie plus facilement modifiable). On peut également citer l’idiome Pimpl (Pointer To Implementation) ou l’utilisation des signaux et slots, deux techniques très utilisée dans Qt.

En complément, Emmanuel Deloget a publié quelques articles intéressants sur les principes de programmation objet :

• valider et corriger une architecture objet première partie et seconde partie par Emmanuel Deloget ;
• le principe d’encapsulation, le principe de ségrégation des interfaces et le principe ouvert-fermé par Emmanuel Deloget ;
• la guerre des accesseurs par Emmanuel Deloget ;
• présentation des classes de Traits et de Politiques en C++ par Alp Mestan ;
• l’idome pImpl (WikiBooks) ;
• Boost.Signals (documentation de Boost) ;
• les signaux et slots dans Qt (documentation de Qt 4.8).

Commentaires
Vous pouvez réagir à ce billet sur le forum dans cette discussion. Merci.

Lorsque l’on souhaite faire communiquer des objets entre eux, il nécessaire en général que les objets se connaissent mutuellement. Par exemple

Ce code présente cependant plusieurs problèmes :

• il faut que la classe Sender connaisse la classe Receiver et cela implique d’ajouter une dépendance (include) entre ces classes ;
• il est nécessaire de créer une fonction spécifique dans Sender pour chaque type de classe Receiver et pour chaque slot possible ;
• il ne permet pas de gérer des connexions vers plusieurs objets Receiver et il faut modifier le code pour gérer une liste de Receiver.

Ces contraintes s’accumulent dans un framework complexe comme Qt et cela alourdit fortement le code en ajoutant un nombre important de dépendances inutiles. Le code devient très vite ingérable (*).

Le système des signaux et slots permet de faire de s’affranchir de ces contraintes. Il est ainsi possible de faire communiquer des objets entre eux sans qu’il soit nécessaire que ces objets se connaissent mutuellement. On peut également choisir lors de la connexion le slot que l’on souhaite appeler lorsque le signal est émis. On passe ainsi d’un couplage fort (nécessité d’avoir une dépendance) à un couplage faible (plus de dépendance nécessaire) et l’on parle de découplage des classes.

(*) Il est possible d’utiliser d’autres approches que celle présentée ici. En particulier, on peut utiliser les pointeurs de fonctions ou équivalents (callback). Le lecteur intéressé par la question pourra par exemple étudier l’approche utilisée dans Boost.Signals

Le système des signaux et slots dans Qt

Le système de signaux et slots de Qt est relativement simple. Lorsqu’un événement se produit, un signal est émis. Tous les slots qui sont connectés à ce signal sont alors exécutés. La fonction QObject::connect permet de créer une telle connexion. La forme la plus classique de cette fonction prend en paramètres un pointeur vers l’objet émetteur, le nom du signal (ainsi que la liste des types des arguments du signal), un pointeur vers l’objet recepteur et pour terminer le nom du slot (ainsi que la liste des types des arguments du slot). Il est possible de connecter plusieurs signaux à un même slot, un signal à plusieurs slots ou un signal avec un signal. Le compatibilité entre les classes et les signaux et slots est vérifiés lors de la compilation.

Les classes de Qt fournissent de nombreux signaux et slots par défaut. Ces signaux et slots seront disponibles dans les classes créées par les utilisateurs et dérivant des classes de Qt. Il est également possible de créer ses propres signaux et slots et de les connecter aux signaux et slots par défaut de Qt :

Créer une connexion dans Qt 5

Dans Qt 4, il est possible de connecter uniquement les fonctions déclarées comme signaux et
slots dans la classes, comme indiqué dans le code d’exemple précédant. Dans Qt 5, il est
maintenant possible de connecter directement des pointeurs de fonctions ou d’utiliser des
fonctions lambdas.

La connexion de pointeurs de fonctions est similaire à une connexion classique, en donnant un pointeur sur les objets et sur les fonctions. Les classes émettrices et réceptrices doivent dériver de QObject mais il n’est pas nécessaire de déclarer les fonctions slots avec le mot clé « slots ».

L’avantage de cette écriture est que la compatibilité des paramètres est effectuée lors de la compilation et non lors de l’exécution.

Pour les fonctions lambdas :

Dans ce code, on capture le pointeur vers l’objet recepteur et on récupère le paramètre passé par la fonction send() puis on appelle dans le corps de la lambda le fonction receive(). Le résultat obtenu est identique au code précédant, mais il est possible de faire beaucoup d’autres choses dans la lambda (par exemple déconnecter tous le signaux ou parcourir tous les enfants de l’objet récepteur).

Si le compilateur utilisé ne support pas les variadic template, les signaux et slots doivent avoir moins de 6 paramètres.

Remarques
Vous pouvez télécharger un projet d’exemple montrant ces nouvelles fonctionnalités en action : la page de téléchargement.

Les images et codes d’exemple sont issus de la documentation de Qt5 disponible à cette page : Qt 5.0: Signals & Slots.

Quelques rappels
Les geometry shaders sont optionnels et s’intercalent entre les vertex shaders et les fragment shaders. Ils travaillent sur des primitives (triangle, ligne, points, avec un maximum de 6 vertices) et permettent de générer d’autres primitives. Ils sont disponibles dans le Core depuis OpenGL 3.2 / GLSL 1.5 ou avant avec l’extension GL_ARB_geometry_shader4 (en ajoutant le code #extension GL_EXT_geometry_shader4 : enable dans le geometry shader).

Lors de l’appel à glDrawArray ou glDrawElement, il faut que le type spécifié corresponde au type d’entrée du geometry shader. Les correspondances autorisées sont :

1. points : GL_POINTS
2. lines : GL_LINES, GL_LINE_LOOP ou GL_LINE_STRIP
3. triangles : GL_TRIANGLES, GL_TRIANGLE_FAN ou GL_TRIANGLE_STRIP
4. lines_adjacency : GL_LINES_ADJACENCY
5. triangles_adjacency : GL_TRIANGLES_ADJACENCY

Les nouveaux types ADJACENCY (GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY, GL_TRIANGLES_ADJACENCY et GL_TRIANGLE_STRIP_ADJACENCY) permettent d’accéder aux vertices des primitives voisines de la primitive en cours de traitement.

Un exemple simple
L’exemple choisit est tres tres classique. Il permet d’afficher le mailage d’un mesh, les vecteurs normaux des faces et de calculer les vecteurs normaux de chaque face (flat mode). Cet exemple me permet également d’introduire quelques classes simples, pour lire un fichier .obj (version simplifiee), calculer les vecteurs normaux, initialiser un contexte GL avec Qt.

Pour l’affichage des vecteurs normaux et des triangles, on a besoin des positions et des normales, que l’on passent donc aux shaders en attributs.

Pour afficher les vecteurs normaux dans le geometry shader, on prend un seul vertex en entree (input = points) et l’on retourne une ligne (output = lignes, size = 2), dont le premier point est la position du vertex et le second point est la position du vertex auquel on ajoute le vecteur normal (multiplie par une constante, passee comme uniform, pour modifier la longueur du vecteur)

Pour afficher les triangles, on recupere un triangle en entree (input = triangles) et l’on retourne 3 lignes (output = lignes, size = 6). Chaque points correspond a la position d’un vertex decale legerement par le vecteur normal (pour que les lignes soient bien visibles et ne soient pas cachees par les triangles).

Télécharger le projet d’exemple

A suivre…

1. Shrink, explosion, subdivision, silhouette, hedgehog
2. Explosion, cheveux
3. Instanciation et culling
4. Instanciation et culling