Archives du mot-clé c++

Développement Web en C++

4 réponses

En attendant MeetingCpp j’ai commencé cet article, car j’étais étonné qu’il n’y ait aucune session prévue au sujet du développement web en C++. Je le finalise ce soir en rentrant de cette magnifique conférence, afin de me donner le temps de faire de mes nombreuses notes de véritables articles sur les sujets abordés et discutés.

En effet on ne trouve pas des masses de tutoriaux, ni de solutions pour le développement web en C++, du fait de la prédominances des langages tels que Php, Spring, Django, Ruby on Rails etc. dans ce domaine.

J’aimerai présenter dans cet article une des solutions existantes en tant que framework de développement web, permettant de parvenir très rapidement à de bons résultats, comme on peut y être habitué avec CodeIgniter, Zend, Django ou Ruby on Rails, mais avec un gain de performance.

Pourquoi du développement web en C++ ?

Avant de rentrer dans des détails d’implémentation, il est possible de se poser la question pourquoi du dévéloppement web en C++ ? En effet avec la pléthore de langages et de frameworks existants destinés à ce problème, on pourrait penser que cela n’a pas d’autre intérêt que la préférence de ce langage.

En réalité, il y a trois raisons qui peuvent mener à choisir de développer une application web ou un site internet en C++ :

  • Hautes performances & haute disponibilité : Benchmark CppCms vs Java, C#, PHP
  • Réduction du nombre de serveurs, ayant pour conséquence la réduction des coûts et de l’impact sur l’environnement : HipHop for Php: Move Fast
  • Ajout d’une interface web (html ou web service) pour une base C++ existante

CppCms parmi d’autres solutions

J’ai eu le loisir de tester et de comparer différentes solutions (i.e. POCO HttpServer, CppCms, FastCgiQt, WebToolkit, QtWebApp, inetd…) et bien qu’il y ait différents avantages et inconvénients pour chaque solution, la librairie la plus flexible et la plus riche qu’il m’ait été donnée de trouver est CppCms.

CppCms est bel et bien un framework et non un système de gestion de contenu comme son nom souhaiterait l’indiquer, il est très semblable au framework Django en Python ou encore à CodeIgniter en PHP, n’ayant pas grand chose à envier à ces derniers en matières de fonctionnalités disponibles (i.e. Moteur de template statique/dynamique, systèmes de cache, json, jsonrpc, url mapping, génération/validation de forms HTML, modules multilingues/multiencodage, validation des entrées, fonctions cryptographiques/hash, gestion des sessions, gestion des vues, logging, accès aux bases de données avec cppdb, connexion avec apache/lighttpd/nginx via SCGI/FCGI ou HTTP…)

En addition le code et la documentation de CppCms est très claire, à tel point que Boost.Locale qui provient de CppCms a été accepté très rapidement.

Boost ou booster ?

CppCms peut laisser un peu sceptique au premier abord, car ce dernier contient une bibliothèque : booster, qui correspond à une petite partie de boost sur lequel le framework se base en addition à des extensions. Il est donc possible d’utiliser boost ou directement booster dans le code client ou de mélanger les deux sans que cela ne pose problème. Il y a des parties de booster qui font double emploi avec boost tel que booster::shared_ptr qu’il m’est impossible de justifier, mais d’autres qui sont très justifiées tel que booster::aio et qui se différencie de Boost.Asio par différents points abordés plus après.

CppCms : Télécharger & Installer

Je pars du principe que vous êtes dans un environnement unix, même si les étapes sont semblables sous windows.

  • Récupérez le code source : http://sourceforge.net/projects/cppcms/files/
  • Récupérez quelques dépendences :
    apt-get install libpcre3-dev zlib1g-dev libgcrypt11-dev libicu-dev python
  • Compilez :
    tar xf cppcms-1.0.2.tar.bz2
    cd cppcms-1.0.2/
    mkdir build
    cd build/
    cmake ..
    make -jX (Où X correspond à votre nombre de coeurs processeur + 1)
    sudo make install

Hello World

Nous allons pour ce premier article visant à présenter CppCms, implémenter l’infatigable “Hello World”.

Un design pattern que l’on retrouve de nos jours dans la quasi-totalité des frameworks webs est le MVC, utile dans le cas de sites webs, il permet de séparer les données ou la logique (i.e. le Modèle) de l’interface graphique (i.e.la Vue) à l’aide d’un glue code traitant les interactions utilisateurs (i.e. le Contrôleur).

Bien que pour ce premier “Hello World” nous n’allons pas utiliser cette organisation, CppCms ne fait pas exception et met à disposition le concept de contrôleur à l’aide de la classe mère cppcms::application, le modèle avec cppcms::base_content et les vues à l’aide du compilateur de fichier .tmpl : cppcms_tmpl_cc qui permet de mélanger C++ et le format de sortie : JSON, HTML…

Une cppcms::application synchrone simple

CppCms propose différents modèles de programmation, celui auquel un développeur web connaissant PHP, Django, Ruby on Rails ou Java est habitué est le modèle synchrone usant différents threads afin de traiter les requêtes reçues. C’est très simple à comprendre et scalable verticalement comme horizontalement via les systèmes de load balancing proposés avec FCGI ou SCGI (e.g. lighttpd mod_fcgi permet de définir plusieurs processus de gestion des requêtes, locaux ou distants).

Ici nous allons utiliser le serveur web intégré à CppCms en créant un petit projet organisé de la façon suivante:

hello_world/config.js :

hello_world/CMakeLists.txt :

Et dans le dossier src, le CMakeLists qui actuellement produit l’executable, hello_world/src/CMakeLists.txt

Et enfin le code de notre application, hello_world/src/SomeController.hpp :

  1. #ifndef SOMECONTROLLER_HPP
  2. #define SOMECONTROLLER_HPP
  3.  
  4. #include <cppcms/application.h>
  5. #include <cppcms/http_response.h>
  6. #include <cppcms/url_dispatcher.h>
  7.  
  8. class SomeController : public cppcms::application {
  9.     public:
  10.         SomeController(cppcms::service &srv) : cppcms::application(srv) {
  11.             dispatcher().assign("/hello",&SomeController::hello,this);
  12.             dispatcher().assign("/bye",&SomeController::bye,this);
  13.             dispatcher().assign(".*",&SomeController::redirect,this);
  14.         }
  15.  
  16.         void redirect() {
  17.             response().set_redirect_header("/hello");
  18.         }
  19.  
  20.         void hello() {
  21.             response().out() <<
  22.                 "<html>"
  23.                 "<body>"
  24.                 " <h1>Hello World</h1>"
  25.                 "</body>"
  26.                 "</html>\n";
  27.  
  28.         }
  29.  
  30.         void bye() {
  31.             response().out() <<
  32.                 "<html>"
  33.                 "<body>"
  34.                 " <h1>Bye</h1>"
  35.                 "</body>"
  36.                 "</html>\n";
  37.         }
  38. };
  39.  
  40. #endif

Afin de démarrer le service web et monter notre application à une url particulière il nous faut un point d’entrée, hello_world/src/main.cpp :

  1. #include <cppcms/applications_pool.h>
  2. #include <cppcms/service.h>
  3. #include <iostream>
  4.  
  5. #include <SomeController.hpp>
  6.  
  7. int main(int argc, char **argv) {
  8.  
  9.     try {
  10.         cppcms::service srv(argc,argv);
  11.         srv.applications_pool().mount(cppcms::applications_factory<SomeController>());
  12.         srv.run();
  13.     } catch(std::exception const &e) {
  14.         std::cerr << e.what() << std::endl;
  15.     }
  16.  
  17.     return 0;
  18. }

Configuration et mount()

Ici l’instance de cppcms::service que nous créons au sein de la fonction int main(int argc, char **argv) de l’application va justement définir sa configuration en fonction du fichier config.js que l’on passe à l’application. Ce fichier respecte un format JSON avec la possibilité en plus de commenter des lignes à l’aide de //.

Il est possible de configurer à l’aide de la clé “service” la façon dont CppCms doit servir des requêtes. Pour cet exemple nous resterons sur la configuration présente, mais pour une mise en production un petit changement vers fcgi ou scgi sera nécessaire (c.f. Configurer CppCms avec des serveurs webs).

Avec cette configuration, CppCms instancie un serveur http utilisant le nombre de threads donnés par worker_threads pour traiter les requêtes, il utilise ainsi la fabrique : cppcms::applications_factory() pour créer SomeController une fois par worker thread qui traite ce type de requêtes. La méthode mount() permet de définir sous quel chemin racine la cppcms::application sera servie, sans second paramètre, mount() utilise SomeController pour répondre à n’importe quelle requête entrante.

L’appel un peu plus loin à srv.run() lance le serveur HTTP ou FCGI/SCGI selon la configuration et démarre une event loop qui distribue les différentes requêtes au threads sur la base du reactor pattern (i.e. Il est possible de configurer quel backend utiliser via la clé “reactor”, avec l’une des valeurs suivantes : “default”, “select”, “poll”, “epoll”, “devpoll”, “kqueue”, cependant cela n’a rien de nécessaire sur les plateformes communes parce que default choisi toujours la meilleure option pour la plateforme en cours. Vous noterez que l’option iocp est manquante, cela résulte dans l’utilisation de select() sur windows).

Plutôt que des threads il est possible d’utiliser des processus pre-forkés en spécifiant la clé : worker_processes. Cela a deux principaux avantages : un crash d’une des instance de SomeController n’affecte que l’unique requête servie par ce dernier et sous la plupart des systèmes d’exploitations, au dessus un certain nombre de thread la gestion de ces derniers devient si complexe que leur coût en performance devient exponentiel (c.f. Scalable Network Programming, Or: The Quest For A Good Web Server (That Survives Slashdot)).

Cependant en restant sous un nombre réaliste de threads, la rapidité sera meilleure qu’avec fork, tout dépends de combien de clients simultanés doivent pouvoir être supportés et de la longueur du traitement de chaque requête, dans cet exemple nous n’utilisons que 10 threads.

Pour exécuter cet exemple sur votre pc, il vous suffit de taper les commandes suivantes :

Assignement d’url

Comme il est possible de le voir dans le fichier SomeController.hpp lors de l’instanciation de ce dernier il est possible de définir quelle méthode doit être appellée à quelle instance à l’aide du header : cppcms/url_dispatcher.h.

Ce dernier ne se limite pas à cette utilisation simpliste, en effet le premier paramètre est une expression régulière, il est ainsi possible de mapper des éléments capturés de l’url en tant que paramètre de la méthode à appeller, de telle sorte que l’on pourrait écrire pour une méthode avec la signature SomeController::getArticle(string categoryName, string articleId):
dispatcher().assign("/getArticle/(s+)/(d+)", &SomeController::getArticle,1,2);

Ainsi la méthode chargée de traiter la requête n’est appellé que si le format de l’url correspond. Cela n’empêche pas pour autant d’accèder directement à l’url complète ou aux paramètres GET, POST etc. à l’aide de la méthode request() retournant un objet de type cppcms::http::request représentant la requête.

Ecriture de la réponse

Comme il est possible de le voir dans les méthodes redirect(), hello() & bye on manipule la réponse http à l’aide de la méthode response() qui retourne un object de type cppcms::http::response et qui possède une API très riche pour manipuler les réponses, avec des méthodes confortables. Vous trouverez également une méthode io_mode() qui peut être définie sur normal, nogzip, raw, asynchronous ou asynchronous_raw.

De nombreuses autres fonctionallités à découvrir

Comme vous avez pu le constater il y a différents modes d’entrées/sorties possibles dans cppcms. Un mode très intéressant, mais peut-être le moins commun pour les personnes ne connaissant pas boost::asio est le mode asynchrone.

Chaque thread qui fait de l’entrée/sortie a la problèmatique de devoir attendre sur l’achèvement d’une entrée ou d’une sortie pour pouvoir continuer les traitements. On peut résoudre ce problème d’entrées/sorties bloquants les thread la majorité du temps, en délégant le transfert des données aux drivers et au matériel. Laissant ces derniers effectuer les entrées/sorties lorsque c’est actuellement le moment ou possible, et répondre ainsi à d’autres entrées/sorties avec le même thread. Cela décuple de façon très importante le nombre de requêtes pouvant être traitées avec le même nombre de threads, cela implique cependant plus de complexité et nécessite de gérer soit-même le nombre de connexions par thread, afin de rendre l’application scalable.

Pour ceux connaissant boost::asio il y a cependant certaines différences dans la façon avec laquelle CppCms implémente les mêmes principes avec sa librairie booster::aio. En effet io_service::run() ne peut être appellée par plusieurs threads à la fois et laisse tourner sa boucle d’évènement jusqu’à ce que stop() soit appellée et non pas lorsqu’il n’y a plus de tâches postées.

booster::aio à l’instar de boost::asio n’utilise pas iocp sur Windows, parce qu’il utilise toujours le Reactor pattern. Un autre point est qu’il y a moins de fonctionnalités que dans boost::asio et est orienté objet plutôt que concepts.

Je posterai sous peu un article expliquant cela plus en détails et présenterai dans quels cas avec CppCms les applications webs asynchrones sont intéressantes, cela ne ferait aucun sens pour notre hello_world, mais plutôt dans le cas d’implémentation de server-push ou de long-polling à l’aide de la classe : cppcms::http::context permettant de conserver une requête en cours sur le serveur et de la servir partiellement sans bloquer un thread par utilisateur, à l’aide de fonctions telles qu’async_flush_output(handler).

Conclusion

Développer des applications webs en C++ n’est plus un problème et a différents avantages, je n’ai présenté ici que la base la plus simple de ce framework, mais il y a de nombreuses fonctionnalités qui méritent d’être connues comme le support de Json::Rpc, le compilateur de vues/templates, les mécanismes de cache intégrés, les classes de sérialisation/désérialisation, la gestion des sessions, des formulaires et de l’internationalisation.

Si vous souhaitez en savoir plus n’hésitez pas à visiter les exemples et la documentation officielle : CppCMS 1.x.x — Stable. Je serai également ravi de vous répondre ou de vous aider.

Logo officiel de Boost

Boost::Python, dates et conversions

4 réponses

Ceux qui ont déjà joué avec Boost::Python le savent : cette API est très complète mais malheureusement trop peu documentée. Si elle permet de rendre accessible du code C++ depuis un environnement Python avec parfois une déconcertante simplicité, certaines tâches triviales sont en revanche plus difficiles à réaliser qu’on aurait pu l’imaginer.

Si vous êtes sur cette page, c’est très probablement parce que vous aussi devez jouer avec des dates et des durées, de C++ vers Python, inversement ou bien les deux et que vous vous êtes vous aussi heurté à la complexité de Boost::Python.

L’article qui suit est le résultat de mes recherches en la matière, et la synthèse de la solution à laquelle je suis parvenu.

Le code de base

Pour l’ensemble de l’article, nous partirons du principe que vous utilisez la classe boost::posix_time::ptime côté C++, et datetime.datetime côté Python.

Remarque : Si jamais vous utilisiez une autre classe pour vos dates (quelle soit “maison” ou issue d’une autre bibliothèque), vous devriez pouvoir adapter le principe sans trop de problèmes.

Le code minimal pour un module Python avec Boost::Python dont nous partirons est le suivant :

Rien de fou donc, pour l’instant.

Ajoutons une fonction qui prend en paramètre et retourne un boost::posix_time::ptime :

Cette fonction ajoute bêtement 5 secondes à toute date qui lui est passée, sauf si celle-ci n’est pas une date valide.

Si le code actuel compile et donne une bibliothèque Python valide, l’appel de add_five_seconds() depuis l’interpréteur Python provoque la levée d’une exception :

En effet : à aucun moment nous n’avons indiqué à Boost::Python comment convertir une date Python en date C++, ni même que cette conversion était possible.

Pour que ceci fonctionne, il faut ajouter deux “converters” : un de C++ vers Python, et l’autre de Python vers C++.

Conversion de C++ vers Python

Si Boost::Python ne prend pas nativement en charge la conversion de date, il fournit néanmoins des outils puissants pour nous permettre d’y arriver.

Ajoutons le code de conversion à notre exemple précédent :

Analyse

Regardons ligne par ligne les changements apportés.

Le premier include est nécessaire pour utiliser boost::python::to_python_converter; le second pour rendre disponibles les types Python natifs, tels que PyObject ou PyDateTime.

Ici nous déclarons un “converter”. Au sens de Boost::Python, un “converter” est une simple structure ou classe qui contient une méthode statique nommée convert() qui prend un paramètre le type natif C++ à convertir, et qui retourne un PyObject*.

Dans le cas où notre date n’est pas une date valide, nous choisissons ici de renvoyer None. Libre à vous de modifier ce comportement pour satisfaire vos propres besoins.

Remarque : La valeur retournée doit avoir un compteur de référence strictement positif.

Enfin nous déclarons notre “converter” en spécifiant le type natif et la structure/classe à utiliser pour la conversion.

À partir de ce moment là, notre module Python sera capable de convertir implicitement tout boost::posix_time::ptime en datetime.datetime Python.

Conversion de Python vers C++

La conversion dans l’autre sens demande un peu plus de travail :

Analyse

Regardons encore une fois, ligne par ligne les modifications apportées :

Nous ajoutons une structure qui va contenir les routines de conversions. Contrairement à tout à l’heure, et comme nous le verrons plus tard, ceci n’est pas indispensable. Pour effectuer des conversions de Python vers C++, Boost::Python a juste besoin de deux fonctions. Que celles-ci soient statiques au sein d’une classe ou libres n’a aucune incidence.

La fonction is_convertible() sera utilisée par Boost::Python pour déterminer si l’instance Python à convertir peut l’être.

Dans notre cas nous acceptons tout d’abord None comme valeur “valide” pour respecter la symétrie, puis nous testons si l’instance est de type datetime.datetime grâce à la fonction PyDateTime_Check().

En cas de succès, nous renvoyons la valeur passée en paramètre telle quelle. En cas d’erreur, nous renvoyons NULL.

C’est ici que se passe le gros du travail : lorsque cette fonction est appelée, cela signifie que l’instance obj_ptr a passé l’appel à is_convertible() et est prête à être convertie.

Le paramètre data lui contient entre autres l’adresse de la zone mémoire où nous devons instancier notre résultat de conversion. Notez que pour ce faire, nous utilisons le “placement new” qui permet de construire une instance à un emplacement mémoire donné. Le delete correspondant sera automatiquement appelé par Boost::Python au besoin.

Pour finir, nous renseignons le champ convertible du paramètre data pour y indiquer où nous avons alloué notre résultat.

Comme auparavant, la dernière étape consiste à enregistrer le “converter” pour le faire connaître de Boost::python.
On remarque ici que comme énoncé précédemment, l’appel prend en paramètre deux fonctions qui n’ont pas nécessairement besoin de faire partie d’une classe ou d’une structure.

Résultat

Compilez le code ci-dessus (voir le script SConstruct en annexe), puis chargez votre module au sein de l’interpreteur Python :

Ça y est ! La conversion boost::posix_time::ptime <=> datetime.datetime fonctionne parfaitement. :)

Conclusion

Boost::Python est définitivement une bibliothèque très puissante. On peut certes regretter la qualité de sa documentation, mais fort heureusement les ressources à son sujet sur l’Internet ne manquent pas. Son extensibilité la rend utilisable dans toutes les situations et facilite grandement la vie du développeur.

J’espère que cet article vous aura aidé et/ou donné envie de découvrir/utiliser Boost::Python. Comme toujours, n’hésitez pas à me signaler toute coquille, erreur ou optimisation qui m’aurait échappé.

Annexe

Voici le script SConstruct que j’ai utilisé pour la compilation :

Sources

Ces pages m’ont été très utiles lors de la rédaction de cet article :

  • L’API datetime sur python.org (en Anglais);
  • l’API Boost::Posix Time sur boost.org (en Anglais);
  • l’API de Boost::Python sur boost.org (en Anglais);
  • cet article de misspent (en Anglais).
Hiérarchie de classe à héritage multiple

L’héritage en C++

8 réponses

Tous les langages modernes offrent aujourd’hui, par leur nature orientée objet, un moyen puissant de concevoir des hiérarchies : l’héritage. La plupart des programmeurs sont bien entendu déjà familiers avec le principe de dériver d’une classe pour en étendre les possibilités (ou les restreindre) dans une classe fille. Cependant, dans ce domaine, C++ va un peu plus loin que les autres langages en proposant différentes notions d’héritage public, privé, protégé et virtuel. Nous allons tenter, dans cet article, d’expliquer en détails leurs rôles et en quoi elles peuvent se rendre utiles.

Un cas classique

Ce code n’évoque probablement rien de nouveau pour la plupart d’entre vous : nous déclarons une classe Base, qui possède une méthode publique, une méthode protégée et une variable membre privée. Nous déclarons également une classe Derived, qui dérive de Base au travers d’un héritage public. Ce principe d’héritage public est généralement simple à comprendre et il est présent dans pratiquement tous les langages objets : lorsque Derived dérive de Base au travers d’un héritage public, on dit aussi que Derived “est un” Base. Toute instance de Derived peut être considérée comme une instance de Base. Comme nous l’avions vu, dans un article précédent, il est également possible de tester si une instance de Base est une instance de Derived grâce à un dynamic_cast<>. De façon résumée, un héritage publique offre les garanties suivantes :

  • Toutes les membres (variables et méthodes) publics dans la classe de base le sont aussi dans la classe dérivée.
  • Toutes les membres protégés dans la classe de base le sont aussi dans la classe dérivée.
  • Les membres privés de la classe de base ne sont pas accessibles à la classe dérivée.
  • On peut convertir implicitement un pointeur (respectivement une référence) sur la classe dérivée vers un pointeur (respectivement une référence) sur la classe de base.
  • On peut convertir explicitement un pointeur (respectivement une référence) sur la classe de base vers un pointeur (respectivement une référence) sur la classe dérivée.

Ainsi dans notre exemple, Derived peut, dans sa méthode foo() (et indépendamment de la visibilité de cette méthode), appeler la méthode protégée de son parent, set_x(). Elle ne peut pas en revanche, directement accéder à m_x qui est dans une section privée de la classe de base.

Le rôle de l’héritage public

Une concept erroné va généralement de pair avec l’utilisation de l’héritage public : il consiste à dire que ce type d’héritage est utilisé principalement pour favoriser la réutilisation de code. Ceci n’est pas (ou ne devrait pas) être la raison : en C++, il existe beaucoup de moyens de réutiliser son code, la façon la plus efficace étant la composition. Le fait de d’utiliser un héritage public doit être une décision fonctionnelle, et pas une décision technique : ainsi, la classe Table dérive de la classe Meuble parce qu’une table “est un” meuble, et pas parce qu’en faisant ainsi on évite de retaper du code. L’héritage (public ou non) s’il apporte quelque-chose, c’est principalement de la flexibilité.

Bonnes pratiques

Certains auront peut être pensé la chose suivante : “La méthode set_x() ne sert à rien. Autant déclarer m_x protégé directement : il y aura moins de code”. Si cette remarque part surement d’une bonne intention (après tout, avoir moins de code est en général une très bonne idée), elle risque ici d’avoir des conséquences fâcheuses : En procédant de la même façon que dans l’exemple, nous ajoutons certes une méthode, mais nous réduisons également le couplage. En optant pour la solution “simplifiée”, si pour une raison ou pour un autre, je suis amené à modifier l’implémentation de Base et à renommer par exemple m_x en m_first_x, je devrais alors modifier non seulement tout le code de Base mais aussi tout le code de Derived (puisque nous y faisons référence à m_x directement). Le fait d’ajouter une méthode protégée à Base permet de figer son interface “publique” et réduit donc drastiquement le couplage. Il en résulte un code bien plus maintenable. En règle générale, on retiendra que les variables au sein d’une classe seront toujours soit publiques, soit privées, mais très rarement protégées. Et si dans un cas particulier vous sentez avoir vraiment besoin d’un accès à un membre privé, préférez la directive friend qui augmentera bien moins le couplage.

Cette règle n’est évidemment pas absolue et vous risquez de rencontrer un scénario où déclarer une variable membre protégée est la bonne chose à faire. Cependant, ça ne devrait logiquement pas être votre premier réflexe.

L’héritage privé : une alternative à la composition

Qui n’a jamais écrit par erreur, au cours d’une soirée (nuit ?) un peu trop longue quelque-chose de ce genre :

Il en résulte en général de longues minutes très agaçantes où l’on tente de comprendre pourquoi le compilateur refuse systématiquement d’utiliser les variables de la classe parente. La raison est plutôt simple : en l’absence d’un attribut de visibilité, l’héritage par défaut en C++ est privé. Le code précédent est donc équivalent à :

Voilà une bonne occasion d’expliquer à quoi sert ce type d’héritage. L’héritage privé offre les garanties suivantes :

  • Tous les membres publics dans la classe de base sont privés dans la classe dérivée.
  • Tous les membres protégés dans la classe de base sont privés dans la classe dérivée.
  • Les membres privés de la classe de base ne sont pas accessibles à la classe dérivée.
  • La classe dérivée peut redéfinir les méthodes virtuelles de la classe de base.
  • Toutes les méthodes de la classe dérivée peuvent convertir un pointeur (respectivement une référence) sur Derived en pointeur (respectivement une référence) sur Base. Ceci n’est en revanche normalement pas possible en dehors de la classe dérivée. (Voir tout de même la remarque).

Là où un héritage public traduit une relation de type “est un”, un héritage privé lui traduit une relation de type “est implémenté en tant que”. En pratique, un héritage privé est comparable à une composition de type 1-vers-1. Prenons un exemple plus parlant :

Nous avons déclaré une classe Engine (moteur) et Car (voiture) qui en dérive de façon privée. Dans la déclaration de Car, nous indiquons, au sein d’une section publique et grâce au mot clé using, que nous utilisons la méthode start() de la classe parente. Celle-ci devient donc publique pour la classe fille et en dehors. Dans ce cas, on voit bien qu’un héritage public n’aurait aucun sens puisqu’une voiture “n’est pas” un moteur, elle “possède un moteur”. Certains se demandent peut être si une composition n’est pas plus indiquée dans ce cas et la réponse n’est pas évidente :

  • En règle générale, oui, préférez la composition à l’héritage…
  • … mais dans le cas que nous présentons ici, la composition est assez “forte” : une voiture ne peut toujours avoir qu’un seul moteur, et le fait de démarrer la voiture revient à démarrer le moteur.

Les cas où l’on peut légitimement accepter un héritage privé en lieu et place d’une composition restent très limités. Et personne ne vous blâmera si même dans ce cas, vous optez pour la composition. L’héritage privé est surtout une facilité du langage pour éviter au programmeur de saisir du code inutile : dans notre exemple, en utilisant une composition, on aurait obtenu quelque-chose de ce genre :

Pas vraiment plus difficile à comprendre, mais un peu plus long à taper. Et si ce n’était pas une mais vingt méthodes de Engine qu’il avait fallu “transporter” dans l’interface publique de Car, je vous laisse imaginer le temps perdu à saisir toutes les méthodes triviales qui ne font qu’appeler la “vraie” méthode du sous-objet. Dans tous les cas, notez qu’en t’en qu’utilisateur de la classe Car, vous ne devez jamais prendre en compte la présence d’un héritage privé dans sa définition : cet héritage est privé et relève de l’implémentation : l’auteur de la classe peut à tout moment décider de réécrire sa classe pour utiliser une composition classique, ou encore de redéfinir à la main chacune des méthodes, sans vous en notifier !

Remarque

Un lecteur assidu aura peut être remarqué une contradiction avec un de mes articles précédents : en effet, si j’ai indiqué un peu plus haut qu’il n’était pas possible de convertir un Car* en Engine* en dehors des méthodes de Car, ce n’était pas tout à fait vrai : cela est possible en C++, par l’intermédiaire d’une “conversion à la façon C”. Évidemment, si on respecte la clause énoncée précédemment de ne jamais se baser sur le détail d’implémentation que représente l’héritage privé, il ne s’agit en fait que d’un argument supplémentaire contre l’utilisation de ce type de conversion. En un mot : faites-le une fois pour vous amuser, puis plus jamais !

À propos du mot clé using

S’il est très courant de rencontrer le mot clé using lors de l’utilisation d’héritage privé, il est également possible de l’utiliser lors d’un héritage “classique” public :

Ici, nous avons augmenté la visibilité de la méthode set_x() en la rendant publique dans la classe dérivée, alors qu’elle n’était que protégée dans la classe de base. Bien que peu courante, cette syntaxe n’en demeure pas moins tout à fait correcte.

L’héritage protégé

L’héritage protégé ressemble énormément à l’héritage privé. En fait, sa seule différence est la suivante :

  • Tout membre public ou protégé hérité au travers d’un héritage protégé est également accessible de façon protégée aux classes filles de la classe dérivée.

Ce qui se traduit par :

Ici Robot peut accéder à la méthode protégée de Engine parce que Car hérite de Engine au travers d’un héritage protégé. On voit que si l’héritage privé peut s’avérer utile dans certains cas, l’héritage protégé lui a un intérêt beaucoup plus limité, car le fait de pouvoir accéder aux méthodes de sa classe grand-parente ne fait qu’augmenter le couplage.

Je n’ai encore jamais rencontré ou eu besoin d’un héritage protégé depuis que je développe en C++.

L’héritage virtuel

Pour expliquer en quoi consiste l’héritage virtuel, replaçons avant tout dans le contexte quelques lieux communs :

L’héritage multiple

C++ est l’un des rares langages à autoriser l’héritage multiple là où les autres langages préfèrent imposer la notion d’interfaces. La légitimité de l’une ou de l’autre de ces techniques est un sujet à part entière et sort du cadre de cet article. Si vous vous intéressez à ce débat, il existe sur l’Internet bien des discussions à ce sujet.

La minute “rebelle”

Vous avez certainement déjà entendu quelqu’un dire une chose du genre : “L’héritage multiple c’est toujours une hérésie, ça n’aurait jamais du exister ! Je n’ai jamais réussi à en faire quoi que ce soit d’utile.”

Face à ce genre de remarque simpliste, j’ai tendence à avoir la même réaction que Marshall Cline : les gens qui vous disent ça ne connaissent à priori pas votre problème ou vos besoins, et pourtant ils prétendent y répondre : comment le pourraient-ils ? Comment peuvent-ils savoir que dans votre situation, l’héritage multiple n’est pas la meilleure solution ? Si vous rencontrez ce genre de personnes, soyez prudents : le manque d’ouverture d’esprit et de réflexion fait en général de bien piètres programmeurs. Une phrase que j’aime bien citer dans cette situation est celle-ci : “Toutes les phrases qui dénoncent un principe de façon absolue et générale sont absolument et généralement fausses”. Si l’héritage multiple semble être la solution à votre problème, n’hésitez pas à l’utiliser.

Dans tous les cas, réfléchissez toujours bien à ce que vous faites : si l’héritage multiple est tant victime d’à priori négatifs, c’est qu’il est parfois difficile de comprendre son utilisation.

La démonstration par l’exemple

Pour illustrer les notions d’héritage multiple et virtuel, créons tout d’abord une hiérarchie de classes :

Hiérarchie de classe à héritage multiple

Comme nous le voyons ici, nous partons d’une classe Shape (“forme” en anglais), de laquelle dérivent deux classes Rectangle et Diamond (“losange” en anglais). Une quatrième classe, Square (“carré” en anglais) hérite à la fois de Rectangle et de Diamond.

Une implémentation naïve de cette hiérarchie en C++ pourrait ressembler à :

Cela a du sens : un carré (si on s’en réfère aux lois de la géométrie) est à la fois un rectangle et un losange, et il est aussi une forme.

Cependant, ce code n’a en pratique pas la structure souhaitée :

En effet, en utilisant un héritage classique (non virtuel) Square hérite en pratique deux fois de Shape : une fois par la branche de gauche (Rectangle), et une fois par la branche de droite (Diamond). Il en résulte que chaque instance de Square possède deux instances de m_identifier. Lorsqu’on souhaite utiliser identifier() ou m_identifier dans ou en dehors de la classe Square, il faut préciser par quelle branche on passe :

  • Soit en préfixant m_identifier par Diamond ou Rectangle (“Rectangle::m_identifier“);
  • soit en effectuant auparavant une conversion de this vers Rectangle* ou Diamond* (“static_cast(this)->m_identifier“)

Ce n’est généralement pas ce qui est souhaité.

Pour résoudre ce problème, nous avons besoin de l’héritage virtuel :

En spécifiant que Rectangle et Diamond héritent tous deux virtuellement de Shape, nous empêchons la multiple instanciation du type de base : il n’y a alors plus qu’une seule instance de m_identifier et on peut y référer directement sans avoir recours à des conversions.

Bonnes pratiques

L’utilisation de l’héritage virtuel peut se faire conjointement avec tout autre type d’héritage (privé, protégé et public), mais est habituellement rencontré principalement avec l’héritage public.

Indépendamment de l’utilisation de l’héritage virtuel, on constate assez logiquement que les classes les plus en haut de la hiérarchie devraient dans l’idéal être virtuelles pures. Si c’est le cas, cela ne signifie pas forcément qu’il faille supprimer l’héritage virtuel : outre le fait de ne pas dupliquer inutilement les instances des membres, l’héritage virtuel permet également de s’assurer que la classe de base n’a qu’une seule adresse dans les instances filles. Il est en pratique très probable que vous deviez user d’héritage virtuel lorsque vous utilisez l’héritage multiple.

Conclusion

Nous avons vu au travers des différentes sections que C++ est très complet en matière d’héritage. Élément incontournable de la programmation orientée objet moderne, c’est un principe qu’il convient de manier avec la plus grande précaution et une bonne réflexion : si l’héritage peut résoudre bien des problèmes, il n’est de loin pas la solution universelle. Que vous optiez pour l’héritage, la composition ou autre chose pour la résolution de vos problèmes, réfléchissez toujours et envisagez chacune des possibilités.

Comme toujours, n’hésitez pas à me faire part de vos remarques, questions ou corrections dans les commentaires.

Sources

Voici une série de liens en anglais qui m’ont inspiré pour la rédaction de cet article. N’hésitez pas à les consulter, ils sont extrêmement intéressants :

casts

Les casts en C++

11 réponses

Nombreux sont les programmeurs C++ qui ont d’abord été confrontés au C. Les deux langages partagent en effet bien des fonctionnalités… mais ont également de grandes différences.

Parmi ces différences, on trouve les opérateurs de conversion C++. Ils sont certainement l’un des points les plus mal compris par les développeurs C qui voient souvent en eux un verbiage inutile. L’objectif de cet article est de (dé)montrer l’utilité des opérateurs de conversion C++, en comparaison avec les conversions classiques, dites : “à la C” et de comprendre ce qu’ils peuvent apporter au programmeur en termes de maintenabilité et de sécurité.

Un petit mot sur les conversions

Les conversions (ou “cast” en anglais) sont un des outils incontournables du programmeur C++. Mais comme tout outil, il faut savoir les utiliser à bon escient.

Dans l’idéal, un programme doit contenir le moins possible de “casts” : les types doivent s’interfacer naturellement les uns avec les autres. Cela garantit un découplage du code et donc une meilleure maintenabilité. Cela ne signifie pas qu’il faille à tout prix éviter les “casts” mais simplement qu’il faut les utiliser avec parcimonie.

Dans les sections qui suivent, nous allons expliquer le rôle de chaque opérateur de conversion. Pour l’ensemble des sections, nous considérerons les classes suivantes lorsqu’il sera question de hiérarchie :

static_cast<>

Il permet plusieurs choses :

  • Expliciter les conversions implicites, supprimant du même fait tout avertissement que donnerait le compilateur si la conversion peut entraîner un risque. Exemple : double vers int.
  • Convertir vers et depuis n’importe quel type pointé à partir d’un void*. Exemple : void* vers unsigned char*.
  • Convertir au travers d’une hiérarchie de classe, sans effectuer de vérification préalable. Exemple : Base* vers Derived* ou Base& vers Derived&.
  • Ajouter l’attribut constant au type converti. Exemple : char* vers const char*.

Dans le dernier cas, notez que puisqu’il n’y a aucune vérification et que static_cast<> n’échoue jamais, le code suivant a un comportement indéfini (communément nommé en anglais “undefined behavior” ou “UB“) :

Notez que la notion de comportement indéfini n’offre par définition aucune garantie : le code peut avoir le comportement espéré, faire crasher le programme ou provoquer l’envoi d’un missile nucléaire sur Cuba.

Il ne permet pas de :

  • Convertir vers ou depuis un type pointé à partir d’un autre type pointé autre que void*. Exemple : unsigned char* vers char*.
  • Tester qu’une instance est celle d’un type dérivé. Exemple : tester qu’un Base* est en fait un Derived*.
  • Supprimer l’attribut constant du type converti. Exemple : const char* vers char*.

En bref

static_cast<> est sans doute l’opérateur de conversion que vous serez amené à utiliser le plus. Il ne permet que de réaliser des conversions sûres et à pour rôle principal celui d’expliciter les conversions implicites.

Dans le cas du polymorphisme, il est à préférer à dynamic_cast<> lorsque l’on a la garantie que la conversion va réussir.

dynamic_cast<>

Le seul rôle de dynamic_cast<> est de tester à l’exécution si un pointeur d’un type de base est en fait un pointeur vers un type dérivé.

Exemple :

Note : pour que dynamic_cast<> fonctionne, le type de base doit posséder au moins une méthode virtuelle.

Un appel à dynamic_cast<> est plus coûteux qu’un appel à static_cast<>car dynamic_cast<> effectue une recherche dans la “v-table” de l’instance à l’exécution pour déterminer son type exact.

On veillera donc à n’utiliser dynamic_cast<> que lorsqu’il n’y a aucune autre solution.

En bref

dynamic_cast<> est le seul opérateur de conversion à avoir un effet “indéterminé” jusqu’à l’exécution. Son utilisation n’a de sens que lorsque confronté à du polymorphisme. Dans les cas où la conversion est assurée de réussir, on lui préfèrera static_cast<> plus rapide et ne nécessitant pas que les classes possèdent une méthode virtuelle.

const_cast<>

const_cast<> permet de supprimer l’attribut constant ou volatile d’une référence ou d’un type pointé. Exemple : const char* vers char* ou volatile int vers int.

C’est notamment le seul opérateur de conversion à pouvoir le faire : même reinterpret_cast<> n’a pas ce pouvoir.

L’importance d’écrire un code “const-correct”

Directement relié aux opérateurs de conversion, l’écriture d’un code const-correct est un autre aspect du C++ souvent mal perçu par les programmeurs C. Le C est plus ancien et le mot clé const n’y a pas toujours existé; il a été emprunté au C++ par la suite.

Le fait d’indiquer qu’une variable est constante est un outil puissant permettant au compilateur de nous signaler certaines de nos erreurs qui auraient autrement passé la barrière de la compilation.

Qui ne s’est jamais trompé dans l’ordre des arguments d’un memcpy() ?

Les mots clé “const” ou “volatile” appliqués aux classes

En C++, les mots clé const et volatile s’appliquent évidemment aussi aux instances de classes mais ont des sémantiques différentes :

Le caractère const ou volatile s’applique récursivement aux membres de l’instance.

Il n’est possible d’appeler une méthode d’une classe que dans les cas suivants :

  • l’instance n’est pas const.
  • l’instance est const et la méthode est déclarée const.
  • l’instance est déclarée volatile et la méthode est déclarée volatile.
  • l’instance est déclarée const et volatile et la méthode est elle aussi déclarée const et volatile.

À propos de “volatile”

Certains lecteurs peuvent être perdus à la lecture du mot clé volatile qui, il faut bien l’avouer, n’est pas utilisé très souvent. Décrire précisément le rôle de volatile mériterait un article bien à part mais je vais tout de même dire en deux mots à quoi il sert :

Lorsqu’une variable est déclarée volatile, le compilateur n’a pas le droit d’optimiser sa valeur (mise en cache processeur) lors de tests.

Ainsi sans volatile sur la variable do_loop, le code suivant :

Risquerait d’être optimisé en tant que :

Ce qui est correct dans la plupart des cas… sauf si do_loop peut être modifié par un autre thread. C’est principalement dans ce genre de cas que volatile trouve son utilité.

Erreurs courantes

Une erreur courante concernant const_cast<> consiste à supposer que l’on peut toujours supprimer le caractère constant d’une variable.

Ceci est évidemment faux : on ne peut supprimer le caractère constant (respectivement volatile) d’une variable que lorsque celle-ci a été déclarée non-const (respectivement non-volatile).

Ainsi le code suivant a un comportement indéfini :

Un autre cas courant est celui des variables membres qui servent à mettre en cache un résultat :

L’utilisation de const_cast<> ici est erronée : si on déclare une instance const de MyClass, m_value_cache est aussi const lors de sa définition. L’utilisation de const_cast<> est la même que dans l’exemple précédent et a comportement indéfini.

La bonne solution est d’utiliser le mot clé mutable, qui permet à une variable membre de ne pas avoir les mêmes contraintes const/volatile que son instance parente :

En bref

const_cast<> est le seul opérateur de conversion à pouvoir supprimer le caractère const ou volatile d’une variable. L’utilisation de const_cast<> doit rester très rare : le contraire indique souvent une importante erreur de design. Son seul usage habituellement toléré est l’interfaçage avec des bibliothèques historiques qui ne sont pas const-correct.

reinterpret_cast<>

Il s’agit de l’opérateur de conversion le plus dangereux, et du plus mal utilisé. Son rôle est de dire au compilateur : “réinterprète-moi la représentation binaire de ce type en tant qu’un autre type”.

Il permet :

  • De convertir n’importe quel type pointé en une autre, même lorsque ceux-ci n’ont aucun rapport. Exemple : int* vers double*.
  • De convertir un type pointé en sa représentation intégrale et vice et versa. Exemple : int* vers int.

