IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Normalisation C++ Discussion :

Le futur du C++


Sujet :

Normalisation C++

  1. #21
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Comment suivez-vous l’actualité du C++ ?
    Sites comme DVP, ou le blog de Herb Sutter notamment, Channel 9 (même si c'est quand même centré sur Microsoft), et désormais isocpp.org.

    Connaissiez-vous le fonctionnement du comité de standardisation du C++ ?
    Oui, ce fonctionnement a été décrit ici dans les grandes lignes avant la standardisation de C++11, et après (nouvelles propositions, comme static if).

    Utilisez-vous le dernier standard (C++11) en production ? à titre personnel ?
    À titre personnel presque exclusivement, mais très prochainement en production, puisque les compilateurs implémentent rapidement la norme.

    Comment vous formez-vous à l’utilisation de la dernière norme (C++11) ?
    Essentiellement avec des vidéos de talks d'Alexandrescu, Sutter, Meyers, Lavavej, Stroustrup ou des articles de blogs.
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  2. #22
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    J'ai l'impression que personne ne lit : Nouvelles fonctionnalités du C++11 prises en charge dans gcc

  3. #23
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Citation Envoyé par gbdivers Voir le message
    J'ai l'impression que personne ne lit : Nouvelles fonctionnalités du C++11 prises en charge dans gcc
    En ce qui me concerne, je l'ai lu, cependant dans le cadre professionnel, nous utilisons plusieurs compilateurs, en fonction du système cible. Par exemple, pour un produit qui doit tourner sous Red Hat Entreprise Linux 4, c'est GCC 3.4, la cible.

    Pour nos produits Windows, nous venons de passer de VS2008 à VS2010. Donc on va pouvoir commencer à utiliser C++11 dans des produits Win-only...
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  4. #24
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par gbdivers Voir le message
    @Freem
    On en avait parlé dans la dernière news sur le C++17 http://www.developpez.net/forums/d11...e-version-cpp/
    Tu as le draft là : http://www.open-std.org/jtc1/sc22/wg...2012/n3347.pdf
    Je n'avais pas lu cette new... faudra que j'y remédie dans un avenir proche.
    Pour le coup, je vois l'intérêt des modules (j'ai lu très vite le début), mais je pense qu'ils vont en baver pour pondre un truc pareil, vu que ça va nécessiter par exemple de pouvoir compiler sans connaître la taille des objets que l'on veut... d'un autre côté, on peut déjà faire plus ou moins ça avec des techniques alakon quand on cache l'interface non publique.
    Heureusement qu'ils ont 5 ans pour faire ça :}

    Et puis ça pourrait aussi pas mal simplifier la vie des gens qui font des logiciels d'auto-complétion, j'ai l'impression...

    Et pour ce qui est de http://www.developpez.net/forums/d12...es-charge-gcc/ je l'avais lu... mais comparé à http://fr.wikipedia.org/wiki/C%2B%2B11 que j'accède en 9 frappes de touches, y'a pas photo (``CTRL+T "w C++11" entrée`` j'adore) ^^

    L'un est centré sur GCC et pas si simple que ça à parcourir, l'autre parle de la norme, et est plutôt clair, bien qu'incomplet sur certains points, qui peuvent être éclaircis en passant à la version anglaise.

    @niark: c'est pas un peu étrange d'utiliser un GCC si vieux à côté d'un VS si récent? REHL sont encore plus en retard que debian stable pourtant réputée pour sa lenteur (et qui utilise la 4.4) !
    Pourrais-tu m'éclairer sur la raison derrière ce point (que je qualifierai quand même de problème là... parce que je doute que GCC3 soit encore maintenu?)

  5. #25
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par isocpp
    To promote greater availability of high-quality C++ libraries, [...] and community libraries (by having an organized, and ideally tool-supported, way for C++ developers to discover and use libraries).
    Ce passage viens de me faire penser à un truc... Actuellement, le pseudo-standard de facto, make, n'a rien de standard et doit changer selon la chaîne de compilation... Accessoirement, sur de gros projets, c'est tout sauf facile à manipuler (d'où les autotools et cmake, entres autres).

    Ca serait pas mal d'avoir un outil, ou au moins un processus standard (que ce soit vraiment standard ou juste de fait) pour gérer les compilations. Parce que m'est avis que ce point est bloquant pour plus d'une personne...

  6. #26
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    C'est en parti le but des modules: virer la nécéssitée des headers et imposer aux compilateurs un moyen de juste lire les fichiers puis d'en faire des index de symboles réutilisables.
    Ca va pas définir la compilation (autre que ce qu'impose le standard actuel), mais ça va garantir que si tu utilise sles modules, tu auras un temps de compilation réduit (et accessoirement des fichiers moins verbeux et plus besoin d'inclure le bon fichier au bon chemin sur le disque..., faut juste le bon nom de module).

    Enfin...en théorie du moins.

  7. #27
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    Mais ça met pas un peu le bazar quand tu compiles juste un .cpp ? (pas de link)

  8. #28
    Membre éprouvé
    Avatar de mitkl
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2010
    Messages
    364
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 364
    Points : 1 081
    Points
    1 081
    Par défaut
    La session Q&A qui a suivi la présentation est disponible : http://herbsutter.com/2012/11/06/fri...f&utm_medium=t
    Si vous ne savez toujours pas ce qu’est la récursivité, relisez cette phrase.

    Mon blog sur la programmation et l'informatique !

  9. #29
    Membre émérite

    Inscrit en
    Mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut
    Citation Envoyé par germinolegrand
    Mais ça met pas un peu le bazar quand tu compiles juste un .cpp ? (pas de link)
    Pourquoi ? Quel est le problème ?
    Si je comprends bien le proposal sur les modules, la manière de compiler tel ou tel fichier restera inchangée.

    Par exemple :

    Version sans module :
    Imaginons trois fichiers lib.h, lib.cpp et main.cpp
    llib.cpp et main.cpp possèdent tous les deux en début de fichier un #include "lib.h"

    Lignes de commande :
    1) $CC -c lib.cpp
    2) $CC main.cpp lib.o

    1) -> compile lib.cpp et génère un lib.o
    2) -> compile main.cpp, link et génère un exécutable
    Il y a une source d'inefficacité dans ce processus, inefficacité que cherche à régler ce proposal sur les modules : lors de la compilation de lib.cpp puis de main.cpp l'#include "lib.h" va forcer une inclusion textuelle du fichier lib.h, qui va donc être recopié, scanné, tokenizer deux fois.

    Version avec module :
    Deux fichiers uniquement lib.cpp, main.cpp
    Au début du fichier lib.cpp on a une directive du style export Lib: pour définir un nouveau module
    Au début du fichier main.cp on a une directive du style import Lib;

    Lignes de commande :
    $CC -c lib.cpp
    $CC main.cpp lib.o
    Oui c'est pareil

    1) -> compile lib.cpp et génère un lib.o et un lib.mpp
    lib.mpp est le fameux fichier module, c'est une sorte de .h généré automatiquement par le compilateur. Le format de ce .mpp n'est pas encore spécifié dans le proposal mais je suppose que pour obtenir les temps de compilation les plus court possible il faudra laisser le format à la discrétion du compilateur qui pourra ainsi générer des fichiers binaires extrêmement proche de la représentation mémoire.
    2) -> compile main.cpp, link et génère un exécutable
    Lorsque le compilateur rencontre la directive import Lib dans main.cpp il va chercher et charger le fichier lib.mpp correspondant. Ce chargement est très efficace vu que le fichier est dans un format directement exploitable par le compilateur.

  10. #30
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    Ouais ais du coup si je veux juste compiler main.cpp je peux pas

  11. #31
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Citation Envoyé par germinolegrand Voir le message
    Ouais ais du coup si je veux juste compiler main.cpp je peux pas
    Il va falloir etre plus précis parceque je comprends pas du tout ta question...

  12. #32
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    Ben si je veux seulement compiler main.cpp (et pas lib.cpp), c'est pas possible avec le système de modules, contrairement au système d'include.

  13. #33
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    @germinolegrand: En effet, mais pourquoi voudrait compiler main.cpp avant d'avoir effectuer un compilation (quelconque) de lib.cpp ? A part imposer un ordre sur le processus de compilation/recompilation, ça ne gène pas.

    NB: J'ai pas lu le proposal, je me base sur ce qu'à dit Arzar.

  14. #34
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    parce que tout simplement j'ai pas accès aux autres fichiers ou je compile simplement pour vérifier que j'ai pas fait d'erreur de syntaxe/que c'est du C++ valide (beaucoup plus courant), pas envie de me taper 3h de compile si c'est un moteur complet que je modifie un peu.

    Edit: ou bien qu'on est en train de bosser à 2 sur le code chacun sur son fichier mais qu'on a pas envie de compiler le fichier du voisin parce qu'en l'état il est pas compilable encore (bah ouais il bosse dessus), et qu'on a pas envie de mélanger toutes les erreurs de compile alors que seules celles de notre propre fichier nous intéressent.

  15. #35
    Membre émérite

    Inscrit en
    Mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut
    Et puis à la réflexion, il y a un problème car comment distribuer une bibliothèque (sans le code source) si l'on ne peut pas distribuer un couple .h/.dll ou .h/.lib ?

    Donc j'ai en fait mal lu le proposal
    En fait dans le proposal la compilation d'un fichier cpp génère deux fichiers (en plus du .o) :

    - Un fichier d'interface
    - Un fichier d'interface pré-compilé (PIF)

    Le fichier d'interface (.mpp dans le proposal) est au format texte, lisible par un humain et destiné à être distribué. Il est extrêmement proche de ce que pourrait être un .h généré automatiquement par le compilateur + quelques annotation. D'après le proposal il est "désirable que les fichiers d'interface soient standardisés". Le proposal donne un exemple de ce que pourrait ressembler un fichier d'interface "5.1 The interface file" (mais c'est juste un exemple j'ai l'impression qu'une standardisation complète demanderait énormément de boulot...)

    Le PIF est la version binaire de ce fichier d'interface, pré-compilé, très efficace, propre à chaque compilateur. Ce PIF n'a pas pour vocation à être distribué, vu que s'il n'est pas présent à la première compilation alors le compilateur le génèrera pour accélérer les compilations futures.

    Pour ce qui est du pb soulevé par germinolegrand, il y a une section du porposal dédié (2.4 Writing Against Unimplemented Interfaces) qui ne résout pas complètement le problème mais donne au moins un workaround : Écrire dans un premier temps un squelette de lib.cpp ne contenant que les déclarations (comme un .h quoi ) et compiler une fois pour obtenir le fichier d'interface correspondant. Ce fichier d'interface obtenu peut être alors distribué et utilisé pour compiler et travailler indépendamment (comme on le ferait avec un .h).

    Edit : Du coup ça m'a l'air bien complexe comme feature et difficile à standardiser... j'espère que ça va pas finir comme les concepts

  16. #36
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    rhoooo
    Encore un bateau coulé à ajouter sur C++Land...

  17. #37
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Citation Envoyé par Arzar Voir le message
    Edit : Du coup ça m'a l'air bien complexe comme feature et difficile à standardiser... j'espère que ça va pas finir comme les concepts
    Errr... non puisque celui qui s'en occupe est le même qui a déjà implémenté les modules pour Objective-C, qu'il y a une implémentation en cours qui est apparamment prométteuse (contre des difficultés d'implémentations massives pour les Concepts) et qu'il est question de virer les headers, pas d'ajouter un meta language... autrement dis oui c'est complexe, surtout parcequ'il faut garder la rétro-compatibilité, et ça sera pas standardisé avant la prochaine grande version (tic?) qui serait pour dans 5 ans... cela dit rien n'empechera d'utiliser des implémentations. L'implémentation par celui qui s'occupe des modules est faite directement dans clang.

  18. #38
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Mais... Si on vire les headers, ça implique que tout le code habituellement un peu crado des #define qui permet une relative portabilité, celui que l'on collait dans les header parce qu'au fond c'est bien là leur place, là ou l'on définit que le code doit se compiler différemment que l'on compile pour WIN32 (je me demande d'ailleurs, WIN32, pour les nouveaux windows 64b, ça fait pas un poil ironique?) pour POSIX ou pour MICHU (ah non, pardon, ça le nom d'une table de bdd... ) va se retrouver au milieu de l'implémentation?
    Idem pour les macros?

    Bon, je sais que l'on a tendance à le limiter au maximum, et que des #ifdef se retrouvent au final dans le cpp, mais les macros (qui bien que d'usage limité peuvent encore servir, parce que ça évite d'apprendre une librairie boost et les astuces genre ## sont parfois utiles) et la majorité du code relatif au pré-processeur se retrouvais dans les header...

    Tiens, maintenant que j'y songe, pareil pour les template?
    Je pense que la distinction header/implémentation tenait pas mal au fait que le header, ça se compile pas (d'où l'implémentaion des template contenue dedans, ou dans un fichier inclus par le header). Je me trompe?

  19. #39
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Citation Envoyé par Arzar Voir le message
    Edit : Du coup ça m'a l'air bien complexe comme feature et difficile à standardiser... j'espère que ça va pas finir comme les concepts
    Ça n'est pas spécialement complexe en tant que tel. C'est grosso modo ce que font les compilateurs D : les sources ont l'extension .d et le compilo peut générer des fichiers .di (D Interface) qui sont l'équivalent de ces fichiers d'interface.
    Lorsqu'il rencontre une directive import, le compilo cherche le module correspondant, que ce soit sous forme d'un fichier.di ou .d. Si c'est sous la forme d'un fichier .d, le compilo le parse et en extrait l'interface, sans s'amuser à le recompiler en entier. C'est la principale différence avec un mécanisme comme #include.

    Ce qui risque d'être plus difficile, ça va être que tout le monde se mette d'accord sur les formats de ces fichiers (on me glisse dans l'oreillette qu'il y a un peu plus de couples système/compilateur dans le monde C++ que dans le monde D)...
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  20. #40
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Citation Envoyé par Freem Voir le message
    Mais... Si on vire les headers, ça implique que tout le code habituellement un peu crado des #define qui permet une relative portabilité, celui que l'on collait dans les header parce qu'au fond c'est bien là leur place, là ou l'on définit que le code doit se compiler différemment que l'on compile pour WIN32 (je me demande d'ailleurs, WIN32, pour les nouveaux windows 64b, ça fait pas un poil ironique?) pour POSIX ou pour MICHU (ah non, pardon, ça le nom d'une table de bdd... ) va se retrouver au milieu de l'implémentation?
    Idem pour les macros?

    Bon, je sais que l'on a tendance à le limiter au maximum, et que des #ifdef se retrouvent au final dans le cpp, mais les macros (qui bien que d'usage limité peuvent encore servir, parce que ça évite d'apprendre une librairie boost et les astuces genre ## sont parfois utiles) et la majorité du code relatif au pré-processeur se retrouvais dans les header...

    Tiens, maintenant que j'y songe, pareil pour les template?
    Je pense que la distinction header/implémentation tenait pas mal au fait que le header, ça se compile pas (d'où l'implémentaion des template contenue dedans, ou dans un fichier inclus par le header). Je me trompe?
    D'abord, les include ne vont jamais disparaitre. Si tu as vraiment besoin de faire un include, ça marche aussi (voir le proposal).
    Pour les templates c'est moins clair mais si j'ai bien compris yaurait du gain de temps de compilation associé.

Discussions similaires

  1. Les futurs tutoriels Java sur DVP ?
    Par Ricky81 dans le forum Débats
    Réponses: 65
    Dernier message: 06/01/2012, 03h33
  2. [debutant] Questions sur 1 futur projet
    Par cyrull22 dans le forum XML/XSL et SOAP
    Réponses: 3
    Dernier message: 28/04/2003, 22h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo