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
Compile Time Function ExecutionEnvoyé par Klaim
Cf : La métaprogrammation en C++
Je suis aussi très dubitatif avec cette feature.
Boost.Typeof en attendant
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.
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
Pouvoir exécuter une fonction à la compilation.
Par exemple: const a = sin(1.5); // a est connue à la compil
Les arrays op potentiellement permettent de vectoriser une boucle.
Ce qu'on peut faire en mieux en C++ avec des expressions templates, pour être honnête (Eigen).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
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. Même si Delphi avait mieux compris les propriétés je trouve.
Cf plus bas.
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.)
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.
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.
On dit C++1x
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).
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.
Dernière modification par Invité ; 01/02/2010 à 13h18.
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
Là aussi, avec la méta programmation, c'est possible, avec la même remarque que plus hautLes arrays op potentiellement permettent de vectoriser une boucle.
Ce qu'on peut faire en C++ avec des expressions templates.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
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 (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 sans doute une histoire de goûts, moi je ne peux pas m'en passer.
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
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éeOui je sais, c'est pour ca que j'ai précisé "aujourd'hui".
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
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 codeExact, 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.
Absoluement pas...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).
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
C'est à quoi servent, entre autres, les en-têtes précompilées et les bibliothèquesIl 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.
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
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".
+1 avec screetch... surtout que si on part par là, le C++ est turing complet, donnc il peut " tout faire"... Tout comme le BF
Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.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
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.
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).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
La partie la plus facile. La CTFE c'est une très grosse partie.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
Merci mais j'ai des clients qui attendent, je vais pas coder pour une norme pas finie.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
Non tu ne peux pas t'en passer en C++.Si tu n'utilise pas les macros du préprocesseur, tu peux parfaitement t'en passer
Cite moi un programme réel sans macros et sans #ifdef
C'est pourtant ce qui arrive quand parser un fichier nécessite toute la chaîne de compilation.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
Ah les joies de faire des librairies dynamiques en C++... Pas étonnant que les gens s'en tiennent à une interface C.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 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).
A priori, avec son développement polynomial si mes souvenirs mathématiques sont bons
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
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++:
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
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2).
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.
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
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
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.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.
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...
Tu me confirme ici que tu as une vision déformée de 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).
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 deJe 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 BComme 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"La partie la plus facile. La CTFE c'est une très grosse partie.
Et pourtant...Merci mais j'ai des clients qui attendent, je vais pas coder pour une norme pas finie.
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
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...Non tu ne peux pas t'en passer en C++.
Cite moi un programme réel sans macros et sans #ifdef
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 pasC'est pourtant ce qui arrive quand parser un fichier nécessite toute la chaîne de compilation.
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)...Ah les joies de faire des librairies dynamiques en C++... Pas étonnant que les gens s'en tiennent à une interface C.
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
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?
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
J'avoue que c'est la feature qui me plait le plus dans la norme qui vient.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)...
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).
Justement, c'est tout le noeud du problème...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
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(ou alors tu penses qu'on a jamais besoin de getter
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é.
Effectivement, c'est assez choquant de leur partIl y a pire, j'ai vu un langage où chaque définition de champ définissait un getter et un setter automatiquement
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.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
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.
Tout à fait d'accord. Je trouve d'ailleurs que le C++ est rempli de tels "pièges".
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 ?)
Dernière modification par Invité ; 01/02/2010 à 15h48.
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
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...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.
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
Je dirais: raison de plus...(EDIT: la philosophie du C++ est aussi de faire confiance au programmeur ; libre à lui de se tirer une balle dans le pied, non ?)
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"
Moi aussi j'aime énormément quand c'est bien fait dans le code.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...
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)
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.
Au fait, si on fait une version constexpr de sin, on peut très bien faire ça en C++0x hein ponce.
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Répondre avec citation
Partager