Il est à noter que ces conversions sont dépendantes de l’implémentation. En d’autres termes, le compilateur est libre de faire ce qu’il veut concernant la conversion basée sur reinterpret_cast<> mais ce comportement doit être constant : il ne s’agit pas de comportement indéfini; le comportement est bien défini, simplement pas par le standard C++ mais votre version du compilateur. Si vous vous basez sur cette dépendance de l’implémentation, votre code est donc non-portable.

La seule garantie délivrée par le standard C++ concernant reinterpret_cast<> est que si vous convertissez un type A en un type B, puis de nouveau en un type A, le comportement est bien défini et vous récupérez bien la valeur de départ.

On comprend dès lors facilement le danger que peut représenter reinterpret_cast<>.

Voici un exemple d’utilisation :

Cas particuliers

Le peu de garanties associées à reinterpret_cast<> rendent celui-ci quasiment inutile dans la plupart des cas. Il y a cependant certaines exceptions de fait qui justifient une utilisation de reinterpret_cast<> sans nuire à la portabilité :

Les conversions entre les types char* et unsigned char* bien que non spécifiées par le standard, sont en pratique supportées par tous les compilateurs et produisent le comportement attendu. Le compilateurs ont par ailleurs de plus fortes contraintes à leur égard (spécifiquement au niveau de leur représentation) pour des raisons de compatibilité ascendante avec le C.

Vous pouvez donc clairement supposer qu’un reinterpret_cast<> entre un char* et un unsigned char* sera à la fois portable et défini.

Polymorphisme

reinterpret_cast<> utilisé dans le cadre d’une conversion faisant intervenir du polymorphisme a un comportement non défini. Il n’est ainsi pas correct d’effectuer un reinterpret_cast<> entre par exemple un Base* et un Derived*.

En bref

reinterpret_cast<> est l’opérateur de conversion le plus dangereux : permettant de faire ce qu’aucun autre ne peut faire (des conversions entres des types non liés) il convient de l’utiliser avec la plus grande prudence. En pratique, on lui préfèrera static_cast<> qui permet d’effectuer des conversions plus sûres, y compris vers et depuis des types pointés génériques (void*). Son seul usage toléré est l’interfaçage avec du code C ancien qui utilise pour ses paramètres de “buffer” des char* ou unsigned char* au lieu des void*.

Old-school : les conversions “à la C”

Le C++ supporte toujours l’ancienne syntaxe concernant les conversions “à la façon C”. Cependant, le standard précise clairement l’effet d’une telle conversion :

Le “cast” suivant : (Type)valeur ou Type(valeur)

Sera équivalent à, par ordre de préférence :

  1. un const_cast<>
  2. un static_cast<>
  3. un static_cast<> suivi d’un const_cast<>
  4. un reinterpret_cast<>
  5. un reinterpret_cast<> suivi d’un const_cast<>

Les bonnes pratiques indiquent souvent que l’utilisation de ce type de conversion est à bannir, principalement parce qu’il peut résulter silencieusement en un reinterpret_cast<>, qui comme nous l’avons vu, peut se révéler extrêmement dangereux. De plus, l’usage des alternatives modernes aux opérateurs de conversion permet de spécifier clairement l’intention du programmeur et de protéger contre les erreurs involontaires (comme celles que nous avons vu avec const_cast<>).

Une autre utilité

Les “casts” à la C offrent également une possibilité qui n’est permise par aucun autre opérateur de conversion : celle de convertir vers une classe de base au travers d’un héritage privé. Ce type d’héritage est très souvent critiqué et fortement déconseillé. Je ne détaillerai pas ici les conséquences et les raisons de ce type d’héritage; c’est un sujet qui mérite son propre article.

Conclusion

Il y a beaucoup à dire sur les opérateurs de conversion et encore plus à apprendre. Nous avons vu que bien utilisés, ils sont un outil puissant et un allié du programmeur. Protégeant contre les erreurs involontaires et révélant les erreurs de conception, ils restent pour certains dangereux et sont tout de même à utiliser avec la plus grande précaution.

Une bonne connaissance de ces opérateurs de conversion et de leurs limites reste indispensable à la réalisation de programmes maintenables en C++.

Références

Voici une série de liens (en anglais, pour la plupart) qui m’ont inspiré dans la rédaction de cet article.

N’hésitez pas à les consulter pour obtenir d’autres informations. Je vous recommande également de vous inscrire sur Stack Overflow qui est à mon sens le meilleur site de questions/réponses concernant la programmation : le niveau des questions et surtout des réponses y est vraiment très élevé.

Comme toujours bien sûr, vous pouvez également utiliser les commentaires pour obtenir des précisions sur un point ou l’autre.

Merci pour votre lecture !

yellow

Découverte de libsystools 2.1

4 réponses

Cette semaine, j’ai eu l’immense honneur d’effectuer la “release” de la version 2.1 de notre bibliothèque de base : libsystools. Cette version est le fruit de nombreuses heures de travail de l’équipe freelan et apporte un bon lot de nouveautés par rapport à la dernière version.

Cet article va tenter de vous faire découvrir ces nouveautés, d’expliquer certaines décisions de design et bien entendu de vous donner envie de l’essayer !

Présentation

Il y a 2 ans, le code de freelan commençait à être volumineux. Bon nombre de classes outils étaient écrites qui pouvaient intéresser d’autres projets. Nous avons donc décidé de rendre cet ensemble de classes autonome et c’est ainsi qu’est né libsystools.

libsystools propose une interface C++ moderne pour un certain nombre de bibliothèques C mais aussi des classes nouvelles (notamment SmartBuffer).

Ses principaux domaines d’application sont :

  • La gestion du xml (parsing, génération, modification, signature);
  • la gestion de la cryptographie (RSA, AES, SHA);
  • la gestion des certificats;
  • la gestion des ports série;
  • la gestion du SSL (TLS, DTLS);
  • la gestion du réseau (Socket, SocketAddress, SocketAddressResolver) en IPv4 et IPv6.
  • la gestion facilité de la mémoire (SmartBuffer);
  • une implémentation basique d’un client UPnP;
  • une implémentation basique d’un client HTTP;
  • une implémentation simple d’une classe de log;
  • la gestion de l’encodage (UTF-8, UTF-16, ISO-8859-1, etc.);
  • différentes méthodes pour calculer de checksum, compresser des flux, etc.

libsystools a été conçue dès le départ pour être extrêmement portable, qu’il s’agisse des systèmes d’exploitation ou des architectures. Elle est donc utilisable sur Windows (MinGW, Visual Studio 2010), Linux (gcc), Mac OSX (gcc), UNIX (gcc) aussi bien en 32 bits qu’en 64 bits.

L’ensemble de ses classes est documenté et différents exemples sont fournis qui traitent de chacun de ses domaines d’application.

libsystools se base sur différentes bibliothèques :

  • libxml2
  • libxmlsec1
  • openssl
  • libiconv
  • boost

Faciliter l’existant

Les bibliothèques sur lesquelles se base libsystools sont bien écrites et fiables. Cependant, elles ne fournissent qu’une interface en C.

Lorsqu’on utilise que peu ces bibliothèques dans un projet, il est acceptable de se servir simplement de ces interfaces C. Cependant, lorsqu’un projet en fait un usage intensif, le code devient très rapidement très dur à maintenir.

Qui n’a jamais eu à écrire un code de ce style ?

Bien sûr, un bon programmeur C++ simplifiera l’écriture de ce genre de code avec l’utilisation de classes conteneurs qui se chargent de libérer la ressource associée lors de leur destruction. Mais devoir refaire ce travail d’encapsulation à chaque utilisation est fastidieux, et ne règle qu’une partie du problème.

C’est dans cet esprit qu’on été développées les classes de libsystools : des wrappers simples, faciles à utiliser et efficaces.

En utilisant libsystools, le code précédent aurait plutôt ressemblé à :

Ce qui est bien plus lisible et maintenable, et présente l’avantage d’être “exception-safe”.

Utilisation & Exemples

Nous pourrions exposer les différents aspects conceptuels qui ont motivé chaque décision pendant des heures et sur plusieurs pages, mais après tout, en programmation, il n’y a pas plus explicite que le code. Voici donc quelques exemples d’utilisation commentés.

SmartBuffer, ou comment gérer la mémoire de façon intelligente

S’il ne fallait garder qu’une seule classe, ce serait celle-ci : SmartBuffer est au coeur de libsystools. Utilisée partout, SmartBuffer représente un tableau d’octets à taille variable et dont les différentes instances peuvent partager leur mémoire.

Dans bon nombre de cas, l’utilisation de SmartBuffer permet de simplifier le code existant en remplaçant les paramètres de type :

Par un simple :

La lecture et la maintenance s’en trouvent tous deux grandement facilités.

XML, les wrappers autour de libxml2

Avec l’engouement de tous les domaines pour le web, il est rare aujourd’hui d’avoir du code à produire qui ne nécessite pas de manipuler du XML. En C++, plusieurs solutions existent.

Nous avons opté pour la libxml2 pour plusieurs raisons :

  • C’est une bibliothèque mature, complète et quotidiennement maintenue;
  • elle est portable sur plusieurs architectures et plateformes;
  • elle s’interface très bien avec OpenSSL au sein de libxmlsec1 pour le support des signatures XML.

Le module XML de libsystools se décompose en trois parties :

  • Les éléments DOM, qui représentent de façon statique un arbre XML;
  • les “writers” qui permettent de générer du XML;
  • les objets XPath, qui permettent d’effectuer des requêtes dans les éléments DOM.

Voyons un exemple d’utilisation :

Reprenons cet exemple point par point :

  • Ligne 20 : nous déclarons un xml::Initializer qui existera pour toute la portée du main. Cet objet permet d’initialiser la libxml2 et de garantir sa libération au moment opportun, de façon automatique.
  • Ligne 28 : nous créons un XmlDocumentWriter. Cet objet permet une construction facilité d’un arbre XML en construisant l’un après l’autre ses différents éléments.
  • Lignes 30 à 38 : Nous créons chacun des noeuds XML. Les différentes fonctions prennent des systools::String en paramètre et supportent donc parfaitement la gestion des différents encodages.
  • Ligne 40 : Nous récupérons un arbre XML complet à partir du writer.
  • Ligne 46 : Nous récupérons l’instance XPath associé à l’arbre XML (cette instance est partagée par tous les noeuds d’un même arbre)
  • Ligne 48 : Nous associons un nom court au namespace nommé “namespace” dans l’instance XPath.
  • Ligne 53 : Nous effectuons une requête XPath sur la racine du document.
  • Ligne 57 : Nous effectuons une requête XPath sur un sous-noeud du document.

La manipulation du XML est grandement facilitée. On voit que seules quelques instructions suffisent à construire un arbre, à y naviguer et à en extraire les informations utiles.

Le module réseau

Une autre partie importante de libsystools est son module réseau. La manipulation des différentes fonctions et structures réseau d’un système a toujours été la bête noire des programmeurs novices. Entre les spécificités propres à chaque système d’exploitation, et les fonctions dépréciées suite au prochain passage à IPv6 (ça approche, si si, croyez-moi !), il n’est pas toujours évident de produire un code propre et robuste.

Le module réseau de libsystools a été conçu pour résoudre cette problématique. Il propose :

  • Une classe qui permet représenter une adresse de socket (IPv4, IPv6, etc.);
  • une classe pour effectuer des résolutions de nom ou d’adresse sur le réseau;
  • des classes Socket et SecureSocket qui encapsulent respectivement une socket classique et une socket SSL (en TLS ou DTLS);
  • une classe “Select” qui encapsule de façon objet les appels à la méthode “select()”;
  • une classe pour représenter les adresses Ethernet;
  • des outils de conversion entre adresse IP et représentation numérique.

Démontrons la simplicité de son utilisation en montrant le code d’un example qui va successivement :

  1. Chercher l’adresse de socket associée à 127.0.0.1:34000 en TCP.
  2. Créer une socket
  3. Connecter cette socket sur le serveur TCP situé à l’adresse recherchée en 1.
  4. Attendre la réception d’un message.
  5. Se déconnecter et libérer la socket et toutes les ressources associées.

Pas si mal pour un code d’une cinquantaine de lignes qui gère correctement toutes les erreurs potentielles et la libération des ressources, non ?

Pour conclure

Vous n’avez eu ici qu’un très bref aperçu des possibilités offertes par la libsystools. Pour découvrir plus avant la bibliothèque, je vous invite à consulter sa documentation en ligne.

En tout cas, j’espère sincèrement que cette présentation aura attisé votre curiosité et vous aura donné envie d’essayer la bibliothèque lors de vos prochains développements. Bien entendu, si vous avez des questions générales sur la bibliothèque et des interrogations concernant son évolution future, n’hésitez pas à commenter cet article ou directement contacter l’équipe sur la mailing-list (en anglais).

Bon code ! :)

Développer avec Qt pour Android

10 réponses

C’est possible ?

Dans ce petit article je vais vous parler du développement Android avec Qt et en C++, en effet, j’ai travaillé dernièrement dans une entreprise d’automatisation et de régulation des bâtiments où un des développeurs était en charge d’un projet d’application Android. La qualité de ses développements m’a donné envie de tenter l’aventure. Malgré la magnifique API de Java pour android je voulais pouvoir déployer pour Windows, Linux, Mac, Symbian et Android la même application. Mon choix se portait donc sur mon framework préféré : Qt et naturellement mon langage préféré. Je ne serai jamais assez redevant à Bjarne Stroustrup =D.

Développer des applications basées sur Qt pour android est possible via le projet android-lighthouse, qui fonctionne très bien ! En effet ce dernier rend possible l’exécution d’une application C++/Qt complète ou encore l’utilisation en Java des libraires écrites avec le framework.

Qt Quick UI - BogDan Vatra

Lighthouse

Quant à lighthouse c’est un projet que l’équipe du Framework Qt a lancé avant la version 4.7 pour rendre le framework Qt portable à n’importe quelle plateforme facilement. En effet cela requiert très peu de code spécifique à la plateforme afin de faire fonctionner toutes les librairies Qt.

Depuis quelques semaines lighthouse est passé dans la branche stable de Qt. Grâce à android-lighthouse on peut d’ailleurs voir que le portage des bibliothèques est très rapide. Seulement quelques mois ont été nécessaires pour obtenir une version pleinement (ou presque) fonctionnelle: même les interfaces basées sur le QML fonctionnent! C’est grâce à BogDan Vatra, initiateur du projet, que le port de Qt pour android en est arrivé à cette maturité qui démontre ainsi que Qt peut être porté n’importe où: Code less, do more, deploy everywhere!

Awesome!

Cela rend le portage d’applications Qt sur Android très simple, écrire une application avec le framework Qt signifie que l’on peut désormais la compiler sans effort pour : Symbian, Windows, Mac, Linux & Android ! :) C’est à mon sens parfait pour construire une base de librairies réutilisables dans une entreprise. Dans cette idée il est également possible de développer des bibliothèques basées sur les fonctionnalités de Qt et de les lier avec JNI afin d’apporter des fonctionnalités natives aux applications Java Android existantes.

Je vous présenterai dans cet article les différentes versions d’Android supportées, les quelques limitations et clarifications nécessaires, ainsi que les procédures à suivre afin de compiler pour et lancer sur Android votre application Qt.

Les versions d’Android compatibles

Lorsque le projet Qt android-lighthouse a été créé, seuls les périphériques Android 1.5 étaient supportés avec Qt lié en statique, ce qui n’est plus le cas aujourd’hui. En effet la branche actuelle du dépôt supporte seulement Qt lié dynamiquement (cela réduit l’utilisation de la mémoire – James Noble & Charles Weir 2001 – Small Memory Software, puisque chacune des applications partagent les mêmes bibliothèques Qt). Cette dernière supporte aujourd’hui les versions d’Android actuelles du marché: 1.6, 2.0, 2.1 et 2.2. N’hésitez pas à essayer avec l’émulateur Android car il fonctionne comme les véritables périphériques, plus d’un développeur Android m’en a confirmé ses qualités. :)

Quelques Limitations

Il y a actuellement (25/11/2010) quelques limitations, par exemple le rendu est réalisé uniquement par le software, les accélérations matérielles Open GL ne sont pas utilisées. Toutefois ce n’est certainement qu’une question de jours, car jusqu’aujourd’hui le portage de Qt sur Android a été très rapide et est toujours aussi actif.

Une autre limitation qui sera bientôt fixée d’après les initiateurs du projet est que l’on ne peut utiliser QtMultimedia pour jouer des sons, il y a d’autres solutions pour y parvenir, toutefois le port de QtMultimedia sera bientôt fait, et d’après l’initiateur du projet cela devrait être “le correctif le plus facile” qu’il lui reste à faire.

Quelques Clarifications

