Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 16 PremièrePremière ... 2345678910 ... DernièreDernière
Affichage des résultats 101 à 120 sur 307

Discussion: Le langage D

  1. #101
    Membre éclairé Avatar de ponce
    Inscrit en
    juillet 2008
    Messages
    343
    Détails du profil
    Informations personnelles :
    Âge : 26

    Informations forums :
    Inscription : juillet 2008
    Messages : 343
    Points : 363
    Points
    363

    Par défaut

    Oui on était en train de dire que le language D était plus productif que C++, plus facile à apprendre, et permet des choses que C++ ne pourra probablement jamais.

    Ah oui et j'oubliais : un projet de 10000 lignes compile en 3 secondes.

    Bref :
    • d'un point de vue langage, D gagne haut la main
    • d'un point de vue environnement, il perd haut la main

  2. #102
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    Sous code::block, l'intégration est relativement bien foutue.

  3. #103
    Membre chevronné

    Inscrit en
    mai 2005
    Messages
    261
    Détails du profil
    Informations forums :
    Inscription : mai 2005
    Messages : 261
    Points : 609
    Points
    609

    Par défaut

    Citation Envoyé par ponce Voir le message
    Oui on était en train de dire que le language D était plus productif que C++, plus facile à apprendre, et permet des choses que C++ ne pourra probablement jamais.
    Qu'un langage de la fin des années 2000 ait des avantages sur un autre lancé 25 ans plus tôt est normal. D'abord parce que la technique a progressé et d'autre part parce que D bénéficie du recul apporté par C++. Si Walter Bright et Andrei Alexandrescu, qui sont des experts dans leur domaine, n'avaient pas été en mesure de faire mieux, on aurait pu se poser des questions.

    Mais pour que D décolle, il faudra :
    • Que ses qualités soit suffisantes pour contre-balancer le poids de l'existant, puisqu'il est incompatible avec C++.
    • Qu'il réponde à un besoin que les autres langages ne parviennent pas à satisfaire correctement.


    À mon avis, le langage risque de décoller si C++ rencontre des difficultés à évoluer. Il me semble que le comité de normalisation de C++ 0x a du faire des concessions sur les fonctionnalités qu'ils souhaitaient voir intégrées au standard initailement : Garbage-Collector, Concepts, modules...
    D2 est conçu avec le multithread facile comme objectif, c'est bien. S'ils peuvent répondre à des besoins que C++ 0x aura eu du mal à satisfaire, il y aura là une belle opportunité pour le langage...

    Le soutien d'une ou plusieurs multinationales serait bien aussi.

  4. #104
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 725
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    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 725
    Points : 3 346
    Points
    3 346

    Par défaut

    Ce que je ne comprends pas c'est comment se fait-il qu'ils aient tant de mal à faire des spécifications précises niveau compilateur alors que visiblement c'est quand même des concepteurs super expérimentés?
    Ou alors ce n'est plus le cas avec D2?

  5. #105
    Membre éclairé Avatar de ponce
    Inscrit en
    juillet 2008
    Messages
    343
    Détails du profil
    Informations personnelles :
    Âge : 26

    Informations forums :
    Inscription : juillet 2008
    Messages : 343
    Points : 363
    Points
    363

    Par défaut

    Je ne sais pas si ce qui se passe dans le front-end D est bien compris par beaucoup de gens tout simplement.

    Ce qui est dur, (à mon avis), c'est que bien que le D soit facile à parser, la phase d'analyse sémantique qui suit est complexe, à cause des intéractions entre expansion de templates, CTFE et string mixins (qui sont un peu comme des macros C qui interviendraient après le parsing).

    Ces concepts sont récursifs à la compilation:
    un string mixin peut utiliser une fonction à la compilation (CTFE) pour créer un nouveau template qui lui même... à un moment, le compilateur dit non mais ce n'est pas bien documenté.

    C'est pourquoi le front-end officiel sert de référence pour le langage (un peu comme Python, Perl, et Ruby). Ce n'est pas si gênant vu qu'il est sous une licence libre, mais c'est gênant quand même.

    Le livre "the D programming language" devrait notamment contribuer à coucher sur le papier tout ca, d'ailleurs Alexandrescu a largement contribué à assainir le language et éliminer les zones d'ombres.

  6. #106
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    Citation Envoyé par Niark13 Voir le message
    Mais pour que D décolle, il faudra :
    • Que ses qualités soit suffisantes pour contre-balancer le poids de l'existant, puisqu'il est incompatible avec C++.
    • Qu'il réponde à un besoin que les autres langages ne parviennent pas à satisfaire correctement.
    Tu oublies un paramètre tout bête : la popularité.

    Pour ce qui est du point 2, il est remplis sans aucun doute. Pour ce qui est du point 1, le poids de l'existant en C++ est tellement lourd que le seul salut à mon avis sera de pouvoir linker du C++ avec du D.

    Des mots clefs sont réservés dans le langage pour le faire, mais rien n'est ne place de ce coté la pour l'instant (ni au niveau pratique, ni même au niveau specs).

  7. #107
    Membre émérite
    Étudiant
    Inscrit en
    septembre 2006
    Messages
    515
    Détails du profil
    Informations personnelles :
    Âge : 20

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : septembre 2006
    Messages : 515
    Points : 931
    Points
    931

    Par défaut

    Pour ma part, je pense que je me mettrai au D lorsque la version 2 sera la version considérée comme stable.

  8. #108
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    D2 promet en effet des choses sympa. Particulièrement pour le multithreading.

  9. #109
    Membre émérite
    Étudiant
    Inscrit en
    septembre 2006
    Messages
    515
    Détails du profil
    Informations personnelles :
    Âge : 20

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : septembre 2006
    Messages : 515
    Points : 931
    Points
    931

    Par défaut

    Mais pas seulement. Il y aura aussi l'introduction du mot-clé "pure" pour indiquer qu'une fonction est pure et n'appelle que des fonctions pures, de réelles fermetures, la compatibilité binaire entre Tango et Phobos...

  10. #110
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    Pour le coup du pure, je ne vois pas bien ce que ça apporte. C'est de toute façon déductible par le compilo si une fonction est pure ou non.

    Pour ce qui est de la compatibilité phobos et tango, ce n'est aps une avancé, c'est juste la résolution des merdes de D1.

    Mais en effet, phobos 2 promet des choses intéressantes, et il y a d'autres trucs que j'attends avec impatience.

  11. #111
    Membre chevronné
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 776
    Points
    776

    Par défaut

    Il y aura aussi l'introduction du mot-clé "pure" pour indiquer qu'une fonction est pure et n'appelle que des fonctions pures
    Ah ça par contre j'adorerais le voir en C++.
    « pure » c'est un peu comme « const », c'est une garantie. En l'occurrence on a la garantie que la fonction est proprement écrite et qu'elle est bien moins source à bugs.
    C'est une fonctionnalité que j'envie des langages fonctionnels.
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  12. #112
    screetch
    Invité(e)

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    Pour le coup du pure, je ne vois pas bien ce que ça apporte. C'est de toute façon déductible par le compilo si une fonction est pure ou non.

    Pour ce qui est de la compatibilité phobos et tango, ce n'est aps une avancé, c'est juste la résolution des merdes de D1.

    Mais en effet, phobos 2 promet des choses intéressantes, et il y a d'autres trucs que j'attends avec impatience.
    c'est pas deductible car une fonction peut etre pure si elle appelle des fonctions qui sont egalement pure, ce que le compilo ne peut pas verifier

  13. #113
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    Et pourquoi donc ne pourrait-il pas vérifier ça ?

  14. #114
    screetch
    Invité(e)

    Par défaut

    parce que le compilateur n'est pas un linker.

  15. #115
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 569
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 569
    Points : 2 571
    Points
    2 571

    Par défaut

    Citation Envoyé par deadalnix
    C'est de toute façon déductible par le compilo si une fonction est pure ou non.
    Parfois le compilo voit comme impures des modifications qui en fait sont pures.
    C'est le cas par exemple des changements de représentation, du genre passage de coordonnées cartésiennes en coordonnées polaires. La POO offre plein d'opportunités de changer d'implantation ou de comportement superficiel sans toucher à la valeur abstraite. D'où le mot clé pure, qui est inspiré de Eiffel je crois, comme beaucoup de choses en D.
    Du même auteur: le cours OCaml, le dernier article publié, le projet, le blog dvp et le jeu vidéo.
    Avant de poser une question je lis les règles du forum.

  16. #116
    Membre chevronné
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 776
    Points
    776

    Par défaut

    Plus simplement, c'est impossible à cause des fonctions virtuelles…
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  17. #117
    screetch
    Invité(e)

    Par défaut

    je ne suis pas sur que ca soit plus simple mais oui c'est un bon exemple

  18. #118
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    Citation Envoyé par screetch Voir le message
    parce que le compilateur n'est pas un linker.
    Ok, je parlait des deux dans mon message. Il n'y a de toute façon aucun raison pour que cela ne soit pas détectable lors du processus complet de transformation du source en exécutable.

    SpiceGuid > Oui, en effet, l'appel de fonction comme cos est un bon exemple. Ceci dit, on risque de toute façon de se retrouver ici avec un message du genre « Votre fonction pure appelle une fonction impure, corrigez moi ça grand escogriffe ! ».

    Est-ce qu'un pragma sur la définition de ces fonction n'aurait pas été amplement suffisant ?

    J'ai comme l'impression qu'on va se retrouver comme avec le const du C++ avec ces histoires de fonction impures. Le truc super envahissant qu'on colle partout, alors que le couple compilo/linker devrait être capable de repérer ça de lui-même.

    Florian Goo > Je ne suis pas sur de comprendre ce à quoi tu réponds. Mais rien d'impossible ici.

  19. #119
    Membre chevronné
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 776
    Points
    776

    Par défaut

    Florian Goo > Je ne suis pas sur de comprendre ce à quoi tu réponds. Mais rien d'impossible ici.
    Si tu as une fonction contenant un appel vers une fonction membre virtuelle, tu ne peux pas savoir à la compilation quelle sera la fonction effectivement appelée, donc tu ne peux pas savoir si la fonction appelée sera pure ou non.
    Conséquence : impossible de déterminer si une fonction qui appelle une fonction virtuelle est pure ou non.

    Il y a aussi le problème des fonctions de bibliothèque dont le compilateur ne peut accéder à la définition. Là encore, comment déterminer si une fonction contenant un appel à une fonction de bibliothèque est pure ou non, si ce n'est en ayant l'information dans la signature de la fonction ?

    « const » n'est pas une lourdeur syntaxique qu'on aimerait déléguer au compilateur comme la numérotation des lignes qui était manuelle dans les premiers langages de programmation. C'est une fonctionnalité qui est là pour aider le développeur.
    Tu peux très bien coder en C++ sans utiliser « const », comme c'est le cas en Java, si tu trouves qu'il est pratique d'envoyer un objet à une fonction sans savoir si celle-ci pourra le modifier…
    C'est pareil pour « pure ».

    Enfin, il n'y a pas de couple « compiler/linker » comme tu l'entends. Il est suffisamment difficile d'écrire proprement l'un et l'autre indépendamment. Si en plus ils sont mutuellement dépendants, non seulement la chaine de compilation sera un bloatware, mais en plus elle sera affreusement lente.
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  20. #120
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 781
    Points
    1 781

    Par défaut

    Ces choses sont déjà faites en java par exemple. Le compilo JIT est capable de savoir si une fonction membre est surchargée ou non et de l'appeler virtuellement ou statiquement. D prévoit aussi de gérer cela à la compilation (c'est d'ailleurs plus facile qu'en java, puisque D ne supporte pas le chargement dynamique de code).

    Le problème de la fonction pure est le même. Tout comme pour savoir si l'appel est virtuel ou non, il faut savoir si les fonction possiblement appelées sont toutes pures ou non.

    Par contre, ça nécessite d'avoir un (en fait 2 : pure, et pure sous réserve d'appels pure seulement) tag dans la fonction placé par le compilateur que le linkeur saura lire. Et ça marche aussi avec les bibliothèques.

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
  •