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

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

Contribuez C++ Discussion :

Le langage D


Sujet :

Contribuez C++

  1. #261
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Emmanuel Deloget
    Anales de Mathématiques Pures et Appliquées de Galois
    Un livre résolument chiant.


    Plus sérieusement, Emmanuel, je crois que je comprends mieux ton point de vue d'architecte maintenant. En tout cas merci d'avoir expliqué.

  2. #262
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Désolé pour le retard.

    Citation Envoyé par koala01 Voir le message
    Je suis bien d'accord qu'un acces en lecture ne pose-- de manière très théorique du moins, à condition de faire l'impasse sur les accès concurrent -- à peu près jamais de problème.
    Tu peux oublier la concurrence dans les paramètres : c'est la même chose avec les méthodes (quoi qu'elles soient).

    Citation Envoyé par koala01 Voir le message
    Par contre, un acces en écriture se doit d'être aussi encadré que possible et d'être permis de manière aussi restreinte que possible
    Ai-je dit le contraire ? Justement, c'est pour ça que j'apprécie les propriétés : possibilité d'avoir l'équivalent d'un attribut, mais en lecture seule (= sous-entendu "consultation libre", mais pas touche en écriture).

    Citation Envoyé par koala01 Voir le message
    tu permet à tout le code d'avoir un acces en écriture sur des objets au sujet desquels un tel acces devrait être particulièrement restreint.
    Bien sûr que non. J'utilise fréquemment un système de verrou par TLS par exemple, qui restreint l'accès à certaines méthodes à certains threads seulement : c'est très utile pour éviter d'avoir à dériver une classe particulière suivant l'accès autorisé ou pas, et se retrouver au final à devoir détruire/reconstruire des classes "pour rien" quand les threads changent de rôle.
    (Pour simplifier, c'est un problème de multiplexage de threads "drivers" qui doivent passer en mode stub de façon dynamique en fonction d'un état global. Le problème étant d'avoir quelque chose d'extrêmement performant tout en étant robuste)

    Citation Envoyé par koala01 Voir le message
    Je suis, encore une fois, désolé d'insister sur ce point, mais c'est loin d'amener une situation idéale
    C'est bien mieux qu'un accesseur, qui est quelque chose de quasiment impossible à empêcher / contrôler (ce n'est qu'une méthode, après tout !!!), tandis qu'une propriété a au moins le mérite d'être clairement identifiable, et potentiellement restreinte.

    Citation Envoyé par koala01 Voir le message
    pire encore, tu encourage le développeur à fournir un acces en écriture à un attribut qui, non seulement, ne devrait déjà pas être accessible en lecture "depuis l'extérieur", mais au sujet duquel il est encore plus incohérent d'envisager d'en permettre un acces en écriture.
    T'inquiètes pas : ce genre de bestiau fait en général un accesseur et un mutateur en même temps que son attribut. C'est triste, mais c'est pourtant le cas... T'as pas idée du nombre de gens qui considèrent comme "obligatoire" d'avoir deux accesseurs (publics, bien sûr) pour CHAQUE attribut interne... Et qui te regardent comme un alien quand tu leur demande pourquoi ils ne virent pas leur fonction en mettant l'attribut public.
    Sans vouloir lancer un troll, ils sont en général issus de Java...

    J'ai même déjà vu cette horreur (refaite de mémoire) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    #define MAKE_ATTRIBUTE(aName,aType) \
    private: aType aName ; \
    public: aType get##aName () { return this->aName ; } \
    public: void set##aName ( aType aValue ) { this->aName = aValue ; }
    Avec les attributs de la classe définis via cette macro.

    Oui, je t'accorde cinq minutes pour pleurer.

    Citation Envoyé par koala01 Voir le message
    Bien sur, tu me dira qu'il faut laisser les "bons" programmeurs faire le boulot, mais je te rappelle encore une fois que tous ne sont pas aussi bons qu'ils ne peuvent le laisser croire...
    Yep, mais bon : t'as des garde-fous à ce niveau aussi... Relecture des specs / conceptions, documentation automatique et relecture de ladite doc (plus rapide et pratique que de relire le code), et bien sûr l'utilisation des classes en question.

    Citation Envoyé par koala01 Voir le message
    Ca facilite grandement, au contraire, vu, qu'à l'extrême limite, il suffit d'une ligne de code pour... exposer aussi bien le mutateur que l'accesseur...
    Et c'est presque plus un risque qu'un avantage...
    La même chose avec les attributs (mettre "public:" devant), les accesseurs triviaux (cf. horreur ci-dessus), etc.

    Citation Envoyé par koala01 Voir le message
    Tu le sais aussi bien que moi, l'homme est par nature un imbécile distrait.
    Oui, c'est pour ça que je garde précieusement Sœur Matraque près de moi, pour limiter la distraction...

    Citation Envoyé par koala01 Voir le message
    Le programmeur n'étant qu'un homme, il est, lui aussi, un imbécile distrait (et je me mets volontiers en tête de liste )
    C'est pour ça que l'on a plein d'outils pour limiter la casse, à condition de les utiliser et de lire ce qu'ils nous disent.

    Citation Envoyé par koala01 Voir le message
    Au final, si tu donnes la possibilité à quelqu'un de modifier un attribut alors qu'il ne le devrais pas, tu dois t'attendre à rencontrer "un imbécile" pour essayer de le faire.
    Certes. Mais c'est la même chose partout : j'ai déjà vu des goyots mettre en commentaire la ligne "private:" d'une classe pour accéder à ses attributs privés sans en hériter ou devoir écrire une méthode d'accès... Et un "//", c'est plus rapide à insérer que n'importe quelle propriété.

    Citation Envoyé par koala01 Voir le message
    Bref, avec les propriétés, tu as beaucoup trop tendance à centraliser des comportements qui feraient beaucoup mieux... de rester clairement séparés.
    C'est là où je ne suis pas d'accord... Une entité = un concept. Maîtrise l'entité, tu maîtrises le concept et réciproquement.

    Citation Envoyé par koala01 Voir le message
    En simplicité et en capacité de faire des conneries, parfois même sans s'en rendre compte, parce qu'un caractère "malencontreux" peut te faire passer en "ecriture"...
    Ah, tu parles d'un problème spécifique à la grammaire (pourrie) du C et C++, là...
    Ce problème est impossible dans beaucoup de langages, comme (au hasard) Delphi, et de façon générale tous les langages non-issus du C.
    Mais bon : un compilateur bien réglé t'envoie un beau warning là-dessus, encore faut-il lire ces warnings et ne pas les masquer.

    Citation Envoyé par koala01 Voir le message
    Tu as, sans doute, un attribut qui garde en mémoire le nombre d'éléments que ta collection comporte, et tu as:
    • une (série de) fonction(s) dont le comportement est clairement déterminé susceptible(s) de modifier cet attribut
    • un seule et unique fonction te permettant de récupérer le nombre d'éléments contenu
    J'ai donc UNE propriété donc la lecture renvoie cette information (possibilité unique), et dont l'écriture effectue un comportement clairement déterminé en fonction de la valeur écrite... Je ne vois pas la différence, sauf que j'ai tout centralisé en un seul point au lieu d'avoir des \see longs comme le bras dans une demi-douzaine de fonctions.

    Citation Envoyé par koala01 Voir le message
    A vrai dire, je fais partie de ceux qui regrettent profondément la présence de [] dans les std::map et qui regrettent encore plus profondément le fait que la sémantique qui est donné à cet opérateur permette aussi bien de rechercher un élément que d'en insérer un...
    Franchement, sans cet opérateur, ça fait longtemps que je n'utiliserais plus DU TOUT les maps de la STL... Je ne suis pas le seul, je pense, et les itérateurs font partie des choses franchement rebutantes... Le pire : certains se targuent d'un code imbitable qui serait, selon eux, du code "pro"... Ce qui m'a toujours fait marrer quand on passe en phase d'optimisation, d'ailleurs, car leur code "pro" y survit rarement.

    Citation Envoyé par koala01 Voir le message
    Partique, peut être, mais, encore une fois, à quel prix
    Au prix d'avoir un langage plus accessible et moins "élitiste" qu'il ne l'est actuellement... Ce qui n'est pas un mal : certains points du C++ sont franchement des usines à gaz.
    Pour ma part, j'ai toujours trouvé les prototypes des templates STL parfaitement infects et illisibles... Peut-être trouves-tu ça "expressif", mais moi, j'y vois seulement un magma infâme digne de l'IOCCC.
    Heureusement, il y a des choses pratiques dedans comme les ... opérateurs [] !

    Citation Envoyé par koala01 Voir le message
    Encore une fois, en centralisant plusieurs comportements fondamentalement différents en un seul terme, tu augmente le risque de voir apparaitre des contre sens ou des erreurs dues, essentiellement... à la mauvaise évaluation du sens à donner à ce terme dans une situation donnée
    C'est là que tu vois des comportements "différents" là où je n'en vois qu'un seul : gérer la taille du container.

    Citation Envoyé par koala01 Voir le message
    L'adaptation aux circonstances que tu permet au travers de propriétés (RW, je l'accorde), c'est d'avoir des comportements fondamentalement différents, et c'est là que repose le problème
    Tant que tu restes sur le principe "action hyper-élémentaire", effectivement, tu auras un souci avec ça. Il faut passer un cran au dessus pour bien comprendre les propriétés...

    Je dis cela sans méchanceté aucune, mais peut-être est-ce trop difficile de faire ce "saut" pour quelqu'un qui est trop ancré dans le C++ (ou le C). Pour ma part, j'ai appris la POO avec Pascal, puis Delphi, puis Java (très brièvement), et en dernier C++ : cela m'a permis de voir certains aspects vraiment intéressants de chaque langage, et surtout, les "manques" de chacun.

    Citation Envoyé par koala01 Voir le message
    Au niveau de la documentation à fournir, tu ne gagne pas grand chose à utiliser les propriétés, ne serait-ce que du seul fait que, si elles présentent deux comportement, tu devra quand meme documenter les deux comportements mis en oeuvre, et tu devra, en plus, indiquer dans quel cas tel ou tel comportement sera mis en oeuvre.
    Bien entendu. Mais je n'ai alors qu'UN SEUL point de documentation, et non pas N points avec l'obligation de créer des références manuellement entre eux... En effet, tu n'as souvent rien qui permette de lier automatiquement (par le code) ces entités : ça ne te choque pas ? Moi, si...

    Citation Envoyé par koala01 Voir le message
    et devoir me rappeler de... tous les cas d'utilisation
    Ce qui revient au même que de te rappeler de toutes les fonctions...

    Citation Envoyé par koala01 Voir le message
    Sans oublier, en plus que le simple fait d'écrire = au lieu de == risque de provoquer des catastrophes.
    C'est un manque grave de la grammaire, donc du langage, et non pas des propriétés... Et un réglage correct du compilateur permet de le détecter immédiatement. Argument non-recevable !

    Citation Envoyé par koala01 Voir le message
    Cela ne rend, effectivement, pas l'interface plus complexe, mais, encore une fois,à quel prix
    • Cela rend plus complexe le fait de déterminer exactement le comportement que l'on met en oeuvre en fonction du "contexte"
    • Cela risque d'entrainer des catastrophes si, d'aventure, on utilise le "mauvais contexte"
    • Cela ne rend pas forcément la lecture et la compréhension plus facile
    Je suis désolé, mais c'est un prix que je ne suis pas près à payer si je peux l'éviter...
    Le contexte est simplement le fait d'avoir une L ou une R-value... Faut pas abuser non plus, la propriété doit avoir un nom parlant comme tout identifiant (ex : "Size" et non pas "IO0Ol1"), et si tu tombes sur un développeur qui n'est pas capable de distinguer sa gauche de sa droite sur une affectation, conseilles-lui de se reconvertir dans l'élevage d'escargots.

    Citation Envoyé par koala01 Voir le message
    Ne t'en fais pas pour ca... je suis connu pour la longueur de mes posts
    J'ai ouï-dire qu'il en était de même pour moi...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  3. #263
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Léger HS, si ça continue, je splitterai la discussion...
    Citation Envoyé par Mac LAK Voir le message
    C++/CLI est là pour ça.
    Je ne suis pas vraiment d'accord. Il est là pour faire l'interface entre les deux mondes, ce qui est à des kilomètres de fournir une interface graphique utilisable en vrai C++.
    Et puis en plus, WPF ne supporte pas le C++/CLI. Ce dont je rêve c'est plus d'une biblitohèque en vrai C++ qui s'inspire des concepts de wpf, car eux sont intéressants (et demandent des propriétés pour être utilisable de manière à peu près fluide).
    Citation Envoyé par Mac LAK Voir le message
    Par contre, la barrière est plus lourde que tu ne le crois : tu ne peux attacher qu'un seul débugger à l'exécutable, soit en mode managé, soit en mode natif. Quand tu arrives au wrapping managé/natif (importation DLL ou appel vers le managé), ton debugger ne permet plus de tracer dans le source, hélas : il voit la fonction de "l'autre monde" comme quelque chose d'atomique, et ton debugger ne passe pas automatiquement du mode managé au mode natif et réciproquement.
    Très pénible quand on fait du debug de wrappers... OK, c'est un cas particulier, mais il se trouve que je suis passé en plein dedans pour avoir développé, justement, des interfaces C#/C++ générales (et générées).
    Je travaille depuis plusieurs années dans ce contexte, et je peux dire que ça ne pose pas de problème. Il suffit dans les options du projet C# de cocher Debug/Enable unmanaged code debuging, ou dans les options de projet C++ de sélectionner Debugging/Debugger type/Mixed.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  4. #264
    Invité
    Invité(e)
    Par défaut
    Oui, il faudrait une discussion "les propriétés encouragent elles les mauvais comportements ?" ou "Pour ou contre les accesseurs, la bataille finale".

  5. #265
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    Léger HS, si ça continue, je splitterai la discussion...
    Yep, ça pourrait être intéressant.

    Citation Envoyé par JolyLoic Voir le message
    Je ne suis pas vraiment d'accord. Il est là pour faire l'interface entre les deux mondes, ce qui est à des kilomètres de fournir une interface graphique utilisable en vrai C++.
    Certes, ce n'est pas du "vrai" C++, on est d'accord... Et ça t'oblige à écrire une IHM avec une partie réellement de présentation, et une partie fonctionnelle sous forme de DLL (d'un autre côté, on devrait toujours faire comme ça...).

    Citation Envoyé par JolyLoic Voir le message
    Et puis en plus, WPF ne supporte pas le C++/CLI. Ce dont je rêve c'est plus d'une biblitohèque en vrai C++ qui s'inspire des concepts de wpf, car eux sont intéressants (et demandent des propriétés pour être utilisable de manière à peu près fluide).
    Je vois mieux ce que tu veux dire...
    Pas gagné, regarde Borland et BCB : pour supporter la VCL, ils ont ajouté une extension au C++ pour, justement, permettre le concept de propriété... Souci : syntaxe C++ oblige, c'est (je trouve) plus "lourd" que l'équivalent Delphi, et ton code n'est plus du C++ compatible avec tous les compilateurs.

    Citation Envoyé par JolyLoic Voir le message
    Je travaille depuis plusieurs années dans ce contexte, et je peux dire que ça ne pose pas de problème. Il suffit dans les options du projet C# de cocher Debug/Enable unmanaged code debuging, ou dans les options de projet C++ de sélectionner Debugging/Debugger type/Mixed.
    Tiens, marrant, ça : le paramètre "Automatique" est donc trompeur... Il se résume à un choix définitif entre du debug managé et natif, alors qu'il aurait tendance à faire croire que le switch est automatique. De plus, sa position dans la liste laisse sous-entendre que c'est le réglage le plus "puissant", et il n'en est rien.

    Bon, je n'avais pas cherché trop loin non plus étant donné que j'avais de toutes façons deux systèmes de log de part et d'autre (prévus dans le fonctionnel), que j'avais donc utilisé pour ce debug, mais ça me permettra de virer le code de trace ou d'éviter d'en ajouter sur une nouvelle interface. Merci.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  6. #266
    screetch
    Invité(e)
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    ...
    on a globalement deux visions qui difèrent
    ta vision, c'est que le code doit être facile a ecrire
    ma vision, c'est que le code doit être facile a (re)lire

    dans ta vision, avoir 14 points d'entrée différent est pénalisant lors de l'écriture du code; besoin de vérifier la documentation, etc etc
    dans ma vision, avoir un même mot faisant plusieurs choses complique la relecture.

    toujours dans ma vision (j'espere qu'il y a assez de disclaimer) la relecture est bien plus importante que l'écriture, d'où l'interet (pour moi) d'ecrire des mots (et pas des symboles) qui ont un sens, et qui expliquent l'action devant être effectuée.
    L'indication de l'action, sa complexité et son comportement sont indiqués par de nombreux points, parfois c'est implicite et parfois c'est explicite.
    par exemple, je m'attends a ce que la fonction insert execute une insertion et rien d'autre. sa complexité n'est pas ecrit dans son nom mais plutot dans le type utilisé; si un map a une complexité en O(n2) je vais être un peu décontenancé.
    enfin, toujours dans ma vision, un accès raccourci a des fonctionnalités (comme une propriété, ou un operateur[]) obscurcissent le code source a la relecture.
    Car, dans mon esprit, la connaissance du fonctionnement d'un opérateur ou d'une propriété ou d'un raccourci ne devrait pas être un prérequis pour la compréhension du code qui l'utilise. Si je travaille dans une base de code de plusieurs milliers de fichiers, des millions de ligne de code, il m'est impossible de connaître par avance le fonctionnement de chaque fonction/opérateur/propriété. En revanche, si chaque fonction est suffisemment explicite (dns son nom) pour dire ce qu'elle fait (et donc ce qu'elle ne fait pas) je n'ai plus besoin d'aller lire sa documentation ou de l'apprendre par coeur.

    Ce dernier point, j'espère, tu n'auras pas l'audace de le contester. En revanche je comprend ton point de vue (a l'opposé du mien) qui revient a pouvoir ecrire du code et effectuer des actions avec du code de plus haut niveau.
    De mon point de vue (disclaimer...) le code est plus souvent relu qu'ecrit, et de plus il contient moins d'erreurs lorsqu'il est clair.

  7. #267
    screetch
    Invité(e)
    Par défaut
    oui j'ai bien compris. mais utiliser du code d'une bibliothèque c'est bien ecrire du code non ? (en en utilisant un autre)
    j'ai donc bien compris que ton code de bibliothèque doit rendre l'ecriture (des autres) plus simples.
    moi j'estime que le code doit être facile a relire et que pour cela, bien souvent, le plus simple est d'utiliser des interfaces elles-mêmes sobres et claires, quitte a rendre leur utilisation plus contraignante (du point de vue de l'ecriture)
    tu publies une interface pour les autres, les autres doivent relire leur code, ton interface fait donc partie de leur code. Lorsqu'ils reliront leur code, ils reliront ton interface, d'ou l'importance de ne pas aller verifier pour chaque fonction que tu as publié ce qu'elle fait "pour de vrai".

  8. #268
    Membre émérite
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 537
    Points : 2 548
    Points
    2 548
    Par défaut
    Je crois que vous vous égarez.

    En C++, on a tous un tas d'outils qui peuvent avoir de très mauvais usages, comme par exemple, en vrac :
    1/ Les pointeurs.
    2/ La gestion manuelle de la mémoire.
    3/ La surcharge d'opérateurs.
    4/ Le renvoie de référence d'objets locaux.

    Et bien d'autres.

    Et pourtant, je ne crois pas que quelqu'un ici veuille éliminer ces fonctionnalités. Je ne vois pas pourquoi la question devrait se poser pour les fonctionnalité ajoutées par D.

    Penser qu'un fonctionnalité n'est pas utile n'est pas une raison suffisant pour vouloir la supprimer du langage. Si vous pensez cela, alors C++ n'est définitivement pas pour vous, et vous devriez plutôt aller voir du coté des catégories C# ou Java du forum

  9. #269
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    C'est bien mieux qu'un accesseur, qui est quelque chose de quasiment impossible à empêcher / contrôler (ce n'est qu'une méthode, après tout !!!), tandis qu'une propriété a au moins le mérite d'être clairement identifiable, et potentiellement restreinte.
    Tu me dira bien comment tu restreint d'avantage une propriété (en dehors du fait quelle permet un acces en lecture, en écriture ou les deux) qu'un accessseur, qui, dans l'idéal, renvoie une valeur constante et est... une fonction constante...

    Dés le moment où tu expose une propriété, cela revient exactement au même que d'exposer l'accesseur, le mutateur ou le couple des deux sur... l'attribut concerné...
    T'inquiètes pas : ce genre de bestiau fait en général un accesseur et un mutateur en même temps que son attribut. C'est triste, mais c'est pourtant le cas... T'as pas idée du nombre de gens qui considèrent comme "obligatoire" d'avoir deux accesseurs (publics, bien sûr) pour CHAQUE attribut interne... Et qui te regardent comme un alien quand tu leur demande pourquoi ils ne virent pas leur fonction en mettant l'attribut public.
    Sans vouloir lancer un troll, ils sont en général issus de Java...
    Justement, si tu facilite les choses pour la création des deux, tu as tendance à les conforter dans l'idée que... c'est ce qu'il faut faire...

    Et donc, tu perd une possibilité de leur "apprendre" que ni l'un ni l'autre n'est d'office obligatoire.

    D'autant plus que, à bien y réfléchir, en gardant les deux clairement séparés, tu peux leur faire la remarque deux fois (on ne sait jamais, au cas où la première fois n'aurait pas été comprise )
    Yep, mais bon : t'as des garde-fous à ce niveau aussi... Relecture des specs / conceptions, documentation automatique et relecture de ladite doc (plus rapide et pratique que de relire le code), et bien sûr l'utilisation des classes en question.
    Tant que le code est "interne"...

    Tu as très rarement la certitude que ta bibliothèque sera correctement utilisée un fois qu'elle sera "diffusée"

    Le malheur veut qu'elle peut être utilisée aussi bien par des gens compétents et responsables que... par de véritables gorets...
    La même chose avec les attributs (mettre "public:" devant), les accesseurs triviaux (cf. horreur ci-dessus), etc.
    Ce que j'essaie de te faire comprendre, c'est qu'il n'est pas forcément nécessaire de donner à l'utilisateur (du code ou du langage) une corde supplémentaire pour se pendre...
    C'est pour ça que l'on a plein d'outils pour limiter la casse, à condition de les utiliser et de lire ce qu'ils nous disent.
    Bien sur, tu as les avertissement du compilateur...

    Encore faut il...
    • que la personne qui les lis ne se dise pas "bah, ce n'est qu'un avertissement"
    • que la personne qui décide de les prendre en compte soit en mesure de les comprendre, et, mieux encore, d'y apporter une solution
    Vous pouvez croire, à me lire, que j'ai une bien piètre opinion de mes "collègues", et je vous rassure: je sais qu'il y a de très bons programmeurs, à tous points de vue... Le malheur est, selon moi, que le pire côtoie régulièrement le meilleur dans la profession
    Au prix d'avoir un langage plus accessible et moins "élitiste" qu'il ne l'est actuellement... Ce qui n'est pas un mal : certains points du C++ sont franchement des usines à gaz.
    Je reconnais le coté usine à gaz de certains points du C++...

    Mais, crois tu réellement que c'est donnant un langage que d'aucuns pourraient considérer comme "simple" que nous améliorerons la qualité générale des applications, surtout de celles créées par le quidam moyen

    Je suis désolé, mais, pour ma part, j'ai l'impression que, plus on tente de faire passer la programmation pour une discipline facile ou aisée, plus on a de chances de voir y venir des gens incapables...

    J'ai, surement, l'air élitiste dans mes propos, mais, lorsque je voit le nombre de gens qui savent utiliser un edi ou un RAD, mais qui sont incapables de concevoir *correctement* une application ou une logique à mettre en oeuvre, je ne peux m'empêcher de penser qu'ils seraient surement plus efficace à planter des patates
    C'est là que tu vois des comportements "différents" là où je n'en vois qu'un seul : gérer la taille du container.
    Si ce n'est que tu n'utilise pas la granularité suffisante dans ce terme:

    Les comportements sont:
    • d'un coté, permettre à l'utilisateur de connaitre la taille
    • de l'autre, permettre à l'utilisateur de modifier la taille

    Tant que tu restes sur le principe "action hyper-élémentaire", effectivement, tu auras un souci avec ça. Il faut passer un cran au dessus pour bien comprendre les propriétés...

    Je dis cela sans méchanceté aucune, mais peut-être est-ce trop difficile de faire ce "saut" pour quelqu'un qui est trop ancré dans le C++ (ou le C). Pour ma part, j'ai appris la POO avec Pascal, puis Delphi, puis Java (très brièvement), et en dernier C++ : cela m'a permis de voir certains aspects vraiment intéressants de chaque langage, et surtout, les "manques" de chacun.
    Et je connais suffisemment les langages que tu cites pour savoir que ces aspects qui représentent, selon toi, un manque, sont en fait les outils tous trouvés pour assister à un "nivellement vers le bas", permettant aux programmeur de ne pas se poser certaines questions pourtant primordiales pour la qualité de l'application
    Bien entendu. Mais je n'ai alors qu'UN SEUL point de documentation, et non pas N points avec l'obligation de créer des références manuellement entre eux... En effet, tu n'as souvent rien qui permette de lier automatiquement (par le code) ces entités : ça ne te choque pas ? Moi, si...
    Pourquoi faudrait il lier automatiquement plusieurs fonctions dans la documentation
    Ce qui revient au même que de te rappeler de toutes les fonctions...
    Je suis désolé, mais non...

    Si tu as un certain nombre de fonctions dont les noms sont explicites, tu sais, en permanence l'action qu'aura une fonction donnée...

    En multipliant les comportements "en fonction des circonstances ou du contexte" qu'aura un terme donné, tu multiplie le risque de... choisir le mauvais contexte...
    Le contexte est simplement le fait d'avoir une L ou une R-value... Faut pas abuser non plus, la propriété doit avoir un nom parlant comme tout identifiant (ex : "Size" et non pas "IO0Ol1"), et si tu tombes sur un développeur qui n'est pas capable de distinguer sa gauche de sa droite sur une affectation, conseilles-lui de se reconvertir dans l'élevage d'escargots.
    Si ce n'est que, encore une fois, l'instruction qui utilise la propriété risque d'être "noyée" parmi un tas d'autre lignes de code...

    Si, à un moment, tu lis un resize(), dans un code, alors que toutes les lignes précédentes te font penser que tu manipule une collection en lecture seule, tu va, immanquablement, te poser des question.

    Si, à l'occasion d'une lecture "un peu trop rapide", tu rencontre une propriété size dans les mêmes conditions, tu n'aura *pas forcément* le réflèxe de vérifier s'il se trouve à gauche ou à droite "d'un unique caractère" (noyé parmi d'autre, pour t'assurer que c'est bel et bien un acces "en lecture" et non un acces "en écriture" qui est effectué

    J'ai ouï-dire qu'il en était de même pour moi... [/QUOTE]

    Citation Envoyé par Mac LAK Voir le message
    Ce qui n'est pas le cas, par exemple, de resize qui (je le rappelle) sous-entends que l'on RE-alloue la taille... De quelle manière ? Absolue ? Relative ? Que se passe-t'il au premier appel ? Quel est l'état initial ?
    Basiquement, on s'en fout... A condition de mettre en oeuvre les *bons* principes (RAII en tête):

    De deux choses l'une:

    Soit, tu viens de créer ta collection (comprenons nous sur le terme: tu l'a créé dans la fonction dans laquelle tu souhaite appeler resize ) , et tu y a, éventuellement ajouté un certains nombre d'éléments... Tu *sais* donc, en fonction des instructions qui séparent la construction de la collection de l'invocation de resize(); ce que la collection contient

    Soit, la dite collection est créée "par ailleurs" et passée en argument (ou membre d'une classe plus complexe), et, quoi qu'il en soit, si tu as décidé qu'il ne devait y avoir que N éléments, il n'y en aura ni plus, ni moins...

    C'est pour cette raison qu'il est largement préférable de faire en sorte que la taille s'adapte automatiquement sur certains comportements utilisables par ailleurs tels que l'ajout, la suppression ou la "vidange", quitte à permettre par ailleurs de définir une taille arbitraire (opération qui échoit à... resize() )...
    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

  10. #270
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Tu me dira bien comment tu restreint d'avantage une propriété (en dehors du fait quelle permet un acces en lecture, en écriture ou les deux) qu'un accesseur, qui, dans l'idéal, renvoie une valeur constante et est... une fonction constante...
    La propriété est une fonction (où plutôt une ou deux fonctions) qui a pour particularité d'être appelée avec une syntaxe d'affectation.
    Elle ne correspond pas forcément à un attribut, et peut tout à fait être const ou renvoyer un objet const...

    Je ne voudrais pas que tu crois que le D encourage par design une certaine facilité et une mauvaise conception.

    Les propriétés, et tu as raison, encouragent à créer plus d'accesseurs puisque c'est plus facile. Tu n'aimes pas, ok. Généralement ce qu'on dit à quelqu'un qui n'aime pas une feature de C++ c'est "tu n'es pas obligé de l'utiliser".

    Les gens qui trouvaient que les propriétés avaient trop d'inconvénients ont d'ailleurs obtenu que l'annotation @property soit obligatoire. Ce n'est donc plus implicite comme avant.

    Mais il ne faut pas jeter le bébé avec l'eau du bain.

    Il faut savoir que Walter Bright,à cause de son passé chez Boeing, a une sensibilité particulière pour la sureté d'un langage et les vies que ca peut sauver.
    Il a pour objectif de faire de D un langage beaucoup plus safe, voire facile a vérifier automatiquement avec de l'analyse statique.

    Aussi chaque décision est prise à la lueur de ce que tu viens de dire : le programmeur moyen est... moyen, et ne mérite pas qu'on lui accorde une pleine confiance - sans toutefois l'émasculer. Il a donc le droit de faire n'importe quoi, mais pas dans un subset "safe" du langage qu'il active là où il veut.

    La safety correspond de fait à un certain nombre de features:

    - les tests unitaires intégré, contrats : c'est plus facile, donc ca encourage à en faire
    - les attributs @safe, @trusted et @disable dans D2
    - la const-correctness de D2 beaucoup plus systématique, qu'on a pas tendance à éviter (ce qui pose d'ailleurs des problèmes de verbosité...)
    - l'alias this encourage la composition sur l'héritage...
    - le compilateur repère des cas d'erreurs comme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (condition);
    {
       ...
    }
    entre autres joyeusetés.

  11. #271
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    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 898
    Points : 7 752
    Points
    7 752
    Par défaut
    En work in progress

    Le D-IDE
    http://d-ide.sourceforge.net/

    Ca pourrait être un point de départ pour développer une communauté autour de ce langage. Un langage, même excellent, sans véritable outil de développement, est une cause perdue.

  12. #272
    Invité
    Invité(e)
    Par défaut
    Oui enfin il y en a pas mal en "work in progress". Le vrai problème est plutôt de pouvoir utiliser un débugger sous Windows.

    Perso je suis sous Codeblocks, mais il faut debugger autrement

  13. #273
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    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 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Genre ton debugger c'est printf?

  14. #274
    Invité
    Invité(e)
    Par défaut

  15. #275
    Membre émérite
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 537
    Points : 2 548
    Points
    2 548
    Par défaut
    Avec code::block + gdb sous linusque, tout marche impeccable chez moi. Le debug se fait bien.

  16. #276
    Membre éclairé

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

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Aucun problème pour débugguer sous linux.
    Pour développer, j'utilise JEdit + gdb + Scons pour le build.
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

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

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

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Hop je remonte ce thread parceque The D Programming Language: Amazon.fr: Andrei Alexandrescu: Livres en anglais@@AMEPARAM@@http://ecx.images-amazon.com/images/I/41-Go5vQ-WL.@@AMEPARAM@@41-Go5vQ-WL sur D va arriver chez moi aujourd'hui ou demain et qu'il semblerait qu'il devienne plus ou moins le bouquin référence pour l'ensemble de la communauté (que je ne suis pas mais le language m'interesse).

    Avec un peu de chance (pour ce language), il y aura une vrai spécification dans quelques temps.

  18. #278
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Ouai j'ai vu qu'il était sorti et en effet c'est LE bouquin qui va faire référence. (du pur Alexandrescu dans le texte).
    Ma to-read-list est trop longue pour l'instant mais dans un futur pas très proche je pense que je me le prendrais car y'a définitivement des trucs très intéressant dans ce langage.
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

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

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

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Je n'ai pas fini de lire le livre (j'ai un livre sur l'histoire du jeu vidéo du point de vue sociétées et personnes à finir) mais j'ai remarqué que le site officiel a une nouvelle page de description plus claire et plus rapide a lire que le livre : http://www.digitalmars.com/d/2.0/overview.html

    Les concepts repris et non-repris du C++ sont clairement listés donc c'est facile de mieux comprendre a quoi s'en tenir.

    Hmm je pense que je tenterai un prototype de petit jeu dans ce language l'année prochaine, histoire de voir...


    edit> Tiens il y a même une page de comparaison avec C++0x : http://www.digitalmars.com/d/2.0/cpp0x.html


    Personellement, l'absence de séparation déclaration/définition m'ennuie. J'ai pratiqué du Java, de l'ActionScript, du C# etc. et ça me choque toujours d'avoir a parcourir du code effectif juste pour repérer des noms de fonctions. Partir du principe qu'on va toujours utiliser un éditeur (supposé en Java et C#) est particulièrement naïf je trouve.

  20. #280
    Membre éclairé
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Septembre 2008
    Messages : 680
    Points : 858
    Points
    858
    Par défaut
    Merci pour le lien Klaim, je vais aller me lire ça.

    Ça commence à être utilisé dans l'industrie, le D ?
    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.

Discussions similaires

  1. [langage] Je cherche un bon livre ?
    Par Anonymous dans le forum Langage
    Réponses: 13
    Dernier message: 09/04/2003, 14h16
  2. [langage] Comparer Perl avec d'autres langages comme C ?
    Par Anonymous dans le forum Langage
    Réponses: 3
    Dernier message: 11/08/2002, 00h52
  3. [langage] comment créer des fichiers ?
    Par Anonymous dans le forum Langage
    Réponses: 3
    Dernier message: 05/05/2002, 17h33
  4. Comparer des fichiers de données : Quel Langage ?
    Par Anonymous dans le forum Langages de programmation
    Réponses: 6
    Dernier message: 24/04/2002, 23h37
  5. Cours, tutoriels, logiciels, F.A.Q,... pour le langage SQL
    Par Marc Lussac dans le forum Langage SQL
    Réponses: 0
    Dernier message: 04/04/2002, 11h21

Partager

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