Vous n’avez pas besoin d’être “root” ou d’avoir accès au shell root sur votre périphérique pour déployer des applications Qt, cela signifie que vous pourriez envoyer l’application sur le Google Market. Toutefois actuellement il est plutôt déconseillé de le faire, il vaudrait mieux attendre que cela soit plus testé et utilisé (ce que fait actuellement une communauté grandissante: http://groups.google.com/group/android-qt/).

Préparez votre environnement de développement

J’ai écrit les instructions suivantes en m’inspirant de la page http://code.google.com/p/android-lighthouse/wiki/Compile et de ma propre expérience sur Linux 32 bits. Si vous êtes sur Windows vous devriez jeter un oeil au problème suivant: Configure does not work with Cygwin on winxp et appliquer le patch pour cygwin qui est proposé dans l’une des réponses. Enfin si vous êtes sur Mac OS X vous devriez simplement oublier pour le moment (ou bien trouver une solution :p): broken build on mac osx – x86.

Linux semble être la meilleure plateforme pour développer avec Qt pour android actuellement, donc si vous n’utilisez pas cette plateforme, je vous conseille d’essayer avec une Machine Virtuelle, du moins c’est la solution dont je peux vous en assurer le fonctionnement. :)

Actuellement quelques éléments dits sur la page officielle traitant de la compilation de Qt et d’applications Qt pour android ne sont pas vraies, c’est pourquoi je vais vous guider dans la bonne direction pour faire fonctionner votre application Qt sur android, tel que Francisco Dalla Rosa Soares m’a montré cette semaine sur la mailing list d’android-lighthouse. Sans lui je n’aurai jamais pu lancer quoi que ce soit, si ce n’est mon pc portable…

Téléchargement

Avant tout il vous faut télécharger et décompresser QADK, qui est un Kit de Développement natif non officiel pour android, basé sur l’officiel mais avec quelques bibliothèques non supportées en plus:

Après cela il vous faudra cloner le repository git de android-lighthouse qui lui même consiste en un clone du projet Qt lighthouse qui est officiellement fourni par Nokia:

Configurer & Compiler

Vous devrez compiler Qt pour la plateforme visée, il est nécessaire de définir la variable ANDROID_PLATFORM et de faire pointer NDK_ROOT vers le dossier où vous avez décompressé QADK.

La dernière ligne est présente pour cibler les plateformes android 2.0 & 2.1, ce qui fonctionna sans problèmes pour ma part. Utilisez android-4 afin de cibler les plateformes 1.6 et android-8 pour cibler les plateformes 2.2.

Vous pouvez désormais lancer la partie de configuration (n’hésitez pas à aller voir votre petite amie pendant ce temps):

Et enfin vous pouvez compiler le tout:

Changez 3 par le nombre de coeur de votre processeur + un, cela activera la compilation parallèle avec autant de processus.

Il y a une dépendance de Qt qui n’est pas incluse au projet, c’est libcloog-ppl-dev, lancez simplement:

Pour ce que j’ai pu comprendre c’est une librarie utilisée pour l’optimisation de code, qui est destinée à générer du code permettant de passer sur chacun des points d’un Polyèdre. Je suppose que c’est utilisé dans qmake, mais je ne pourrai vous l’assurer. Plus de détails et un exemple sur le site officiel.

Installez Qt sur le Périphérique

Maintenant ce serait sympa d’avoir Qt sur le périphérique Android (ou dans l’émulateur), pour ce faire faites simplement ce que la page de wiki de google code conseille:

Connectez votre Périphérique

Si vous recevez l’erreur adb: command not found, c’est parce que vous êtes nouveau au développement Android (tout comme moi). Vous devez simplement télécharger le dernier sdk d’Android, vous pouvez trouver les instructions détaillées ici et le sdk ici.

Cependant à cette étape de l’article vous avez simplement besoin de télécharger le SDK, de définir le PATH et d’éxécuter:

Ensuite si vous voulez essayer sur votre véritable téléphone vous devrez activer la connexion avec ce dernier, pour y parvenir je vous invite à suivre la petite partie décrite sur le site d’android.

Je suis sur Linux, donc j’ai simplement mis en place la configuration suivante pour mon téléphone LGGT540 sur android 2.1. Sur mon pc avec Ubuntu 10.10 j’ai défini les informations suivantes dans le fichier /etc/udev/rules.d/51-android.rules:
Les fichiers présents dans /etc/udev/rules.d/ sont destinés à définir des règles persistantes pour les périphériques, dont l’une est de changer le CHMOD d’accès à un périphérique, en fonction d’éléments permettant de l’identifier.

Où 1004 vient d’une liste fournie de Vendor Ids pour les périphériques android: http://developer.android.com/guide/developing/device.html#VendorIds/. Prenez celui qui convient. :)

Sur Windows il vous faudra simplement installer les pilotes adb, et sur Mac OS X cela fonctionne sans rien faire, toutefois rappelez vous que android-lighthouse pour Mac OS X ne semble pas fonctionner.

Pour lister les périphériques Android existants vous pouvez lancer: adb devices.

Votre première Application Qt pour Android

Nous n’allons pas écrire notre propre code (oui je sais c’est triste), parce qu’il y a beaucoup de Hello World-like dans les demos du Qt Sdk. Nous allons donc choisir un très simple, afin d’expliquer les choses qui nous intéressent: la configuration de la compilation et comment créer un projet java afin de lancer l’application.

En effet contrairement aux dires du site officiel il n’est pas possible actuellement de compiler directement l’application en temps qu’exécutable natif. Il est nécessaire de la compiler en une bibliothèque dynamique, que l’on chargera à l’aide d’un petit launcher java basé sur les classes fournies par android-lighthouse. Ces dernières sont présentes dans le package com.nokia.qt.QtActivity.

Maintenant allez dans le répertoire /android-lighthouse/demos/mainwindow/, ici vous pouvez ouvrir le fichier mainwindow.pro, qui devrait contenir les configurations suivantes:

Il est réellement important de compiler l’application en tant que bibliothèque dynamique, ainsi pour vos prochaines applications n’oubliez pas d’utiliser les deux premières lignes données ci-dessus. Personnellement j’ai une préférence pour CMake, mais je n’ai pas encore pu préparer de configuration pour android pour le moment, et pourtant cela devrait seulement consister à éditer la méthode qt4_wrap_cpp pour lui donner la version android-lightouse spécialisée de qmake.

En effet pour compiler l’application, il faut utilisez android-lighthouse/bin/qmake afin de générer les fichiers de moc et le Makefile, et non pas la version de qmake que vous avez dans votre PATH.

Voilà, vous ne devez même pas adapter le code de votre application Qt. Le résultat des commandes que vous avez lancées devrait être un fichier so (shared object) avec différents liens symboliques afin de rendre possible la compatibilité entre versions apportée par libtool.

Envoyez simplement celle sans informations de compatibilité de versions sur votre périphérique android: adb push libmainwindow.so /data/local/qt/lib. Une fois que vous avez fait cela, l’application est sur le téléphone, mais rien n’existe pour la lancer.

Créez le Projet Android

Nous allons ainsi créer un launcher en java, basé sur le launcher fourni par le projet android-lighthouse, qui s’occupe tout seul des bindings JNI nécessaires. :D

Tout d’abord créez un projet dans un sous-dossier (javaLoader par exemple)

Créez une classe QtMain.java (vim seul ou avec eclim est un bon outil pour cela):

Et ensuite tapez simplement:

Votre application est installée, et peut facilement être lancée sur votre périphérique à l’aide de:

À propos du débogage

Pour le moment je n’ai hélas pas réussi à déboguer l’application sur le périphérique, mais les sorties consoles sont redirigées, il est donc tout de même possible d’utiliser qDebug pour faire le débogage. Ce n’est pas optimal mais ce n’est qu’en attendant de trouver un moyen simple. Je pense néanmoins que l’outil qadk-r4/ndk-gdb peut rendre le débogage possible, je n’ai pas réussi cependant à faire quoi que ce soit pour l’instant à ce sujet. Je posterai dès que j’y parviendrai. ;)

Qt Creator

Apparemment l’intégration d’Android pour Qt Creator est très avancée mais pas encore dans le dépôtd’après un mail de Tero Savolainen arrivé au moment de poster l’article, sur la liste de diffusion nommé “Re: Qt porting status and some great news” l’intégration de Qt Creator avec Androïd est faite et le débogage est la prochaine fonctionnalité à venir.

Conclusion

Comme vous avez pu le voir il devient très simple de développer nativement pour Android, le projet étant très actif, il y a fort à parier que pour fin décembre les limitations citées devraient avoir disparues et que le débogage soit possible.

Merci beaucoup pour votre lecture, je suis ouvert à toutes vos suggestions et remarques concernant cet l’article. ;)