Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 9 sur 16 PremièrePremière ... 5678910111213 ... DernièreDernière
Affichage des résultats 161 à 180 sur 307

Discussion: Le langage D

  1. #161
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    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 718
    Points : 3 026
    Points
    3 026

    Par défaut

    Code :
    1
    2
    1/ Les choses soient non const par defaut (cas générique). Le compilo de décider de « constifier » si cela l'est dans la pratique.
    2/ Il est possible de spécifier explicitement que quelque chose est const. Dans ce cas, le compilo est chargé de vérifier que la contrat est bien respecté.
    Personellement ça me semble raisonnable effectivement. D'ailleurs, est-ce que le point 1 ne serait pas une optimization possible qu'un compilateur C++ actuel pourrait faire (ou fait déjà) ? Je sais que Visual Studio permet une optimization globale de l'application (je sais plus si ça l'est par défaut) et peut être que ça fait partie des optimizations effectuées, a bien y réfléchir ça me semble faisable.

  2. #162
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 677
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 677
    Points : 15 708
    Points
    15 708

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    Le compilo n'est pas la pour gérer l'engagement. Il est la pour dire « mon programmeur n'a pas marqué ceci comme const, mais en fait ça l'est, ne lui renvoyons pas une erreur dans les gencives et compilons quand même ».
    Rien ne t'empêche pour l'instant d'invoquer une fonction membre constante au départ d'un objet constant...

    La fonction membre size() de n'importe quelle collection de la STL est constante, et, pourtant, le code suivant est tout à fait correct:
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    int main()
    {
        std::vector<int> tab;
        /* remplissage du tableau */
        size_t s=tab.size();
        /*utilisation de s */
        return 0;
    }
    Tu donnes de bons exemples ou il est utile de spécifier explicitement le const. le soucis, c'est que pour que tout cela fonctionne bien, il va falloir par la suite que je colle du const partout dans mon programme, et j'ai pas mal de chance d'avoir à un moment ou a un autre à me battre avec.
    Non pas te battre avec...

    Il ne faut pas considérer le compilateur comme un ennemi, bien au contraire: c'est ton meilleur allié.

    C'est lui qui va t'aider à respecter tes engagements et une saine logique dans le cas où un objet est constant avant l'étape fatidique de l'exécution, parce qu'à ce moment là, il sera trop tard, et, loi de murphy aidant, toujours de nature à te mettre dans une situation peu enviable.
    Ce que tu mets en valeur, c'est que ce qui est dangereux, c'est la « déconstification ».
    Bien sur...

    Il n'y a aucun danger à permettre invocation d'une fonction constante au départ d'un objet non constant...

    Ce n'est pas le fait d'ajouter des restrictions qui est dangereux, c'est le fait d'en retirer
    Ce que je propose, c'est que :
    1/ Les choses soient non const par defaut (cas générique). Le compilo de décider de « constifier » si cela l'est dans la pratique.
    2/ Il est possible de spécifier explicitement que quelque chose est const. Dans ce cas, le compilo est chargé de vérifier que la contrat est bien respecté.
    C'est ce qui se fait...

    [EDIT] Du moins, si on entend par "constifier si besoin" le fait de considérer un objet non constant comme un objet constant[/EDIT]
    A la différence près que tu semblais suggérer que le compilateur puisse déterminer si, effectivement, une fonction est constante ou non, et là, je dit NON

    Le comportement du compilateur se doit d'être clairement déterminé dans une situation donnée.

    On ne peut pas se permettre de lui laisser la possibilité de choisir "ce qui est le mieux" du point de vue de la conception si l'auteur du code ne précise rien.

    Si tu lui laisse cette possibilité, il y aura toujours une chance sur deux qu'il... choisisse la mauvaise.

    Au final, le choix est simple:

    Soit on part (comme c'est le cas actuellement) du principe que les fonctions membres sont non constantes sauf indication explicite du contraire, soit on part du principe que les fonctions membres sont constantes sauf indication explicite du contraire.

    Si tu essaye de partir du principe que les fonctions membres sont non constantes mais que, si l'auteur du code ne l'indique pas, il se peut qu'elles soient, malgré tout constantes, et que c'est au compilateur de vérifier ce qu'il en est, tu t'apprête à foncer droit dans un mur...
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #163
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 677
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 677
    Points : 15 708
    Points
    15 708

    Par défaut

    Il faut bien se rendre compte que le compilateur a un travail à faire, et que c'est déjà bien suffisant: fournir un code exécutable.

    Pour ce faire, il doit suivre trois règles:
    • respecter la syntaxe et la grammaire du langage
    • s'assurer le la cohérence de la conception
    • faire en sorte que le programmeur respecte ses engagements
    On ne peut absolument pas lui demander de prendre des décisions de conception...

    Ce serait un peu comme de demander à une machine de concevoir une application et de la programmer sans avoir recours à la main d'oeuvre humaine.

    Je sais que les films comme terminator ou I robot on beaucoup déliré sur l'idée, mais on est encore loin d'y arriver
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #164
    screetch
    Invité(e)

    Par défaut

    je refuse que des feignasses fassent du code pas propre en disant "le compilo va optimiser tout ca". c'est la meme excuse qui pousse les gens a dire "mais la performance de ce code n'est pas critique". un ingenieur software se doit de pondre le code sans erreur et adapté et pas de pecher par feignantise.
    je pars du principe exactement inverse, une fonction devrait etre const par defaut et un mot clé devrait signaler que la fonction modifie l'objet. tout comme on devrait signaler qu'une fonction est virtelle.

    ce n'est _pas_ le job du compilateur de completer l'interface, c'est le job d'un architecte logiciel. quelqu'un qui ne comprend pas ca n peut pas travailler en equipe

    pour moi ca se range dans la categorie "avoir un nom de fonction qui explicite ce que fait la fonction dans son ensemble". parce que la lecture du code on la fait principalement dans l'interface, pas dans l'implementation.
    Dernière modification par screetch ; 07/01/2010 à 15h26.

  5. #165
    screetch
    Invité(e)

    Par défaut

    et pour completer sur le topic general, a la lueur des derniers posts je me rends compte que D n'est pas un langage orienté industrie, c'est un langage orienté recherche. il est tres abouti d'un point de vue theorie du langage (templates tres puissants, multi paradigmes) mais ne passe pas le "crash test" de la pratique; des problemes plus delicat comme le partage du code entre programmeurs et les outils associés sont en retard sur le reste de l'industrie.
    Dernière modification par screetch ; 07/01/2010 à 15h25.

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

    Par défaut

    Franchcment, cette remarque ne peut objectivement tenir la route.

    Tout d'abords parce que java par exemple fait la même chose, et qu'il a très bien passé le crash test comme tu dis. Ensuite, car question illisibilité, le C++ se pose quand même la.

  7. #167
    screetch
    Invité(e)

    Par défaut

    le C++ a amené une plus grande facilité de partage du code par rapport a C, qui a contribué a le rendre populaire.
    C# et Java sont des langages (comme le C++ ne me fait pas dire ce que j'ai pas dit) tres imparfaits mais des iterations sur les outils ont permis d'aider grandement a la productivité (exemple, le "folding" dans l'editeur permet de cacher les implémentations)
    le D n'apporte ni beaucoup plus de puissance ni plus d'aide a la relecture ni des outils efficaces, c'est costaud de s'imposer comme cela.

    il me semble que trop de temps a été passé sur la puissance/vitesse du compilateur et sur des details interessants au niveau du langage en delaissant ce dont l'industrie a reellement besoin, et je maintiens quelque part que le D n'est pas un langage de partage de code. Le C++, en fait, encore moins. Si un langage doit innover pour etre adopté par l'industrie c'est peut etre par la qu'il faudrait passer? ou alors dans les outils pour le rendre plus facile d'acces.

  8. #168
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 698
    Points : 6 227
    Points
    6 227

    Par défaut

    Je suis pas tout à fait d'accord avec ce qui a été dit dans le post précédent mais c'est vrai qu'une palette d'outils et un IDE puissant aide beaucoup une technologie à gagner en popularité.

    D'ailleurs les librairies graphiques préférées sont souvent celles qui offrent les meilleurs designers visuels, donc la meilleure productivité.

  9. #169
    Membre éclairé Avatar de ponce
    Inscrit en
    juillet 2008
    Messages
    343
    Détails du profil
    Informations personnelles :
    Âge : 27

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

    Par défaut

    Citation Envoyé par screetch Voir le message
    et pour completer sur le topic general, a la lueur des derniers posts je me rends compte que D n'est pas un langage orienté industrie, c'est un langage orienté recherche pour des codeurs hippies qui codent dans leur garage. il est tres abouti d'un point de vue theorie du langage (templates tres puissants, multi paradigmes) mais ne passe pas le "crash test" de la pratique; des problemes plus delicat comme le partage du code entre programmeurs et les outils associés sont en retard sur le reste de l'industrie.
    Oui en D c'est pénible de partager du code à cause de la séparation Phobos/Tango ou D1/D2.

    En C++ c'est pénible à cause de la séparation GCC/MSVC/autre, boost/pas boost, RTTI/pas RTTI, STL/pas STL, Qt/pas Qt, fromage/dessert.

    Un langage qui débarque ne peut pas vraiment avoir un environnement aussi utile et stable que les standards de l'industrie. Il y a bel et bien des efforts d'intégration (IDEs spécifiques, intégration Eclipse etc...) mais pas forcément les ressources pour faire tout ce que les gens demandent ("je veux que ca marche sur ARM", "je veux un plugin pour le support dans Visual Studio...").

    Et puis pour construire la réputation d'un langage il faut convaincre des gens à la fois dans l'industrie et dans l'académie, c'est comme ca parce que les thésard ont du temps. D reste tout de même beaucoup moins académique qu'Haskell et Scala.

    Bref, pour une fois que quelqu'un propose un langage qui n'est pas moins-puissant-que-C++ et qui promet une belle économie de ressources, on lui reproche de ne pas avoir de bouton "fold" dans une IDE. Le serpent se mort la queue.

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

    Par défaut

    J'ajouterais que code block à une intégration sympatique de D. Ça ne vaut pas visual studio, mais c'est vraiment sympatoche.

  11. #171
    Membre chevronné

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

    Par défaut

    Citation Envoyé par screetch Voir le message
    et pour completer sur le topic general, a la lueur des derniers posts je me rends compte que D n'est pas un langage orienté industrie, c'est un langage orienté recherche. il est tres abouti d'un point de vue theorie du langage (templates tres puissants, multi paradigmes) mais ne passe pas le "crash test" de la pratique; des problemes plus delicat comme le partage du code entre programmeurs et les outils associés sont en retard sur le reste de l'industrie.
    Pour moi, les derniers posts n'ont pas parlé de D, mais étaient une digression sur l'utilité de d'utiliser un const implicite/explicite.

    Pour rappel, D utilise un const explicite, comme le prouve ce code, qui foire à la compilation

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
     
    import std.stdio;
     
    class Toto
    {
    public:
        void f() const
        {
            writefln("Toto.f()");
        }
     
        void g() 
        {
            writefln("Toto.g()");
        }
    }
     
    void main(string[] args)
    {
        const Toto t = new Toto;
        t.f();
        t.g(); // Erreur "Toto.g () is not callable using argument types () const"
    }
    Code testé avec DMD 2.039 sous Mac OS X 10.6.2.

  12. #172
    Membre du Club Avatar de MenshaKaine
    Inscrit en
    juin 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : juin 2009
    Messages : 68
    Points : 47
    Points
    47

    Par défaut

    C++ legends Scott Meyers, Herb Sutter, and Andrei Alexandrescu think about these things, too — all the time. Scott and Herb are neck-deep in C++0x, while Andrei is literally writing the book on D (The D Programming Language). Herb and Andrei put the pedal to the metal on applied concurrency and parallelism; Herb is writing the book on that topic (Effective Concurrency). All three focus on the development of high-performance systems, a topic Scott’s writing a book about (Fastware!).
    Andrei Alexandrescu ecrirait un bouquin sur le D !

    http://herbsutter.wordpress.com/

  13. #173
    Membre Expert
    Avatar de Goten
    Inscrit en
    juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 23

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 580
    Points : 1 990
    Points
    1 990

    Par défaut

    C'est pas nouveau :p. Sa fait un moment qu'il est attendu. (LA référence sur le D).

  14. #174
    Membre éclairé Avatar de ponce
    Inscrit en
    juillet 2008
    Messages
    343
    Détails du profil
    Informations personnelles :
    Âge : 27

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

    Par défaut

    C'est un hippie, je parie qu'il écrit son livre dans un garage

  15. #175
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    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 718
    Points : 3 026
    Points
    3 026

    Par défaut

    Ce n'est pas nouveau, au début du thread je parlais justement de discussions a propos du D qui ont été déclenchées après la publication d'un article d'Alexandrescu et il y a effectivment mention du bouquin.

    Ce qui est interessant c'est que visiblement le bouquin va certainement servir de spécification pour mieu fixer le language. Ca me semble pas tout a fait pratique mais bon...

    Sinon Alexandrescu est aussi star-developer sur le language, il y participe activement.

  16. #176
    Membre chevronné

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

    Par défaut

    Citation Envoyé par Klaim Voir le message
    Sinon Alexandrescu est aussi star-developer sur le language, il y participe activement.
    Oui, au départ il me semble qu'il devait se concentrer sur la bibliothèque standard, mais il a pris de plus en plus d'importance. L'aspect général du langage a bien changé d'ailleurs sous son influence.
    Il a d'ailleurs prévu des nouveaux changements importants dans le langage : par exemple le mécanisme de surcharge d'opérateurs devrait être refondu avant la publication de son livre, qui coïncidera avec la stabilisation de D2.

  17. #177
    Membre émérite Avatar de oxyde356
    Homme Profil pro
    Ingénieur Recherche Imagerie
    Inscrit en
    février 2006
    Messages
    798
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Recherche Imagerie

    Informations forums :
    Inscription : février 2006
    Messages : 798
    Points : 919
    Points
    919

    Par défaut

    Le jour de la fin du C++ n'est pas là et je pense qu'elle est encore très très loin, ce langage permet de tout faire, et le nombre indénombrable de bibliothèques et frameworks qui permettent de l'étendre à tout les domaines et toutes les applis codées avec sont là pour en attester. C++ c'est vraiment l'équilibre parfait entre l'homme et la machine niveau langage (Java et C# sont bien trop loin de la machine pour moi quoi qu'en pense Microsoft), il y a certes quelques défauts mais il n'y a pas besoin d'un autre langage pour le remplacer, il suffit de modifier l'existant, et vu les possibilités...

  18. #178
    Membre éclairé Avatar de ponce
    Inscrit en
    juillet 2008
    Messages
    343
    Détails du profil
    Informations personnelles :
    Âge : 27

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

    Par défaut

    Citation Envoyé par oxyde356 Voir le message
    Le jour de la fin du C++ n'est pas là et je pense qu'elle est encore très très loin, ce langage permet de tout faire, et le nombre indénombrable de bibliothèques et frameworks qui permettent de l'étendre à tout les domaines et toutes les applis codées avec sont là pour en attester. C++ c'est vraiment l'équilibre parfait entre l'homme et la machine niveau langage (Java et C# sont bien trop loin de la machine pour moi quoi qu'en pense Microsoft), il y a certes quelques défauts mais il n'y a pas besoin d'un autre langage pour le remplacer, il suffit de modifier l'existant, et vu les possibilités...
    Qui a dit que C++ allait disparaître ?
    Enfin bon, si tu penses que C++ est un parfait équilibre c'est probable que le D ne t'intéressera pas.

  19. #179
    Membre éclairé Avatar de ponce
    Inscrit en
    juillet 2008
    Messages
    343
    Détails du profil
    Informations personnelles :
    Âge : 27

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

    Par défaut

    Citation Envoyé par oxyde356 Voir le message
    ce langage permet de tout faire
    Juste une liste de choses que je ne peux pas faire en C++ aujourd'hui:
    - CTFE
    - arrays ops
    - slices
    - propriétés
    - import
    - auto
    - templates mixins
    - nested functions
    - de pas écrire de headers
    - constexpr ("const")
    - pas besoin de preprocesseur
    - compiler en 2 sec un programme en entier (200 ms pour du link incrémental)

    alors qu'avec D1 je peux et je le fais aujourd'hui.
    Je précise que le C++, j'en vis et que merci je le connais.

  20. #180
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    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 718
    Points : 3 026
    Points
    3 026

    Par défaut

    Sans douter de tes connaissances, quelques reflexions :

    - CTFE

    Tu peux préciser stp? Je connais pas cet acronyme...

    - arrays ops

    Je ne suis pas sur de comprendre non plsu ce que tu entends par là?

    - slices

    Là par contre je ne vois pas bien en quoi en D il y a un avantage par rapport a C++, un slice a priori, est de toutes manière dépendant du conteneur ou des fonctions qui l'effectuent non?

    - propriétés

    Cette feature est pour le moins contestée au niveau C++... a mon avis avec ou sans c'est pas très important.

    - import

    Oui, tout ce qui est module est problématique en C++, visiblement le problème sera (avec de la chance) travaillé pour le TR2 (après c++0x).

    - auto

    Sera disponible dans C++0x et est aujourd'hui déjà implémenté dans des compilateurs récents comme gcc 4.4.x (si je me trompe pas) et le prochain vc10 qui devrait être officiellement dispo dans quelques mois et dont la beta est déjà dispo.

    - templates mixins

    Pas d'avis là dessus personellement.

    - nested functions

    Possibles a partir de C++0x via les lambda.

    - de pas écrire de headers

    Je ne comprends pas ce point : tu peux tout a fait coder sans header si tu n'as pas de types communs a tes différents cpp... ?

    - constexpr ("const")

    Ca arrive avec C++0x

    - pas besoin de preprocesseur

    Je ne comprends pas non plus : si tu n'utilise pas de commandes de préprocesseur, alors il ne sera pas utilisé. Ou alors j'ai mal compris ce que tu veux dire?

    - compiler en 2 sec un programme en entier (200 ms pour du link incrémental)

    C'est clair! D'après ce que j'ai lu sur le net, il se peut que si un systeme de module est mis en place, cela aiderai à largement accélérer la compilation. Mais je n'ai pas suivi les détails, je dis peut être des bêtises. En tout cas, rendre la compilation rapide aiderai grandement au niveau organisations iteratives façon scrum parcequ'on perdrait moins de temps a récupérer une version pour du feedback.

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
  •