Publicité
+ Répondre à la discussion
Page 4 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 61 à 80 sur 84
  1. #61
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 133
    Points
    2 133

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    [...]C (pas le C++...), Fortran et Ada. Point.
    PAscal, D… et puis faut pas exagérer: même si je n'aime pas le C++ on peut avoir de la performance quand même avec

    En tout cas, on va dans le même sens ou presque.

  2. #62
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 129
    Points
    1 129

    Par défaut

    Citation Envoyé par Garulfo Voir le message
    PAscal, D… et puis faut pas exagérer: même si je n'aime pas le C++ on peut avoir de la performance quand même avec

    En tout cas, on va dans le même sens ou presque.
    Ah oui, je l'avais oublié celui-là, Pascal. Pour D... je suis un peu dubitatif étant donné que c'est un langage très peu utilisé, mais certainement de qualité.

    Pour ce qui est de compiler du C avec du C++... je répondrai ce que répondent les vrais programmeurs C++ (mais je n'en suis absolument pas un) : "On ne fait pas du C++ à la mode C".

    Citation Envoyé par alex_pi
    Citation Envoyé par InOCamlWeTrust
    Si on me demandait à moi ce qu'est un bon code, je dirais qu'il s'agit d'un code robuste à toutes les erreurs possibles et imaginables, comme on le voit dans les codes C bien faits et quasiment jamais dans les programmes écrits en fonctionnel.
    Les seuls tel codes que je connaissent sont justement écris dans des langages purement fonctionnels tel que le Calcul Inductif des Constructions :-)


    Pour ce qui est des performances asymptotiques, on est malheureusement forcé de constater que les structures modifiables comme les tables de hachage ou les tableaux sont pour beaucoup d'opérations, mais pas pour la totalité, plus performantes (asymptotiquement) que des AVL ou des listes, sous toutes leurs formes. Pour certaines opérations les strucutres fonctionnelles peuvent s'avérer plus efficaces (asymptotiquement), mais pas pour toutes.

    Enfin, je reste persuadé que le problème de la performance en termes de temps de calcul de nos chers programmes, scripts d'affichage de pages web, et tout le beau monde va revenir, un jour à l'autre, sur le devant de la scène. La puissance des CPU stagne (attendons tout de même les premiers CPU gravés en 45 nm... je pense que la différence sera très significative), mais les programmes deviennent plus gros chaque jour, programmés dans des langages lents (Java, PHP, Ruby, Python), avec tout un tas de manies logicielles qui ne servent à rien, sinon à faire le beau devant son patron (comme cette manie de tout sérialiser en XML)...

    Il y a quelques années, quand tu avais l'ADSL à la maison, la page s'affichait instantanément : c'était pratiquement que du HTML. Aujourd'hui, les débits ont grossi d'un facteur au moins 10 en zone urbaine, mais beaucoup de pages web mettent jusqu'à plus de 5 - 10 secondes à s'afficher ! Personnellement, je vais très souvent sur eBay, et franchement, il y a des fois où je pense que j'étranglerais les développeurs ! En plus ils ont changé ça (ebay.com, car certains autres sites ebay l'avaient fait avant), et maintenant, c'est encore plus lent !

    Résultat, en 5 ou 6 ans : CPU x 5 ou 6 (pas en fréquence, hein, mais en nombre d'opérations !), RAM x 10 (facilement...), débit x 10... mais tout est plus lent, mis à part les video.

    Le paradoxe est là.

    A quoi sert la puissance de nos ordinateurs ?

    Et bien elle sert à faire des trucs aussi intelligents que getTrucMuche(b){ return b.getMachinTruc()}... mais 1 000 000 000 de fois pas seconde.

    Dans les entreprises, avant, on imprimait. Avec l'ordinateur, tout le monde a cru que l'on n'imprimerait plus. Faux, car avec l'ordinateur on peut imprimer deux fois plus vite... et c'est ce qui s'est réellement produit.

    Et bien là, c'est pareil : ce genre de truc, personne ne pouvait se le permettre sur des 68000, à moins de le faire peu souvent. Avec l'arrivée du GigaHertz, tout le monde a pensé que tout irait plus vite. Et bien c'est faux, car avec le GigaHertz, on peut se le permettre jusqu'à 1 000 000 000 de fois par seconde.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  3. #63
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 009
    Points
    1 009

    Par défaut

    Pour ce qui est des performances asymptotiques, on est malheureusement forcé de constater que les structures modifiables comme les tables de hachage ou les tableaux sont pour beaucoup d'opérations, mais pas pour la totalité, plus performantes (asymptotiquement) que des AVL ou des listes, sous toutes leurs formes. Pour certaines opérations les strucutres fonctionnelles peuvent s'avérer plus efficaces (asymptotiquement), mais pas pour toutes.
    On peut utiliser des structures "modifiables" dans un langage fonctionnel. Par exemple OCaml. On peut même souvent les utiliser en conservant la transparence référentielle, en les utilisant de manière "linéaire", c'est à dire en conservant en permanence au plus une référence (adresse, etc.) en écriture vers cette structure (en gros : pas d'aliasing). On peut même demander au compilateur de vérifier cette linéarité à notre place, en la rendant explicite, par exemple par le biais de monades (Haskell) ou de types uniques (Clean), ce qui permet leur utilisation dans les langages fonctionnels "purs".


    On peut donc programmer de façon globalement fonctionnelle, en utilisant au besoin des structures modifiables, et donc en profitant de leurs performances asymptotiques.

  4. #64
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 128
    Points
    1 128

    Par défaut

    Pour ce qui est de compiler du C avec du C++... je répondrai ce que répondent les vrais programmeurs C++ (mais je n'en suis absolument pas un) : "On ne fait pas du C++ à la mode C".
    Bien sûr, c'est aussi ce que je recommande, partant du principe que C++ est beaucoup mieux que C. Mais si tu as peur de perdre quelques cycles en instanciant une classe, c'est peut-être la solution pour toi. Toujours est-il que les performances de C++ sont très bonnes - ce n'est pas plus lent qu'OCaml, en moyenne.

    A quoi sert la puissance de nos ordinateurs ?
    À pouvoir utiliser des outils de plus haut niveau et diminuer le temps de développement.

    Enfin, je reste persuadé que le problème de la performance en termes de temps de calcul de nos chers programmes, scripts d'affichage de pages web, et tout le beau monde va revenir, un jour à l'autre, sur le devant de la scène.
    Peut-être, mais dans ce cas, c'est Perl, Ruby, JavaScript, PHP et Python qui vont perdre de l'intérêt. Java, C++ et C# resteront, leurs performances sont correctes. Les machines virtuelles s'améliorent avec le temps.

  5. #65
    alex_pi
    Invité(e)

    Par défaut

    Y a un truc que je ne comprends pas. Tu as dit:
    Citation Envoyé par InOCamlWeTrust Voir le message
    A quand un langage qui vérifie la taille des matrices à la compilation ?
    a quand un langage qui vérifie la taille des listes ?
    C'était ironique ? Parce que sinon, il va falloir se faire une raison. Ces propriétés sont complètement indécidables. Donc il va falloir soit une forme de type dépendant, soit une possibilité de fournir des preuves au système (en fait si le premier, il faut aussi le deuxième..). Et à coté de ça, tu dis que Coq c'est "de la branlette". Il va falloir choisir à un moment.

  6. #66
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 009
    Points
    1 009

    Par défaut

    Peut-être, mais dans ce cas, c'est Perl, Ruby, JavaScript, PHP et Python qui vont perdre de l'intérêt. Java, C++ et C# resteront, leurs performances sont correctes. Les machines virtuelles s'améliorent avec le temps.
    Ou alors Perl, Ruby, JS et PHP se doteront de VM décentes. Et c'est justement ce qui est en train d'arriver (bon peut-être pas PHP, il faut pas déconner non plus).

  7. #67
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 128
    Points
    1 128

    Par défaut

    Si, PHP compile sous .Net et ça marche bien. En effet, tous ces langages vont beaucoup améliorer leurs performances. Mais ça restera toujours plus lent, du fait du typage dynamique.

    Pour toutes les tâches où les performances ne sont pas cruciales, je pense aussi que ces langages-là vont rester.

  8. #68
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 133
    Points
    2 133

    Par défaut

    Citation Envoyé par LLB Voir le message
    [...]partant du principe que C++ est beaucoup mieux que C. [...]
    Humm c'est aussi troll que quand IOCWT dit que C c'est incomparablement mieux que C++

  9. #69
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 129
    Points
    1 129

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    Y a un truc que je ne comprends pas. Tu as dit:

    C'était ironique ? Parce que sinon, il va falloir se faire une raison. Ces propriétés sont complètement indécidables. Donc il va falloir soit une forme de type dépendant, soit une possibilité de fournir des preuves au système (en fait si le premier, il faut aussi le deuxième..). Et à coté de ça, tu dis que Coq c'est "de la branlette". Il va falloir choisir à un moment.
    Non, je ne dis pas que Coq c'est de la branlette, mais ce n'est pas, à ma connaissance, un langage de programmation, même si on peut lui faire cracher de l'Haskell ou du OCaml... et encore moins un outil très largement diffusé. Je ne lui ôte aucune vertu, ceci dit.

    Pour ce qui est de la vérification des tailles à la compilation, je confirme que ce n'est pas de l'ironie. J'y travaille, d'ailleurs, même si mes autres activités ne me permettent pas de m'y consacrer à plein temps.

    Il y a deux problèmes.

    1- le problème de débordement d'indice, qui est indécidable.

    2- le problème de s'assurer que les matrices, ou listes, sont utilisées avec les bonnes tailles, et ce, quelques soient les tailles, qui lui est complètement décidable.

    Vérifier la 2- ne veut pas dire que l'on vérifie la 1-, bien-sûr.

    Par exemple, si une fonction prend deux listes en argument, la deuxième devant être, pour des raisons algorithmiques, de taille double, le vérifier à la compilation.

    Désolé, mais je ne donnerai pas plus de détails sur le forum.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  10. #70
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 129
    Points
    1 129

    Par défaut

    Citation Envoyé par Garulfo Voir le message
    Humm c'est aussi troll que quand IOCWT dit que C c'est incomparablement mieux que C++
    Je ne me suis pas très bien exprimé.

    C++ n'est pas lent, mais les pratiques, parfois très lourdes, des gens qui programment en C++ font que les codes C++ sont plus lents que leurs équivalents C.

    Je ne parle ici que pour ces programmes qui ont absolument besoin de hautes performances, comme les programmes de calcul intensif, mais parfois, si les programmes étaient faits en C, donc si ils adoptaient un modèle de programmation et d'architecture plus simple, ce serait pas plus mal à mon avis.

    Citation Envoyé par InOCamlWeTrust
    Oui, et si on est préoccupé par les performances, il faut aller voir ailleurs : C (pas le C++...), Fortran et Ada. Point.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  11. #71
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 133
    Points
    2 133

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    Je ne me suis pas très bien exprimé.
    [...]
    Dis comme ça, on est d'accord.

  12. #72
    Membre Expert
    Inscrit en
    avril 2008
    Messages
    999
    Détails du profil
    Informations forums :
    Inscription : avril 2008
    Messages : 999
    Points : 2 193
    Points
    2 193

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    Je pense qu'il faut prendre plus de recul.

    Pour commencer, il n'y a pas de bonne façon de programmer. Il y a des codes plus élégants que d'autres, plus concis, plus clairs. Si on me demandait à moi ce qu'est un bon code, je dirais qu'il s'agit d'un code robuste à toutes les erreurs possibles et imaginables, comme on le voit dans les codes C bien faits et quasiment jamais dans les programmes écrits en fonctionnel. D'autres auraient des critères différents.
    Exact ! J'ai des critères différents! J'ai écrit pas mal de code depuis une trentaine d'années et j'ai souvent entendu dire autour de moi que l'important était que le code marche. C'est-à-dire qu'il soit sans bug. Or, pour moi, ce n'est vraiment pas le critère essentiel, au départ. J'ai très souvent eu à intervenir sur du code pondu par d'autres. J'ai déjà vu du code qui marche parfaitement sauf qu'il est complètement incompréhensible et donc toute tentative d'évolution est extrêmement coûteuse et risquée. La moindre petite modification et tout le "bel" ensemble s'écroule sous le poids de ses rustines. Du coup, effectivement, il marche bien car personne ne veut (ne peut!) y toucher. Je préfère de loin un code avec une structure judicieuse et claire, avec de bons modules simples et qui ont du sens. De cette manière, même si le code est bourré d'erreurs, celles-ci sont faciles à détecter et à corriger. Et les évolutions sont alors grandement facilitées.

    Pour moi, c'est d'ailleurs le critère pour voir si le code est bien fait: les évolutions sont simples à mettre en oeuvre.

    Ce que j'ai décrit ici s'applique aussi à mon propre code. Comme je n'ai pas une bonne mémoire, j'ai besoin que mon code soit bien organisé et documenté pour que je puisse m'y retrouver, même au bout de quelques semaines, mois ou années.

    Évidemment, la robustesse du code est indispensable lorsque la tolérance aux erreurs est faible (logiciel médical, fusée, etc.).

    )jack(

  13. #73
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 133
    Points
    2 133

    Par défaut

    Citation Envoyé par jack-ft Voir le message
    [...]Or, pour moi, ce n'est vraiment pas le critère essentiel, au départ.[...]

    )jack(
    À moins qu'on n'ait pas le même sens du terme « essentiel », il me semble que ce soit essentiel que ton code marche sans bug, mais pas suffisant certes. Le code le plus modulaire, robuste, rapide, ce-que-tu-veux, est inutile s'il ne respecte pas les besoins et s'il ne « marche » donc pas.

    Non ?

  14. #74
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    Il y a deux problèmes.

    1- le problème de débordement d'indice, qui est indécidable.

    2- le problème de s'assurer que les matrices, ou listes, sont utilisées avec les bonnes tailles, et ce, quelques soient les tailles, qui lui est complètement décidable.
    C'est évidement indécidable et la vraie question est de savoir s'il est possible de trouver une approximation sure, à l'expressivité raisonnable et passablement utilisable, le tout sans système de preuve. Et dans l'état actuel des choses, j'en doute. Mais vu que tu ne parleras pas de ta solution, fin de la discussion.

  15. #75
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 129
    Points
    1 129

    Par défaut

    Moi je parle bien du point 2-, et non du 1-.

    L'expérience montre que 80% - 90% des erreurs dans le programmes de calcul numérique sont dûs à des erreurs de dimensions. Or il est possible en mettant un mécanisme très simple à l'utilisation, et absolument pas contraignant, d'en vérifier la bonne correspondance.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  16. #76
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    Moi je parle bien du point 2-, et non du 1-.

    L'expérience montre que 80% - 90% des erreurs dans le programmes de calcul numérique sont dûs à des erreurs de dimensions. Or il est possible en mettant un mécanisme très simple à l'utilisation, et absolument pas contraignant, d'en vérifier la bonne correspondance.
    J'ai bien compris que tu parlais des dimensions matricielles. Simplement, si les dimensions sont dynamiques, on se retrouve avec des quantificateurs universels (il faut bien dire que la multiplication est vraie pour tout n, ou qu'il existe un m tel que la fonction retourne une matrice de taille m x m), et si on veut autoriser les gens à produire des matrices dont les dimensions sont obtenues par multiplication, on sort de l'arithmétique de Presburger, et là, les contraintes ne sont plus décidables. Mais si tu as quelque chose de plus précis, moi ça m'intéresse :-)

  17. #77
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 209
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 209
    Points : 16 756
    Points
    16 756

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    Simplement, si les dimensions sont dynamiques, on se retrouve avec des quantificateurs universels (il faut bien dire que la multiplication est vraie pour tout n, ou qu'il existe un m tel que la fonction retourne une matrice de taille m x m), et si on veut autoriser les gens à produire des matrices dont les dimensions sont obtenues par multiplication, on sort de l'arithmétique de Presburger, et là, les contraintes ne sont plus décidables. Mais si tu as quelque chose de plus précis, moi ça m'intéresse :-)

    je n'ai pas étudié ce point en particulier, mais il me semble qu'avec de "simples" types fantomes, on devrait pouvoir avoir ces contraintes... tout comme on arrive à s'assurer qu'on fera obligatoirement un add de deux listes de même longueur
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  18. #78
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    je n'ai pas étudié ce point en particulier, mais il me semble qu'avec de "simples" types fantomes, on devrait pouvoir avoir ces contraintes... tout comme on arrive à s'assurer qu'on fera obligatoirement un add de deux listes de même longueur
    On peut bien sûr définir le type des matrices de dimension n*m, comme celui des listes de longueur l, puis imposer que les opérations se passent uniquement sur des dimensions compatibles. Le problème est de vérifier statiquement que des dimensions obtenues dynamiquement seront compatibles entre elle. Et c'est là que ça se corse salement.

    Pour les matrices, si j'ai une fonction de création, il faut lui donner le type (n : int) -> (m : int) -> 'a -> mat n m 'a . Et là on a des types dépendants ! Ou à la rigueur, pour faire uniquement des types indicés, avec des types singletons, forall n, m : Int, (int n) -> (int m) -> 'a -> mat n m 'a. Ca devient vite pénible. Ensuite, quand j'ai trois entier m, n, p, que je crée deux matrices par new_mat m n 42 et new_mat n p 69, il faut que je sois capable de suivre d'une façon ou d'une autre que les deux dimensions sont compatibles (au passage, il faut bien entendu que n soit non mutable, sinon c'est foutu) . Mais évidement, les deux matrices sont rarement créé l'une à coté de l'autre. Et si elles étaient créées de façons aussi simple, il y aurait peu de chance de se planter à la base, même sans système de vérification.

    Pour prendre des exemples plus simples, sur les listes. Si j'écris la fonction me retournant la liste des diviseurs d'un nombre n, je vais lui donner le type int -> exists l, list l int. Et là je n'a plus seulement une liste, mais un paquet existentiel à ouvrir à chaque fois que je veux atteindre ma liste, et à refermer proprement.

    Ensuite on veut écrire des fonctions sur les listes. Une simple fonction de tri par exemple, dont on va vouloir s'assurer qu'elle conserve la taille de la liste. Celle de la lib standard de Caml ne peut pas s'écrire parce qu'on a des listes de listes, et que les listes internes n'ont pas une taille constantes (ou alors on se traine des list l (exists m, list m 'a mais y a moyen d'en chier, surtout pour que le typeur/système s'assure que la taille est conservée). Mais même un simple tri fusion est loin d'être trivial à typer. Prenons l'opération de fusion
    Code :
    1
    2
    3
    4
    5
    6
    let rec fusion l1 l2 =
      match l1, l2 with
        | [], l 
        | l, [] -> l
        | t1 :: q1, t2 :: q2 -> if t1 <= t2 then t1 :: fusion q1 l2 else t2 :: fusion l1 q2;;
    Si je veux que ma fonction de tri montre qu'elle conserve la taille, il faut que le système vérifie l'invariant. A condition de le lui fournir, ça doit être possible, puisqu'on n'a que des additions. Mais ce n'est pas trivial.
    Et dès que les dimensions sont obtenues à partir de produit d'entier (par exemple en découpant une matrice en sous matrices), on sort de l'arithmétique de Presburger, et les contraintes à vérifier (à supposer que l'utilisateur explicite ces contraintes !) ne sont plus décidables.

    Bref, je ne dis pas que c'est impossible de proposer un système utilisable. Je dis juste que c'est très complexe et que je suis dubitatif que ce soit faisable sans un système de preuve sur les programmes.

  19. #79
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 129
    Points
    1 129

    Par défaut

    C'est bien, je vois que la réflexion avance dans le bon sens... mais je continue à conserver de l'avance !
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  20. #80
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    C'est bien, je vois que la réflexion avance dans le bon sens... mais je continue à conserver de l'avance !
    De l'avance ? Ma réflexion sur ce qu'est la recherche et le progrès des langages de programmation m'emmène dans une autre direction. Celle de la collaboration et non de la compétition. Mais vas y, cours devant, on te suit.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •