Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 10 sur 16 PremièrePremière ... 67891011121314 ... DernièreDernière
Affichage des résultats 181 à 200 sur 307

Discussion: Le langage D

  1. #181
    Rédacteur/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 672
    Points
    11 672

    Par défaut

    Citation Envoyé par Klaim Voir le message
    - CTFE

    Tu peux préciser stp? Je connais pas cet acronyme...
    Compile Time Function Execution
    Cf : La métaprogrammation en C++

    Citation Envoyé par Klaim Voir le message
    - 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.
    Je suis aussi très dubitatif avec cette feature.
    Citation Envoyé par Klaim Voir le message
    - 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.
    Boost.Typeof en attendant

    Citation Envoyé par Klaim Voir le message

    - 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... ?
    J'avoue que je ne comprends pas trop non plus. Force de l'habitude ? Peut être, mais j'avoue aimer pouvoir séparer la déclaration dans un fichier d'en-tête de l'implémentation dans un fichier source.

  2. #182
    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 Klaim Voir le message
    Tu peux préciser stp? Je connais pas cet acronyme...
    Pouvoir exécuter une fonction à la compilation.
    Par exemple: const a = sin(1.5); // a est connue à la compil

    Citation Envoyé par Klaim Voir le message
    - arrays ops
    Je ne suis pas sur de comprendre non plsu ce que tu entends par là?
    Les arrays op potentiellement permettent de vectoriser une boucle.
    Code :
    1
    2
    3
     
    float[] a, b, c;
    a[] = b[] + c[] * 2.f;
    Ce qu'on peut faire en mieux en C++ avec des expressions templates, pour être honnête (Eigen).

    Citation Envoyé par Klaim Voir le message
    - 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?
    Disons que les tableaux dynamiques de D sont des std::vector builtins d'où un gain en expressivité au prix de la généricité.

    Citation Envoyé par Klaim Voir le message
    - 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.
    C'est sans doute une histoire de goûts, moi je ne peux pas m'en passer. Même si Delphi avait mieux compris les propriétés je trouve.

    Citation Envoyé par Klaim Voir le message
    - 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).
    Cf plus bas.


    Citation Envoyé par Klaim Voir le message
    - 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.
    Oui je sais, c'est pour ca que j'ai précisé "aujourd'hui". (C'est d'ailleurs les features les plus faciles à implémenter de C++0x qui sont venues en premier.)

    Citation Envoyé par Klaim Voir le message
    - nested functions

    Possibles a partir de C++0x via les lambda.
    Exact, mais C++0x n'est pas encore là. Les lambdas C++, c'est une très bonne nouvelle mais je n'aime pas l'idée de spécifier quoi mettre dans la closure manuellement.

    Citation Envoyé par Klaim Voir le message
    - 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... ?
    En pratique, j'ai des types communs à mes différents cpp et je n'ai jamais codé dans un projet où ca n'arrivait pas. Mais ca m'intéresse si on peut baisser ce couplage.

    Citation Envoyé par Klaim Voir le message
    - constexpr ("const")
    Ca arrive avec C++0x
    On dit C++1x

    Citation Envoyé par Klaim Voir le message
    - 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?
    En pratique, tu as besoin du préprocesseur même en ne ciblant qu'une plateforme et qu'un compilateur. Préprocesseur => pas d'auto-complétion fiable et en temps borné (je le constate tous les jours avec VS2008).

    Citation Envoyé par Klaim Voir le message
    - 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.
    Il me semble que Google a compris cela quand ils ont marketé leur langage Go (que je n'aime pas par ailleurs).

    Un système de module en C++ nécessiterait d'exporter des templates, or c'est dur à faire. Ca m'étonnerait que ca vienne dans le compilateur de Microsoft par exemple...

    En D, un template n'a pas besoin d'être dans chaque "translation unit".
    Le D, c'est comme si une partie de Boost était dans le langage. Pas besoin d'attendre trois plombes que ca compile.

  3. #183
    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 ponce Voir le message
    Pouvoir exécuter une fonction à la compilation.
    Par exemple: const a = sin(1.5); // a est connue à la compil
    Comme l'a fait remarquer 3DArchi, c'est possible avec la méta programmation, même s'il faut avouer que ce n'est (comme tout ce qui touche à la méta prog un "peu poussée") pas *forcément* tres instinctif comme manière d'envisager les choses
    Les arrays op potentiellement permettent de vectoriser une boucle.
    Code :
    1
    2
    3
     
    float[] a, b, c;
    a[] = b[] + c[] * 2.f;
    Ce qu'on peut faire en C++ avec des expressions templates.
    Là aussi, avec la méta programmation, c'est possible, avec la même remarque que plus haut

    Disons que les tableaux dynamiques de D sont des std::vector builtins d'où un gain en expressivité au prix de la généricité.
    C'est sans doute une histoire de goûts, moi je ne peux pas m'en passer.
    C'est sans doute (surement) que tu as têté à la tétine des propriétés avant d'avoir assimilé les concepts plus ou moins immuables de la programmation OO...

    Le concept de propriété est fondamentalement en désaccord avec des règles de POO qui sont souvent, et parfois volontairement, mal interprétées ou passées sous silence par certains langages.

    Je pense, entre autres, à la loi demeter
    Oui je sais, c'est pour ca que j'ai précisé "aujourd'hui".
    Sauf que, même si C++0x (C++1x maintenant), c'est... aujourd'hui, même si la norme n'est pas tout à fait finalisée

    Comme l'ont si bien fait remarquer plusieurs personnes, la plupart des compilateurs actuels implémentent déjà une bonne partie des features de la prochaine norme
    Exact, mais C++0x n'est pas là. Les lambdas C++ c'est une bonne nouvelle mais je n'aime pas l'idée de spécifier quoi mettre dans la closure manuellement.
    Encore une fois, elle a beau ne pas être totalement finalisée, la nouvelle norme est déjà bel et bien là, et rien ne t'empêche, dés à présent, de la respecter dans ton code
    En pratique, tu as besoin du préprocesseur même en ne ciblant qu'une plateforme et qu'un compilateur. Préprocesseur => pas d'auto-complétion fiable et en temps borné (je le constate tous les jours avec VS2008).
    Absoluement pas...

    L'auto-complétion n'est jamais qu'une "facilité fournie" par le traitement de texte intégré à ton environnement de développement...

    Le préprocesseur n'est qu'une étape de la compilation qui applique des macros...

    Si tu n'utilise pas les macros du préprocesseur, tu peux parfaitement t'en passer

    Si un EDI donné a besoin du préprocesseur pour permettre l'auto-complétion, j'aurais presque tendance à dire qu'il est beaucoup trop couplé avec le compilateur
    Il me semble que Google a compris cela quand ils ont marketé leur langage Go (que je n'aime pas par ailleurs).

    Un système de module en C++ nécessiterait d'exporter des templates, or c'est dur à faire. Ca m'étonnerait que ca vienne dans le compilateur de Microsoft par exemple...

    En D, un template n'a pas besoin d'être dans chaque "translation unit".
    En D, c'est comme si une partie de Boost était dans le langage. Pas besoin d'attendre trois plombes que ca compile.
    C'est à quoi servent, entre autres, les en-têtes précompilées et les bibliothèques

    La notion de module est utilisé en quasi permanence chaque fois que tu utilise une bibliothèque externe, que ce soit soit la forme d'une bibliothèque statique ou dynamique...

    Maintenant, rien ne t'empêche d'appliquer un raisonnement fort similaire pour tes propres développements, et de "modulariser" ton projet de manière à... créer des bibliothèques qui soient le plus indépendantes les unes des autres...

    Evidemment, il faut avouer que cela demande un peu plus d'effort de conception, mais qui oserait prétendre que l'on crée une application comme on écrit une lettre à sa douce
    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. #184
    screetch
    Invité(e)

    Par défaut

    il ne faudrait pas non plus confondre la finalité avec les outils
    "pouvoir tout faire" en C++ (même si je ne crois pas que ca soit vrai) voudrait plus dire selon moi que l'on peut réaliser tout type de programme avec les outils dont on dispose
    tandis que vous listez tous les outils dont D dispose, ce qui ne dit pas si on peut faire "plus de choses".

  5. #185
    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

    +1 avec screetch... surtout que si on part par là, le C++ est turing complet, donnc il peut " tout faire"... Tout comme le BF
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  6. #186
    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 koala01 Voir le message
    Comme l'a fait remarquer 3DArchi, c'est possible avec la méta programmation, même s'il faut avouer que ce n'est (comme tout ce qui touche à la méta prog un "peu poussée") pas *forcément* tres instinctif comme manière d'envisager les choses
    Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.

    Citation Envoyé par koala01 Voir le message
    C'est sans doute (surement) que tu as têté à la tétine des propriétés avant d'avoir assimilé les concepts plus ou moins immuables de la programmation OO...
    C'est gentil de me prendre de haut mais merci je sais programmer objet... les propriétés, c'est une autre manière d'écrire des getters et setters. Ni plus, ni moins.

    Citation Envoyé par koala01 Voir le message
    Le concept de propriété est fondamentalement en désaccord avec des règles de POO qui sont souvent, et parfois volontairement, mal interprétées ou passées sous silence par certains langages.

    Je pense, entre autres, à la loi demeter
    Les propriétés ne violent pas l'encapsulation. C'est une autre syntaxe pour appeler une méthode, point barre. J'ai même vu des cas où ca permettait de remplacer un champ par une méthode où vice-versa de manière transparente (donc augmenter l'encapsulation).

    Citation Envoyé par koala01 Voir le message
    Comme l'ont si bien fait remarquer plusieurs personnes, la plupart des compilateurs actuels implémentent déjà une bonne partie des features de la prochaine norme
    La partie la plus facile. La CTFE c'est une très grosse partie.

    Citation Envoyé par koala01 Voir le message
    Encore une fois, elle a beau ne pas être totalement finalisée, la nouvelle norme est déjà bel et bien là, et rien ne t'empêche, dés à présent, de la respecter dans ton code
    Merci mais j'ai des clients qui attendent, je vais pas coder pour une norme pas finie.

    Citation Envoyé par koala01 Voir le message
    Si tu n'utilise pas les macros du préprocesseur, tu peux parfaitement t'en passer
    Non tu ne peux pas t'en passer en C++.
    Cite moi un programme réel sans macros et sans #ifdef

    Citation Envoyé par koala01 Voir le message
    Si un EDI donné a besoin du préprocesseur pour permettre l'auto-complétion, j'aurais presque tendance à dire qu'il est beaucoup trop couplé avec le compilateur
    C'est pourtant ce qui arrive quand parser un fichier nécessite toute la chaîne de compilation.

    Citation Envoyé par koala01 Voir le message
    La notion de module est utilisé en quasi permanence chaque fois que tu utilise une bibliothèque externe, que ce soit soit la forme d'une bibliothèque statique ou dynamique...

    Maintenant, rien ne t'empêche d'appliquer un raisonnement fort similaire pour tes propres développements, et de "modulariser" ton projet de manière à... créer des bibliothèques qui soient le plus indépendantes les unes des autres...

    Evidemment, il faut avouer que cela demande un peu plus d'effort de conception, mais qui oserait prétendre que l'on crée une application comme on écrit une lettre à sa douce
    Ah les joies de faire des librairies dynamiques en C++... Pas étonnant que les gens s'en tiennent à une interface C.

  7. #187
    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
    tandis que vous listez tous les outils dont D dispose, ce qui ne dit pas si on peut faire "plus de choses".
    A mon avis on ne peut strictement rien faire de plus.
    EDIT: Mais surtout, il ne fait pas moins comme tous les autres langages proposés comme "remplacement".

    Je cherche juste à répondre aux contre-vérités, pas à inciter qui que ce soit à programmer en D (il faut être un peu maso).

  8. #188
    Rédacteur/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 672
    Points
    11 672

    Par défaut

    Citation Envoyé par ponce Voir le message
    Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.
    A priori, avec son développement polynomial si mes souvenirs mathématiques sont bons

  9. #189
    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 3DArchi Voir le message
    A priori, avec son développement polynomial si mes souvenirs mathématiques sont bons
    Exactement, j'avais lu un article là-dessus où ils faisaient ca.

    Sauf qu'un développement de Taylor comme ca, non seulement ca converge lentement mais ca ne marche bien qu'autour de zero. Donc ce n'est pas comme si "on pouvait faire ca en méta-programmation".

    Si j'ai envie de calculer ca à la compilation en C++:
    Code :
    1
    2
     
    sqrt(cos(exp(1) * atan(1.0) * 4.0));
    Je vais probablement prendre la calculette plutôt que de calculer la dérivée n-ième (où laisser tomber et faire ca à l'exécution ).

  10. #190
    Rédacteur/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 672
    Points
    11 672

    Par défaut

    Visual (donc hors du langage en lui même) propose les intrinsic, c'est à dire qu'il t'inline le code de fonctions comme sin, cos, etc. à la place de l'appel.

  11. #191
    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 ponce Voir le message
    Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.
    En utilisant les règles des séries...

    Je crois d'ailleurs que ce point est expliqué dans l'article sur la méta programmation déjà cité par 3D

    C'est gentil de me prendre de haut mais merci je sais programmer objet... les propriétés, c'est une autre manière d'écrire des getters et setters. Ni plus, ni moins.
    Je ne voulais absolument pas te prendre de haut, et je te fais mes plus humbles excuses si c'est l'impression que je t'ai donnée.

    Ce que je voulais exprimer, c'est que tu as sans doute trop pris l'habitude des propriétés pour te rendre compte que le concept lui-même est sujet à caution, entre autre à cause de demeter.

    Et comme les habitudes prises "au bibron" (comprend: quand on débute) sont les plus tenaces...
    Les propriétés ne violent pas l'encapsulation. C'est une autre syntaxe pour appeler une méthode, point barre. J'ai même vu des cas où ca permettait de remplacer un champ par une méthode où vice-versa de manière transparente (donc augmenter l'encapsulation).
    Tu me confirme ici que tu as une vision déformée de la loi demeter...

    S'il est vrai que le concept d'encapsulation est une des composantes de demeter, ce n'est absolument pas le seul point de vue qu'elle aborde.

    De plus, tu sembles croire que le seul but de l'encapsulation est... de cacher le contenu d'un objet, et, là encore, ce n'est pas le cas.

    Si tu place un accesseur ou pire, un mutateur sur le membre d'une classe, il ne sert souvent pas à grand chose de le placer en visibilité privée pour *soi disant* l'encapsuler...

    Demeter dit que, si une classe B utilise (a comme membre un objet du type) une classe C, et que, si une classe A utilise un objet dont le type est un B, la classe A ne devrait absolument rien connaitre... du type C.

    Si tu crée une fonction qui renvoit... (une référence sur) un objet de type C, et, pire, si tu manipule depuis ton objet de type A (la référence sur)l'objet de type C renvoyé par ton objet de type B, tu crées une dépendance très forte de ta classe A vis à vis de... la classe C, alors que la seule dépendance réellement subie par la classe A devrait être vis à vis de... B

    L'idée poursuivie par l'encapsulation est de réfléchir d'une manière proche de
    Je dispose d'un type B qui me fournit l'ensemble des comportements qui me permettent de le gérer sans avoir à m'inquiéter des "détails d'implémentation".

    Si B est, entre autres, composé d'un membre de type C, aucun des comportements de B ne doit laisser transparaitre ce fait.

    Si une classe A utilise le type B, je fais simplement appel aux comportements de B, et cela me suffit: je n'ai a priori aucun besoin de récupérer le C dans une fonction de A.

    Dans l'absolu, je dois pouvoir utiliser une instance de type B dans une fonction de A sans même avoir à m'inquiéter du fait qu'il existe un type C qui est utilisé par B
    La partie la plus facile. La CTFE c'est une très grosse partie.
    Comme on l'a déjà fait remarquer, cela existe depuis très longtemps, même si cela passe par des traits ou des politiques, et même s'il faut avouer que leur mise en oeuvre n'est pas forcément "instinctive"

    Merci mais j'ai des clients qui attendent, je vais pas coder pour une norme pas finie.
    Et pourtant...

    Si tu ose "prendre le pari" de déjà utiliser les possibilités de la prochaine norme, quitte à ce que cela se fasse à coup de compilation conditionnelle, tu te mets en bonne position pour réagir rapidement aux évolutions futures...

    En effet, une fois que la norme sera finalisée et appliquée, il te suffira d'une option de compilation pour être en mesure... de profiter de ses avantages, et, pourquoi pas, de supprimer toute une partie du code qui serait moins efficace.

    Cela prend, certes, plus de temps aujourd'hui, mais c'est, très certainement, de nature à t'en faire gagner énormément par la suite...

    Sur le court terme, cela ne changera pas grand chose du fait que cela ne te prend que quelques minutes de prendre les deux situations en compte au moment même, mais, sur le long terme, cela te fait gagner un temps précieux parce que tu t'économise le temps important que pourrait nécessiter le fait de tout reprendre (avec les problèmes de refactoring que cela implique) pour adapter ton code à la nouvelle norme
    Non tu ne peux pas t'en passer en C++.
    Cite moi un programme réel sans macros et sans #ifdef
    Dans mes codes, je ne les utilise que comme garde contre les inclusions multiples, ou, comme je viens d'en parler, lorsque je souhaite anticiper sur la prochaine norme...
    C'est pourtant ce qui arrive quand parser un fichier nécessite toute la chaîne de compilation.
    Si ton éditeur de texte nécessite de passer toute la chaine de compilation en revue pour te fournir l'auto complétion, c'est que, quelque part, il y a un sérieux problème, tu ne crois pas
    Ah les joies de faire des librairies dynamiques en C++... Pas étonnant que les gens s'en tiennent à une interface C.
    Le problème des bibliothèques dynamique du C++ vient principalement du fait qu'il n'y a pas (encore) d'abi standardisée pour celui-ci (mais il me semble que c'est un des points sur lequel se concentre la nouvelle norme)...

    Et puis, il n'y a pas que les bibliothèques dynamiques, dans la vie... le bibliothèques statiques ont pas mal de choses à nous apporter, surtout lorsqu'il s'agit de modulariser un projet
    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

  12. #192
    screetch
    Invité(e)

    Par défaut

    les flottants et doubles ne sont pas supportés par les templates C++.
    la raison est que le code est généré sur une machine A et éxécuté sur une machine B qui pourraient donner des résultats différents, donc le code flottant doit être calculé et non inliné.
    sinon il faut un compilateur capable d'émuler l'architecture cible, mais là encore, quid des exceptions de virgule flottante?

  13. #193
    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 koala01 Voir le message
    Tu me confirme ici que tu as une vision déformée de la loi demeter...

    S'il est vrai que le concept d'encapsulation est une des composantes de demeter, ce n'est absolument pas le seul point de vue qu'elle aborde.

    De plus, tu sembles croire que le seul but de l'encapsulation est... de cacher le contenu d'un objet, et, là encore, ce n'est pas le cas.

    Si tu place un accesseur ou pire, un mutateur sur le membre d'une classe, il ne sert souvent pas à grand chose de le placer en visibilité privée pour *soi disant* l'encapsuler...

    Demeter dit que, si une classe B utilise (a comme membre un objet du type) une classe C, et que, si une classe A utilise un objet dont le type est un B, la classe A ne devrait absolument rien connaitre... du type C.

    Si tu crée une fonction qui renvoit... (une référence sur) un objet de type C, et, pire, si tu manipule depuis ton objet de type A (la référence sur)l'objet de type C renvoyé par ton objet de type B, tu crées une dépendance très forte de ta classe A vis à vis de... la classe C, alors que la seule dépendance réellement subie par la classe A devrait être vis à vis de... B
    Dans ce cas-là j'ai tendance à utiliser la délégation dans mon objet B pour que A ne le manipule pas. J'ai mis du temps à apprendre ça effectivement mais je ne pense plus faire l'erreur.


    A mon avis proposer un getter ou setter alors qu'on ne devrait pas (ie. violer Demeter) est orthogonal avec le fait d'utiliser ou non des propriétés, qui sont du sucre syntaxique autour (ou alors tu penses qu'on a jamais besoin de getter ?).

    Il y a pire, j'ai vu un langage où chaque définition de champ définissait un getter et un setter automatiquement

    Le problème des bibliothèques dynamique du C++ vient principalement du fait qu'il n'y a pas (encore) d'abi standardisée pour celui-ci (mais il me semble que c'est un des points sur lequel se concentre la nouvelle norme)...
    J'avoue que c'est la feature qui me plait le plus dans la norme qui vient.

  14. #194
    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
    les flottants et doubles ne sont pas supportés par les templates C++.
    la raison est que le code est généré sur une machine A et éxécuté sur une machine B qui pourraient donner des résultats différents, donc le code flottant doit être calculé et non inliné.
    sinon il faut un compilateur capable d'émuler l'architecture cible, mais là encore, quid des exceptions de virgule flottante?
    C'est effectivement un vrai casse-tête. Par exemple le code flottant ne s'exécute pas exactement pareil à la compilation et à l'exécution en D (plus de précision à la compilation).

  15. #195
    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 ponce Voir le message
    Dans ce cas-là j'ai tendance à utiliser la délégation dans mon objet B pour que A ne le manipule pas. J'ai mis du temps à apprendre ça effectivement mais je ne pense plus faire l'erreur.


    A mon avis proposer un getter ou setter alors qu'on ne devrait pas (ie. violer Demeter) est orthogonal avec le fait d'utiliser ou non des propriétés, qui sont du sucre syntaxique autour
    Justement, c'est tout le noeud du problème...

    Les propriétés n'étant, comme tu le fais remarquer, qu'un "sucre syntaxique" remplaçant les mutateur et accesseurs, tu est tenté de déclarer "propriété" (avec les accesseurs et mutateurs que le terme induit) quelque chose qui... ne devrait pas l'être...
    (ou alors tu penses qu'on a jamais besoin de getter ?).
    Je pense, en tout cas, que l'on en a besoin suffisemment rarement pour y réfléchir à deux fois avant de décider d'en placer un, c'est certain

    Et, si j'admets encore "assez facilement" (alors que tu auras remarqué que je ne suis pas leur meilleur partisan) l'usage d'accesseurs, j'ai, toutes proportions gardées, encore beaucoup plus de mal à admettre les mutateurs.

    Or, si tu fournis un mécanisme qui tend à simplifier la mise en oeuvre de comportement qui devraient rester exceptionnels, tu incite de facto à la généralisation de l'utilisation de ces comportements.

    Et c'est en cela que j'ai énormément de mal à accepter le concept de propriété.

    Il y a pire, j'ai vu un langage où chaque définition de champ définissait un getter et un setter automatiquement
    Effectivement, c'est assez choquant de leur part
    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

  16. #196
    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 koala01 Voir le message
    Justement, c'est tout le noeud du problème...

    Les propriétés n'étant, comme tu le fais remarquer, qu'un "sucre syntaxique" remplaçant les mutateur et accesseurs, tu est tenté de déclarer "propriété" (avec les accesseurs et mutateurs que le terme induit) quelque chose qui... ne devrait pas l'être...
    Je pense, en tout cas, que l'on en a besoin suffisemment rarement pour y réfléchir à deux fois avant de décider d'en placer un, c'est certain
    C'est vrai que ca risque de banaliser la chose... et ca n'encourage pas à faire émerger une interface claire. Je comprends mieux ce que tu voulais dire.

    Citation Envoyé par koala01 Voir le message
    Et, si j'admets encore "assez facilement" (alors que tu auras remarqué que je ne suis pas leur meilleur partisan) l'usage d'accesseurs, j'ai, toutes proportions gardées, encore beaucoup plus de mal à admettre les mutateurs.
    Je les utilise énormément... particulièrement avec les libraries qui maintiennent un état. C'est certain que ca poserait des problèmes sur des projets plus gros avec beaucoup de personnes

    Cela dit, c'est une question de balance entre faire vite et faire bien ; on peut aussi s'en tenir à des conventions qu'on essaye de garder.

    Citation Envoyé par koala01 Voir le message
    Or, si tu fournis un mécanisme qui tend à simplifier la mise en oeuvre de comportement qui devraient rester exceptionnels, tu incite de facto à la généralisation de l'utilisation de ces comportements.
    Tout à fait d'accord. Je trouve d'ailleurs que le C++ est rempli de tels "pièges".

    Citation Envoyé par koala01 Voir le message
    Et c'est en cela que j'ai énormément de mal à accepter le concept de propriété.
    Je suis près à prendre ce risque contre un peu de productivité. Je ne trouve pas que ca soit si problématique en fait.

    Quelque part le C++ vient avec l'assertion que chaque partie du code sera réutilisé. De mon côté, j'écris beaucoup de code jetable qui n'aura que quelques utilisations seulement.

    (EDIT: la philosophie du C++ est aussi de faire confiance au programmeur ; libre à lui de se tirer une balle dans le pied, non ?)

  17. #197
    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 ponce Voir le message
    Je suis près à prendre ce risque contre un peu de productivité. Je ne trouve pas que ca soit si problématique en fait.
    Je préférerais personnellement perdre un peu de temps à assurer une conception correcte...

    Le temps passé à assurer une conception correcte est très largement amorti au vu du temps passé en debugage et recherche d'erreur lorsque la conception fait défaut.

    Encore une fois, cela implique une vision à terme un peu plus large que... simplement les cinq prochaines minutes

    A titre personnel, la première chose que je fais quand on me demande un code, c'est de fumer une cigarette ou de boire un café... pour prendre le temps de réfléchir aux différentes implications de ce qu'on me demande.

    A défaut de sortir l'artillerie lourde (schema UML ou nassi schneiderman), pour des petites choses particulièrement limitées dans le temps, cela me permet, au moins, d'avoir une vue d'ensemble avant de commencer à coder, et de gagner énormément de temps par rapport à ceux qui se jettent sur leur clavie et commence à "vomir des lignes de code" sans savoir exactement ce qu'ils doivent faire...

    Si tu ne me crois pas, je t'invite à en faire l'expérience par toi même
    Quelque part le C++ vient avec l'assertion que chaque partie du code sera réutilisé. De mon côté, j'écris beaucoup de code jetable qui n'aura que quelques utilisations seulement.
    Je ne vois pas en quoi un code "jetable" ou "peu réutilisé" ne mérite pas une attention particulière au moment de la conception...

    C'est un peu comme si tu estimais devoir faire plus attention en écrivant un système d'exploitation qu'en écrivant une simple calculatrice en ligne de commande: quand on fait quelque chose, même si c'est un "petit projet" qui n'est pas destiné à être récupéré, on le fait bien, ou pas du tout...

    J'apprécie énormément les logiciels de qualité, et je présumes que je suis loin d'être le seul.

    Si tu te "contente" de fournir quelque chose d'à peine passable, il ne faut pas t'étonner outre mesure si ton concurrent direct, qui fournit quelque chose de meilleure qualité, a plus de succes que toi.

    Mais bon, ce n'est qu'un avis qui n'engage que moi... Mais je le partage
    (EDIT: la philosophie du C++ est aussi de faire confiance au programmeur ; libre à lui de se tirer une balle dans le pied, non ?)
    Je dirais: raison de plus...

    Il y a déjà tellement de pièges dans lesquels on risque de tomber, que ce soit au niveau de la conception ou au niveau d'un langage particulier (je vise particulièrement C++ ici), qu'il me semble inutile d'en rajouter "uniquement pour le plaisir"
    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. #198
    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 koala01 Voir le message
    Si tu ne me crois pas, je t'invite à en faire l'expérience par toi même
    Je ne vois pas en quoi un code "jetable" ou "peu réutilisé" ne mérite pas une attention particulière au moment de la conception...

    C'est un peu comme si tu estimais devoir faire plus attention en écrivant un système d'exploitation qu'en écrivant une simple calculatrice en ligne de commande: quand on fait quelque chose, même si c'est un "petit projet" qui n'est pas destiné à être récupéré, on le fait bien, ou pas du tout...
    Moi aussi j'aime énormément quand c'est bien fait dans le code.

    Mais avoir assez vite quelque chose qui marche, dégage du temps pour une autre qualité justement ; pas forcément la qualité du code, que personne ne voit malheureusement, mais les choses à côté. Il y a aussi des moments où c'est la panique et qu'il faut aller vite (deadlines "presque tenable"...).

    Je n'ai pas l'impression que le C++ encourage spécialement à la qualité en fait (qualité dans le sens "pas de bugs"). (EDIT: même si le langage a peu d'influence là dessus)

  19. #199
    screetch
    Invité(e)

    Par défaut

    ce qui m'interesse le plus dans le C++ c'est le code généré pour moi par le compilateur; l'aggrégation de deux classes copiables est copiable, l'héritage aussi, le destructeur qui 95% du temps ne devrait pas être changé (et j'essaye vraiment de m'en tenir a cette règle)
    a côté de cela, avoir une propriété ou bien appeler une fonction ne me fait ni chaud ni froid.

  20. #200
    Alp
    Alp est déconnecté
    Expert Confirmé Sénior
    Avatar de Alp
    Homme Profil pro
    Inscrit en
    juin 2005
    Messages
    8 586
    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 586
    Points : 10 409
    Points
    10 409

    Par défaut

    Au fait, si on fait une version constexpr de sin, on peut très bien faire ça en C++0x hein ponce.

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
  •