Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Developpez Le Mag Édition de juin - juillet 2012. Numéro 40. Magazine en ligne

Developpez Le Mag Édition de juin - juillet 2012. Numéro 40. Magazine en ligne gratuit. Diffusion de copies conformes à l’original autorisée. Réalisation : Alexandre Pottiez Rédaction : la rédaction de Developpez Contact : magazine@redaction-developpez.com Sommaire C++ Page 2 Qt Page 5 Mac Page 13 MS Office Page 14 JavaScript Page 21 (X)HTML/CSS Page 29 Java Page 39 Eclipse Page 46 Android Page 49 Business Intelligence Page 52 Liens Page 62 Article (X)HTML/CSS Ajoutez du style à vos listes ordonnées Ajouter des styles à des listes ordonnées a longtemps été une tâche difficile et piégeuse, je vais vous montrer comment utiliser CSS3 pour améliorer leur présentation en utilisant une approche sémantique. par Didier Mouronval Page 29 Article Eclipse Premiers pas avec Eclipse Scout Cet article propose une présentation détaillée du framework Eclipse Scout. par Jérémie Bresson Page 46 Éditorial Cet été, croquez à pleines dents dans de nouveaux articles bien juteux et savourez toute la fraîcheur des news et des billets blogs de la rédaction. Profitez-en bien ! La rédaction Nouveaux forums publics pour le comité de normalisation du C++ Jusqu'à maintenant, celui qui voulait faire des remarques ou propositions à propos du C++ sans pour autant être membre du comité de normalisation pouvait poster sur le forum Usenet (Lien 01) comp.std.c++ (et dans une moindre mesure comp.lang.c++.moderated : Lien 02). Bien que non officiel, ce forum était suivi par un grand nombre de membres du comité qui pouvaient ainsi relayer les avis de l'ensemble de la communauté. Le problème est qu'Usenet n'est plus trop utilisé, et ces forums sont moribonds. Afin de renforcer les liens avec la communauté des utilisateurs du C++, le comité de normalisation a donc décidé d'ouvrir des forums Web publics reprenant ce rôle. Deux forums sont créés : • discussions sur le langage tel qu'il est actuellement : Lien 03 ; • propositions d'évolution du langage : Lien 04 . L'objectif de ces forums est de discuter de problèmes potentiels dans la norme ou d'évolution du langage, pas de l'apprentissage du C++ ni des problèmes de son code (mais heureusement, pour ça, il y a les forums C++ de Developpez.com !) La première annonce officielle prévue pour ces forums est pendant la conférence C++Now (ex-Boostcon) : Lien 05. Que pensez-vous de cette initiative ? Commentez la news de Loïc Joly en ligne : Lien 06 Les "Guru of the week" en français Découvrez (ou redécouvrez) les célèbres problèmes C++ de Herb Sutter C'est une source d'information que les développeurs expérimentés connaissent bien. Guru of the Week (GotW) est un site créé et alimenté par Herb Sutter entre 1997 et 2003. Le principe est simple : une question technique est posée et les lecteurs interviennent pour répondre à la question en essayant de faire le tour de toutes les difficultés techniques qui pourraient apparaître. Une note sur 10 indique le niveau de difficulté de la question. Cette discussion aboutit à une analyse en profondeur de la problématique posée. Ces questions et réponses ont eu tellement de succès que Herb Sutter a publié plusieurs ouvrages pour regrouper et compléter ces analyses : Exceptional C++ (Lien 07), More Exceptional C++ (Lien 08) et Exceptional C++ Style (Lien 09). Pour les lecteurs francophones, seul le premier ouvrage est traduit en français. L'équipe de rédaction de la rubrique C++ de Developpez.com (Lien 10) vous propose de découvrir (ou redécouvrir) ces articles traduits en français. En fonction des autres publications de la rubrique, nous vous proposerons ainsi un ou deux GotW par semaine. Cette semaine, nous vous proposons le GotW numéro 31, sur les fonctions virtuelles impures : Lien 11 . Connaissiez-vous ces subtilités concernant les fonctions virtuelles pures ? Que pensez-vous de cette initiative de Developpez.com de vous proposer ces articles en français ? Retrouvez la liste de tous les Guru of the Week sur la page d'index : Lien 12. Commentez la news de Guillaume Belz en ligne : Lien 13 Guru Of the Week n° 31 : les fonctions virtuelles (im)pures 1. Problèmes 1.1. Question Junior Qu'est-ce qu'une fonction virtuelle pure ? Donnez un exemple. 1.2. Question Guru Pourquoi déclarer une fonction virtuelle pure et aussi écrire une définition (body) ? Donnez autant de raisons ou de situations que vous pouvez. 2. Solutions 2.1. Question Junior Qu'est-ce qu'une fonction virtuelle pure ? Donnez un exemple. uméro 40 – juin - juillet 2012 Developpez Magazine est une publication de developpez.com Page 2 Les dernières news C++ Les dernier tutoriels et articles C++ Guru Of the Week n° 31 : les fonctions virtuelles (im)pures Difficulté : 7 / 10 Est-ce toujours une bonne chose de faire une fonction virtuelle pure, tout en fournissant un body ? Une fonction virtuelle pure est une fonction virtuelle dont vous voulez forcer l'implémentation par les classes dérivées. Si une classe comporte encore des fonctions virtuelles non redéfinies, alors c'est une classe abstraite, et vous ne pourrez pas instancier ce type. class AbstractClass { public: // déclare une fonction virtuelle pure : // cette classe est désormais abstraite virtual void f(int) = 0; }; class StillAbstract : public AbstractClass { // impossible d'instancier f(int), // aussi cette classe est-elle toujours abstraite }; class Concrete : public StillAbstract { public: // instancie f(int), // aussi cette classe est concrète void f(int) { /*...*/ } }; AbstractClass a; // erreur, classe abstraite StillAbstract b; // erreur, classe abstraite Concrete c; // ok, classe concrète 2.2. Question Guru Pourquoi déclarer une fonction virtuelle pure et aussi écrire une définition (body) ? Donnez autant de raisons ou de situations que vous pouvez. Il y a trois principales raisons pour faire cela : la première est courante, la deuxième est assez rare et la troisième est une solution de rechange utilisée de temps en temps par des programmeurs expérimentés travaillant avec des compilateurs un peu faibles. La plupart des programmeurs ne devraient jamais utiliser que la première. 2.2.1. Destructeur virtuel pur Toutes les classes de base devraient avoir un destructeur virtuel (consultez votre manuel C++ favori pour y trouver les raisons).(Note de traduction : vous pouvez également consulter la FAQ « Pourquoi et quand faut-il créer un destructeur virtuel ? » : Lien 14) Si la classe doit être abstraite (vous voulez éviter son instanciation) mais qu'il s'avère qu'elle n'a aucune autre fonction virtuelle pure, voici une technique courante pour créer le destructeur virtuel pur : // file b.h class B { public: /*...d'autres choses...*/ virtual ~B() = 0; // destructeur virtuel pur }; Bien sûr, tout destructeur de classe dérivée doit appeler le destructeur de classe de base, ainsi le destructeur doit rester défini (même s'il est vide) : // file b.cpp B::~B() { /* peut être vide */ } Si cette définition ne devait pas être fournie, vous pourriez toujours dériver les classes de B, mais elles ne pourraient jamais être instanciées, ce qui n'est pas particulièrement utile. 2.2.2. Acceptation consciente forcée d'un comportement par défaut Si une classe dérivée choisit de ne pas redéfinir une fonction virtuelle non pure, elle se contente d'hériter du comportement de base par défaut de sa version. Si vous voulez fournir un comportement par défaut, mais que vous ne voulez pas laisser les classes dérivées simplement en hériter "silencieusement", vous pouvez la rendre virtuelle pure tout en lui fournissant un comportement par défaut. L'auteur de la classe dérivée pourra l'appeler s'il veut l'utiliser : class B { public: virtual bool f() = 0; }; bool B::f() { return true; // c'est un bon comportement par défaut, mais // il ne devrait pas être utilisé en aveugle } class D : public B { public: bool f() { return B::f(i); // si D veut le comportement par défaut, // il doit le dire } }; 2.2.3. Solution de rechange pour les diagnostics de mauvais compilateurs Il y a des situations dans lesquelles il se peut que vous vous retrouviez à appeler accidentellement une fonction virtuelle pure (indirectement à partir d'un constructeur ou destructeur de base ; référez-vous à votre manuel de C++ avancé favori pour avoir des exemples (Note de traduction : vous pouvez également consulter la FAQ « Puis-je appeler des fonctions virtuelles dans le constructeur (ou le destructeur) ? » : Lien 15) ). Bien sûr, un code bien écrit ne devrait pas présenter ce genre de problème, mais nul n'est parfait et ça peut toujours arriver. Malheureusement, il y a des compilateurs (c'est vrai que techniquement, c'est l'environnement de l'application qui détecte ce genre de chose. Toutefois je dirai à chaque fois "compilateur", parce que c'est généralement le compilateur qui est censé entrer dans le code qui vérifie cela pour vous quand vous lancez le programme) qui ne vous préviendront pas de ce problème. Ceux qui ne le font pas peuvent vous donner de mauvais messages d'erreur qui prennent un temps infini à comprendre. "Argh", criez-vous, quand vous diagnostiquez enfin le problème par vous-même quelques heures plus tard. "Pourquoi le compilateur ne m'a-t-il pas simplement dit ce que c'était ?" Une façon d'éviter une uméro 40 – juin - juillet uploads/s3/ dev-mag-201206.pdf