Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 16 PremièrePremière 12345612 ... DernièreDernière
Affichage des résultats 21 à 40 sur 307

Discussion: Le langage D

  1. #21
    Alp
    Alp est déconnecté
    Expert Confirmé Sénior
    Avatar de Alp
    Homme Profil pro
    Inscrit en
    juin 2005
    Messages
    8 587
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : juin 2005
    Messages : 8 587
    Points : 11 195
    Points
    11 195

    Par défaut

    Citation Envoyé par JolyLoic Voir le message
    Enfin, sans concepts, pas d'axiomes non plus, et là, je ne vois rien qui puisse faire comme ces derniers.
    Ce qui est dommage, c'est qu'on ne savait pas trop à quoi s'attendre pour les axiomes... On va dire qu'on a du mal à voir comment le compilo peut en faire quelque chose.

  2. #22
    screetch
    Invité(e)

    Par défaut

    si GCC avait un support direct du D (sur toute les plate formes, sans qu'il soit exterieur) alors D serait plus populaire.

  3. #23
    Expert Confirmé Sénior
    Homme Profil pro Mathias Gaunard
    Ingénieur développement logiciels
    Inscrit en
    décembre 2003
    Messages
    3 550
    Détails du profil
    Informations personnelles :
    Nom : Homme Mathias Gaunard
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 550
    Points : 4 603
    Points
    4 603

    Par défaut

    Tu trouve qu'il est plus clair et plus concis plutôt que de définir deux concepts et de faire de l'overloading basé dessus de définir une classe de trait, et d'avoir une fonction qui dispatch l'appel vers deux fonctions avec un paramètre bidon permettant de lire la classe de traits ?
    Mais de quoi tu parles ?
    Je trouve qu'il est plus clair de définir ce qu'est un concept avec une suite d'expressions valides plutôt qu'avec une signature. Ça ne compose pas très bien avec le genre de fonctionnalité que proposent les concept_map, par contre.

    Sans compter que pour moi, la fonctionnalité principale des concepts qui est la détection d'erreur, je ne vois pas trop comment l'émuler. Avec des checks, on peut valider que le type de l'utilisateur répond bien aux contraintes (mais de manière peu élégante, je trouve), mais je ne crois pas qu'on puisse valider que l'implémentation n'utilise rien d'autre que ce qu'elle croit utiliser.
    Pour ça, on instancie l'algorithme avec un archétype, ce qui réalise un test de recouvrement, et qui est en effet un peu plus de travail. Mais ça ne concerne que l'auteur de la fonction, pas son utilisateur (et il me semble que les messages d'erreurs plus clairs, c'est un truc demandé par les utilisateurs de bibliothèques templates plus que par leurs auteurs).

    Enfin, sans concepts, pas d'axiomes non plus, et là, je ne vois rien qui puisse faire comme ces derniers.
    Les axiomes permettent au compilateur de présupposer certaines choses pour faire des optimisations éventuelles.
    En particulier, ne faire aucune optimisation est une implémentation valide.
    Une émulation (à moins qu'elle ne soit couplée à un optimiseur d'expressions Boost.Phoenix ou que sais-je) ne ferait aucune optimisation.
    Boost ftw

  4. #24
    Membre expérimenté
    Inscrit en
    février 2004
    Messages
    1 432
    Détails du profil
    Informations forums :
    Inscription : février 2004
    Messages : 1 432
    Points : 575
    Points
    575

    Par défaut

    J'ai du mal à comprendre pourquoi il faut absolument trouver un successeur au C++

  5. #25
    Membre Expert

    Inscrit en
    mai 2008
    Messages
    1 007
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 007
    Points : 1 950
    Points
    1 950

    Par défaut

    Citation Envoyé par loufoque Voir le message
    Mais de quoi tu parles ?
    Du même exemple qu'a donné Florian, je suppose.

    Ceci :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    //overload for list nodes
    template<ListNode SyntaxNodeT>
    SyntaxNodeT
    convert_node(const tree_node_t& node)
    {
    return convert_list_node(node);
    }
     
    //overload for optional nodes
    template<OptionalNode SyntaxNodeT>
    SyntaxNodeT
    convert_node(const tree_node_t& node)
    {
    return convert_optional_node(node);
    }
    au lieu de :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
     
    //overload for list nodes
    template<class SyntaxNodeT>
    SyntaxNodeT
    convert_node
    (
    const tree_node_t& node,
    typename boost::enable_if<syntax_nodes::utility::is_list_node>::type* = 0
    )
    {
    return convert_list_node(node);
    }
     
    //overload for optional nodes
    template<class SyntaxNodeT>
    SyntaxNodeT
    convert_node
    (
    const tree_node_t& node,
    typename boost::enable_if<syntax_nodes::utility::is_optional_node>::type* = 0
    )
    {
    return convert_optional_node(node);
    }
     
    /*
    * Utility types
    */
    typedef char yes_type;
     
    struct no_type
    {
    char padding[8];
    };
     
     
     
    /*
    * list_node type trait
    */
    namespace list_node_check
    {
    template<class T>
    static
    yes_type
    check_sig(typename T::item*);
     
    template<class T>
    static
    no_type
    check_sig(...);
    }
     
    template<class T>
    struct is_list_node
    {
    static const bool value = sizeof(list_node_check::check_sig(0)) == sizeof(yes_type);
    };
     
     
     
    /*
    * optional_node type trait
    */
    template<class T>
    struct is_optional_node
    {
    static const bool value = false;
    };
     
    template<class T>
    struct is_optional_node<syntax_nodes::optional_node>
    {
    static const bool value = true;
    };
    Citation Envoyé par loufoque Voir le message
    Leur enlèvement ne change rien en pratique car leurs fonctionnalités s'émulent sans problème avec une syntaxe comparable (je dirais même plus claire et concise).
    Très drole.

    Et pourtant, bizarrement, dans pas mal d'entreprise, la politique c'est PAS DE TEMPLATE, car justement personne n'arrive à comprendre et maintenir ce genre de "syntaxe comparable claire et concise" à base de boue illisible de SFINAE, traits et autres hacks.

  6. #26
    Expert Confirmé Sénior
    Homme Profil pro Mathias Gaunard
    Ingénieur développement logiciels
    Inscrit en
    décembre 2003
    Messages
    3 550
    Détails du profil
    Informations personnelles :
    Nom : Homme Mathias Gaunard
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 550
    Points : 4 603
    Points
    4 603

    Par défaut

    Comparons.

    Définition de concept :

    Code :
    1
    2
    3
    4
    5
    auto concept Foo<typename T>
    {
        typename type = typename T::type;
        void T::bar();
    };
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    template<typename T>
    struct Foo
    {
        typedef typename T::type type;
     
        BOOST_CONCEPT_USAGE(Foo)
        {
            make<T>().bar();
        }
    };
    Je dirais que la solution 2 est plus intuitive, pratique et puissante, plus en relation avec la réalité (ce qu'on veut, c'est tester que des expressions sont valides, pas des signatures), d'autant plus qu'elle s'intègre mieux dans le langage (un concept est un type, donc on peut le manipuler comme tel).

    Ensuite, l'usage :

    Code :
    1
    2
    3
    4
    template<typename T>
    requires Foo<T>, Assignable<T>
    void
    use_a_foo(const T&);
    Code :
    1
    2
    3
    4
    5
    template<typename T>
    BOOST_CONCEPT_REQUIRES(
       ((Foo<T>))((Assignable<T>)),
       void
    ) use_a_foo(const T&);
    Bien entendu, il faut une macro, mais c'est pas la mort.

    Alternativement on peut aussi faire

    Code :
    1
    2
    3
    4
    5
    6
    template<typename T>
    void use_a_foo(const T&)
    {
        BOOST_CONCEPT_ASSERT(Foo<T>);
        BOOST_CONCEPT_ASSERT(Assignable<T>);
    }
    ce qui est un peu moins bien, puisque les concepts n'apparaissent pas dans la signature de la fonction. (et donc par conséquent ne peuvent pas être utilisés pour la résolution de surcharge, mais est-ce vraiment important)
    Boost ftw

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Salut,

    Pour en revenir au noeud du problème, je peux t'assurer que les "chroniques d'une mort annoncées" d'un langages ont eu lieu de tous temps...

    Et, de tous temps, elles se sont révélées n'être que des mirages, quel que soit le langage (utilisé de manière professionnelle) visé ou le temps laissé pour qu'elles se réalisent...

    Le bémol que l'on peut émettre, c'est que certains langages se sont retrouvé limités à des secteurs de niches particuliers, mais, dans l'ensemble, dés que tu as des développements étalés sur dix ans avec un langage précis, il est souvent plus facile et moins onéreux de trouver "la perle rare" qui connait le langage et de continuer à l'utiliser que reprendre le développement intégral dans un autre langage

    Cela a été le cas avec Ada, Cobol, et C quand un nouveau langage a été annoncé (je me demande même si, concernant fortran, il n'y aurait pas eu prophétie identique à la sortie de C), et, pourtant, ils sont toujours utilisés

    De plus, la décision prise concernant les concepts en C++ ressemble plus à un ajournement concernant leur mise au point qu'à un abandon définitif

    Sans compter le fait que ce n'est pas parce qu'une feature particulière n'est pas adoptée que, forcément, cela implique que le langage subira une "perte de vitesse", même si cette feature semble importante

    Tout cela pour te dire qu'il "n'est pas impossible" que l'absence des concepts fasse que certains nouveaux programmeur décident de ne pas l'utiliser, mais qu'il y a encore de la marge pour en arriver au fait que cette absence décide ceux qui l'utilisent à changer de langage

    Ceci dit, mon avis personnel est qu'il est bon d'être "spécialisé" dans un langage particulier, mais que cela n'empêche absolument de connaitre au minimum les bases des autres, et qu'il est même souhaitable d'être en mesure de se débrouiller avec

    Il n'est pas souhaitable de vouloir les maitriser parfaitement tous, car à trop vouloir savoir tout faire, on en vient à ne rien savoir faire correctement, mais c'est malgré tout une bonne chose que d'être en mesure de poser un oeil attentif sur un code écrit dans un autre langage que celui dans lequel on est "spécialisé" et d'arriver à comprendre ce qui est fait
    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

  8. #28
    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

    Merci Koala, c'est très rassurant pour moi de lire tout ceci
    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.

  9. #29
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    14 390
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

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

    Informations forums :
    Inscription : mai 2008
    Messages : 14 390
    Points : 67 550
    Points
    67 550

    Par défaut

    So, mettons nous tous au D \o/

  10. #30
    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

    Bon alors sur proposition de Florian Goo, je relance le topic.

    Tout d'abords, pour que vous cituiez le personnage, je suis un utilisateur expérimenté de C++, mais surtout un utilisateur de D bien que j'ai bien moins d'expérience dans ce langage.

    Dans un premier temps, soyons réaliste : D ne va pas tuer C++. C++ à un tel passif qu'il ne va pas disparaitre du jour au lendemain. On a un tas de libs en C++, tout plein de programmeurs expérimentés, et c'est une techno connue vers laquelle un décideur se tournera plus facilement qu'une techno moins connues (dissonance cognitive tout ça).

    D propose de faire du C++ à l'envers. En C++, on part bas niveau, mais, avec divers outils comme les smart pointers, ce que tous le monde utilise de nos jours, on s'élève à un niveau supérieur.

    D propose de coder haut niveau d'origine, mais de descendre bas niveau quand cela est nécessaire. Ce qui est à mon avis une meilleur approche étant donné la proportion de code haut niveau vs bas niveau dans une appli standard.

    Par exemple, la mémoire alloué l'est par défaut par un GC, mais on peut décider d'utiliser le mécanisme de notre choix.

    Ou bien les fonction membres d'une classe sont virtuelle par défaut. On précise qu'elles en le sont pas à l'aide du mots clef final, se besoin est.

    Pour moi, D, c'est ce qu'aurait du être le C++ si on l'avait conçu avec l'expérience qu'on a maintenant.

    J'ai vu ici que D avait été conçu par des théoriciens. Mon avis d'utilisateur est diamétralement opposé. En connaissant C++, j'ai juste l'impression de coder plus facilement sans me sentir vraiment plus limité. La syntaxe est plus simple, les bugs moins nombreux (ou détectés plus tôt/facilement), et ça compile vite !

    D'ailleurs, ça compile suffisamment vite pour que D puisse être utilisé en langage de scripting. Le compilateur dmd fournis déjà cette possibilité.

    Parmi les choses sympathiques, il y a par exemple les unitest, les lazy évaluation pour les paramètres de fonction, les templates sont bien mieux pensées qu'en C++, permettent de faire plus plus simplement (C++0x propose des choses intéressantes la dessus, mais tout est déjà dans D), la surcharge d'opérateur est aussi mieux pensée.

    Voila pour D1. D2 promet bien plus, notamment sur le multithreading, ou l'approche est vraiment intéressante. D2 est un peu le C++0x version D, le truc génial qui peine à venir.

    Maintenant D souffre de quelques soucis de jeunesse. Il y a deux lib standard en compétition (sic) ce qui n'aide pas à s'y retrouver au début, et google est bien prolifique en réponses qu'avec C++ (bien qu'on ai généralement moins de questions aussi).

    La compatibilité avec C est très bien assurée, mais pas avec C++. Ceci est principalement du au fait que noms ne sont pas standardisées en C++, ce qui pose des soucis quand il faut lier le tout. Si appeler du code C est facile, D rompt la compatibilité au niveau syntaxique, ce qui est le principal défaut de C++ selon moi. Repartir sur une base saine et fraiche, c'est a mon avis ce qu'il faut à C++.

    Bref, c'est pour moi une bonne solution pour un projet tout neuf. Mais il faut savoir être réaliste, réutiliser l'existant est un gros point fort de C++.

  11. #31
    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

    Le D différencie allocation sur la pile et sur le tas, et donc permet le RAII. Ça c'est fort bien !

    Ou bien les fonction membres d'une classe sont virtuelle par défaut. On précise qu'elles en le sont pas à l'aide du mots clef final, se besoin est.
    Ça par contre j'aime moins. J'ai bien plus de fonctions membres « finales » que virtuelles dans mes codes…
    Enfin, vu qu'on a plus de chances de s'exclamer « ah ben voilà pourquoi ça bugue, j'avais oublié de rendre la fonction virtuelle ! » que la même chose avec s/virtuelle/finale.
    Après tout, les variables sont mutables par défaut en C++. C'est certainement plus cohérent.

    Maintenant D souffre de quelques soucis de jeunesse. Il y a deux lib standard en compétition (sic) ce qui n'aide pas à s'y retrouver au début
    Fichtrement rédhibitoire, non ?

    La compatibilité avec C est très bien assurée, mais pas avec C++. Ceci est principalement du au fait que noms ne sont pas standardisées en C++, ce qui pose des soucis quand il faut lier le tout.
    Je ne sais plus où j'ai entendu parler de volonté de standardisation de l'ABI C++. Dans C++0x, peut-être ?
    Si on pouvait utiliser du C++ aussi bien que du C en D, ce serait un essor formidable.
    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. #32
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par Florian Goo Voir le message
    Si on pouvait utiliser du C++ aussi bien que du C en D, ce serait un essor formidable.
    Oui, à la limite, une compatibilité "partielle" avec le C++, qui permettrait, disons, d'utiliser les principaux frameworks d'UI, et d'interfacer D avec la masse de code "C with classes" existant donnerait au langage une chance dans le monde professionnel.

    C'est, mine de rien, ce qui a contribué au succès initial du C++: partant d'un gros existant C, on pouvait assez facilement lui ajouter des bouts de C++, et ainsi de suite. C'est aussi ce qui a fait que le C++ traine toujours, 20 ans après, cet héritage...

    Francois

  13. #33
    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

    La possibilité d'utiliser des libs C++ serait déjà intéressante.
    EDIT : Grâce à Scalpel (voir signature), on pourrait envisager un générateur de binding.

    Rendre possible l'inclusion directe de C ou C++ dans du code D serait reproduire l'erreur commise par le C++… la même « erreur » qui a permis des migrations de gros programme de C vers C++, certes.
    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.

  14. #34
    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 Florian Goo Voir le message
    Ça par contre j'aime moins. J'ai bien plus de fonctions membres « finales » que virtuelles dans mes codes…
    Enfin, vu qu'on a plus de chances de s'exclamer « ah ben voilà pourquoi ça bugue, j'avais oublié de rendre la fonction virtuelle ! » que la même chose avec s/virtuelle/finale.
    Après tout, les variables sont mutables par défaut en C++. C'est certainement plus cohérent.
    C'est très pragmatique :
    - Une fonction virtuelle qui ne devrait pas l'être ne va pas poser de gros problèmes, si ce n'est une indirection lors de l'appel. Ce qui est en fait insignifiant dans la plupars des cas (cela n'est signifiant que si la fonction est destinée à être appelée très souvent).
    - Le compilo peut optimiser de lui même en « finalisant » une méthode.

    Mais bon, visiblement, ton message montre que tu as bien comprit ce point.

    De plus, D fait une différence très nette entre classe et structure.

    Dans une classe les méthodes sont virtuelles par défaut. On y fait de l'héritage, et toutes les classe héritent de la classe Object. Bref, on est dans le paradigme objet a fond les ballons.

    Dans le cas de la structure, on ne peut pas avoir de méthodes virtuelles ni d'héritage. Il y a fort a parier que nombre de tes classes C++ devraient être en fait traduite en D par des structures plutôt que des classes.

    Citation Envoyé par Florian Goo Voir le message
    Fichtrement rédhibitoire, non ?
    Je ne te le fais pas dire !


    Citation Envoyé par Florian Goo Voir le message
    Je ne sais plus où j'ai entendu parler de volonté de standardisation de l'ABI C++. Dans C++0x, peut-être ?
    Si on pouvait utiliser du C++ aussi bien que du C en D, ce serait un essor formidable.
    Non, je n'ai pas entendu parler de ça. Ça serait d'ailleurs un sacré problème étant donné le passif qu'on a en C++ de changer l'ABI comme ça. Mais c'est aussi un sacré problème d'être dans le merdier qu'on a actuellement à ce sujet. je penses que c'est l'un des faiblesses du C++, mais celle-ci étant historique, il sera très dur de revenir dessus.

    D prévoit de s'interfacer avec le C++, mais ce problème d'ABI fait que cela a été reporté à plus tard.

  15. #35
    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 Florian Goo Voir le message
    EDIT : Grâce à Scalpel (voir signature), on pourrait envisager un générateur de binding.
    Ça ne résout pas le problème de l'ABI, mais c'est clairement une partie de la solution.

    Citation Envoyé par Florian Goo Voir le message
    Rendre possible l'inclusion directe de C ou C++ dans du code D serait reproduire l'erreur commise par le C++… la même « erreur » qui a permis des migrations de gros programme de C vers C++, certes.
    Sur ce point, D à fait quelque chose d'intéressant. S'il est trivial d'appeler du code C depuis D, la compatibilité syntaxique est rompue.

    Pour importer des lib bien connues, on peut faire :

    import std.c.stdio

    Ce qui revient à inclure stdio.h .

    Pour des choses personnalisées :
    extern (C) int foo(int a); //Pour cdecl
    extern (Windows) int foo(int a); //Pour stdcall

    Bref, rien de plus simple. On compile le C d'un coté, le D de l'autre, et on lie tout ensemble.

  16. #36
    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

    Sur ce point, D à fait quelque chose d'intéressant. S'il est trivial d'appeler du code C depuis D, la compatibilité syntaxique est rompue.
    Oui, c'est la fameuse « erreur » à laquelle je faisais allusion (mais que tu as mieux formulée que moi ).
    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. #37
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    <snip>
    De plus, D fait une différence très nette entre classe et structure.

    Dans une classe les méthodes sont virtuelles par défaut. On y fait de l'héritage,
    Ca, ca ne me gène absolument pas, et je trouve d'ailleurs l'idée "raisonnable" par contre
    et toutes les classe héritent de la classe Object.
    Ca, ca me gène déjà beaucoup plus...

    Mais c'est un travers repris par plus d'un langage.

    Je comprend le principe, mais cela signifie:
    1. que tu *risque* de te retrouver avec une arborescence d'héritage comprenant un nombre élevé de niveaux là où deux ou trois auraient suffit sans cet héritage "d'office"
    2. que LSP est, à tout le moins, envisagé d'un coté bizarre de la lorgnette, car quel pourrait bien être le point commun (récupéré de Object) entre une classe voiture, une classe chien et une classe pomme
    3. Que l'héritage multiple, s'il est autorisé, finit immanquablement en héritage en losange, voir en diamant, avec les problèmes que cela comporte (mais peut être est-ce géré d'une manière ou d'une autre par le langage )
    Bref, on est dans le paradigme objet a fond les ballons.
    Je vais peut être te surprendre, mais, plus ça va, plus j'ai l'impression que l'on considère à tord le paradigme objet comme la solution miracle à tous les maux.

    Attention, n'allez pas me faire dire ce que je n'ai pas dit: je trouve énormément de qualités au paradigme objet...

    Mais cela n'empêche que j'estime que son potentiel est encore bien plus large s'il est couplé, par exemple, avec le paradigme générique, voire, pourquoi pas, avec une petite dose de procédural pur (une bonne fonction libre, éventuellement générique peut éviter pas mal de circonvolutions qui seraient nécessaires si on devait s'en tenir au seul paradigme objet)
    Dans le cas de la structure, on ne peut pas avoir de méthodes virtuelles ni d'héritage. Il y a fort a parier que nombre de tes classes C++ devraient être en fait traduite en D par des structures plutôt que des classes.
    Très certainement, et je citerais en premier les classes ayant sémantique de valeur

    Mais, en C++ la distinction entre une classe et une structure est à ce point ténue (elle tient dans la visibilité par défaut de la classe/structure) qu'il est tout à fait possible d'utiliser indifféremment l'un pour l'autre
    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

  18. #38
    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

    Tiens, il m'avait échappé le coup de la classe Object… je ne suis pas fan non plus.
    Concernant l'héritage multiple en losange, diamant ou parallélépipède rectangle, pas de problème puisque l'héritage multiple n'est pas autorisé.

    Je te rejoins sur l'exagération de la suprématie du paradigme objet. En revanche il me semble que les fonctions libres sont autorisées en D, donc fausse alerte.
    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.

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par Florian Goo Voir le message
    Tiens, il m'avait échappé le coup de la classe Object… je ne suis pas fan non plus.
    Concernant l'héritage multiple en losange, diamant ou parallélépipède rectangle, pas de problème puisque l'héritage multiple n'est pas autorisé.
    C'est un choix qui se vaut, mais auquel j'ai malgré tout le plus grand mal à adhérer, même si je le respecte...

    La raison est, sommes toutes, des plus simple, mais je lui trouve une certaine importance:

    Cela t'oblige à prendre en compte les restrictions imposées par le langage alors que tu n'est encore que très loin d'envisager ne serait-ce que la première ligne de code, du moins, dans un process idyllique de mise au point d'une application.

    Je m'explique:

    A la base de la mise au point, il y a (normalement) une analyse des besoins, des cas d'utilisation et tout plein de chose qui, au final, déboucheront sur un ou plusieurs diagrammes de classes.

    Et il est plus que vraisemblable que, à un moment donné, tu en vienne à te dire que "ce serait pas mal si ma classe C héritait de ma classe A et de ma classe B", dans le plus pur respect de LSP.

    Mais, c'est à ce moment là que tu te rappelle que "mince, zut, flute, j'avais oublié: le langage que j'utilise n'autorise pas l'héritage multiple"... Et encore, cela implique que celui qui s'occupe de la conception sache quel sera le langage utilisé (re )

    Alors, de deux choses l'une:

    Ou bien celui qui s'occupe de la conception en connait "suffisamment" sur le langage pour savoir qu'il doit éviter l'héritage multiple, mais il se retrouve confronté à devoir faire des circonvolutions pour "faire avec" cette limite.

    Ou bien il ne connait pas la limite (ou décide de ne pas en tenir compte, ce qui serait bien pire, mais qui arrive surement), et c'est le pauvre type chargé de l'implémentation qui doit, au mieux, demander à ce que l'on refasse le travail (avec le surcout et la perte de temps que cela implique), au pire se "démerder" et ne pas suivre le "plan" que l'on a tracé pour lui.

    Mais soyons clair sur un point: c'est un reproche que je fais de manière générale à tout langage qui place ce genre de restriction... Même si j'arrive à m'y faire lorsque je suis obligé d'utiliser un tel langage

    [EDIT]Je précise que, selon moi, une bonne conception (ou un bon algorithme, d'ailleurs) devrait pouvoir être totalement indépendant du langage dans lequel il ou elle sera implémenté et que ce n'est, en tous cas, pas au langage de placer des restrictions "arbitraires"...
    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

  20. #40
    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

    Depuis le moment où j'ai appris l'existence des principes « préférez la composition à l'héritage » et « une classe hérite pour être réutilisée dans un contexte polymorphe et non pour réutiliser les fonctions de la classe mère » , je n'ai pas rencontré de cas où l'héritage multiple s'imposait (sauf pour les bidouilles du style boost::noncopyable ou boost::enable_shared_from_this, qui n'auraient pas lieu d'être en D).

    Je ne suis pas un grand fan du Java, mais j'ai fini par concéder qu'un système à base d'héritage simple et d'interfaces était suffisant voire supérieur et à imiter en C++.
    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.

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
  •