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
Discussion :
Tu as vu ca ou? (Il a fait son doctorat a la VUB, mais si tu regardes, ses etudes antérieures -- terminée 18 ans avant le début de son doctorat -- sont aux US).Envoyé par koala01
(tout à fait HS...: je viens de me rendre compte que Coplien est un "petit belge"... cocoricooo)
ooopps.. je suis resté bloqué sur le sigle de la VUB
A méditer: La solution la plus simple est toujours la moins compliquée
Je t'invite à suivre ce post de Alp:
http://www.developpez.net/forums/d78...x/#post4544271
Les lambdas ont leur propre contexte isolé dans lequel on peut importer (par value ou reference) les entitées disponibles dans le scope parent. C'est un principe important pour que l'on puisse parler de closure plutôt que de simple expression anonyme. Les facilités d'usages (telles que présentées dans les proposals) en ce qui concerne la "capture-list" (ce qui est capturé/importé dans le contexte de l'expression) permettent de simplifier énormément ce que l'on serait obligé de faire si on devait écrire un foncteur équivalent à la main.
Hum... Ca se pose surtout pour importe quel langage multi-paradigme, et que plusieurs implémentations/design/analyses sont possibles.Le problème se pose pour n'importe quel langage...
Dans un langage mono-paradigme (fonctionnel, séquentiel, objet, ...), on n'a pas trop de choix quand à l'implémentation (sauf bidouilles), ce qui implique des contraintes en amont sur le design et donc sur l'analyse. Ce qui nous amène tout naturellement à choisir ce type langage lorsque le problème lui même se définit suivant le même paradigme.
Le fait d'avoir 3 ou 4 "sous-langages" en C++, permet d'envisager 3 ou 4 approches différentes pour résoudre le problème posé. C'est ce qu'on cache derrière les mots "souplesses" et "puissances" quand on parle du C++. Le choix c'est bien, mais il faut aussi avoir le moyen de choisir.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je comprend ton point de vue, mais je n'y adhère pas entièrement...
Le point sur lequel je suis d'accord, c'est que le fait que C++ soit multiparadigme ne facilite pas forcément le choix de la méthode de conception ou du point de vue pour aborder un problème donné.
Par contre, lorsque tu es face à un problème "inconnu" (ou peu s'en faut), si tu ne passe pas par la case "conception" (à prendre dans le sens le plus large ici) avant de te lancer, tu éprouvera des difficultés sans noms à apporter une solution correcte et efficace, et ce, quel que soit le langage ou le paradigme du langage avec lequel tu travailles...
De plus, certains Cistes n'hésitent par exemple pas à faire valoir le fait qu'une approche OO est tout à fait envisageable en C, malgré le fait qu'il n'utilise à la base que le paradigme séquentiel
une autre approche que j'essaye d'utiliser le plus souvent c'est l'approche d'architecture par composants, en fait parmi les grandes lacunes de UML était la nom prise en charge des composants mais UML 2.0 a heureusement combler cette lacune.
la conception par composants a le grand avantage d'isoler les fonctionnalités avec des frontières précises et ces composants vont êtres pluguables via leurs points de connexions.
il suffit de chercher sur google UML2 et "Approche Composant" pour se rendre compte de toute la puissance d'une tel approche.
et finalement on aura un contrôleur qui fait collaborer les différents composants pour un but donné, et ce contrôleur peut être fait par un automate qui exécute le workflow.
pour l'automate il ya pas mal d'outil qui génére depuis un workflow sous forme de diagramme la state machine, c'est très intéressant dans le sens ou on évite pas mal de bug , puisque dans un etat donné on est sur qu'on peut faire que si qui est tolérer a l'intérieur de cet état comme événement.
et bien sur chaque composant peut contenir plusieurs classes qui collaborent entre eux pour la logique du composant.
cet approche apporte plus un couplage faible et contribue a la clarté de l'architecture et surtout a la facilité d'implémentation.
Effectivement, on peut choisir une méthodologie d'analyse "objet" tout en utilisant des langages non objet. En fait, je pratique assez souvent cette façon de faire. Mais je me suis rendu compte que cela consistait simplement à avoir une approche systémique : le système complexe est analysé sous forme "objet" (ou autre) et découpé (design) en sous-systèmes. Ces sous-systèmes sont alors analysés avec la méthodologie qui leur "colle le mieux".Par contre, lorsque tu es face à un problème "inconnu" (ou peu s'en faut), si tu ne passe pas par la case "conception" (à prendre dans le sens le plus large ici) avant de te lancer, tu éprouvera des difficultés sans noms à apporter une solution correcte et efficace, et ce, quel que soit le langage ou le paradigme du langage avec lequel tu travailles...
De plus, certains Cistes n'hésitent par exemple pas à faire valoir le fait qu'une approche OO est tout à fait envisageable en C, malgré le fait qu'il n'utilise à la base que le paradigme séquentiel
C'est en gros aussi ce que dit la thèse de Coplien si j'ai bien compris. Je n'ai pas encore vue dans sa thèse une méthodologie "réellement" multi-paradigme. C'est plus un assemblage de méthodologies mono-paradigmes.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Ce bouquin devrait *beaucoup* t'intéresser.
Oui, c'est en gros ce qu'il dit. Il analyse et explique comment utiliser au mieux chaque paradigme et comment bien faire collaborer les différents paradigmes.
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++
Donc ca incite à voir les 3/4 sous-langages du C++ comme "indépendants" et plus ou moins interdire le mélange des genres. non ?
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Le but primaire de mon intervention était surtout de faire valoir que la conception doit être présente dés le départ quel que soit le paradigme, le langage ou la méthode de conception utilisée
Le but secondaire était de faire valoir le fait que, une fois que tu es parti d'une conception correcte et cohérent et que tu connais suffisamment le langage que tu utilise, le passage d'un point de vue OO à un point de vue procédural (ou vice versa) ne représente malgré tout pas une difficulté insurmontable
Ce n'est effectivement pas une difficulté que le "petit programmeur du dimanche" (dans le sens péjoratif du terme) sera capable de surmonter, mais ce ne sera pas non plus le truc tellement difficile à faire qu'il ne sera accessible aux gens ayant au minimum 180 de QI
Non, justement, ça incite à les faire collaborer dans l'harmonie, la joie et la bonne humeur !
En particulier, si tu sais bien manier la programmation OO d'un côté et la programmation générique de l'autre, en les faisant "collaborer" tu peux avoir un système robuste et souple. C'est je pense la caractéristique majeur des bibliothèques de Boost (non, ce n'est pas que de la méta-programmation).
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++
Merci Alp, finalement cette discussion n'est pas aussi stérile que ça même s'il y a quelques tensions, de mon coté j'ai découvert pas mal de bonnes références
Dans la pratique, vous utilisez quoi pour la phase de conception ?Le but primaire de mon intervention était surtout de faire valoir que la conception doit être présente dés le départ quel que soit le paradigme, le langage ou la méthode de conception utilisée
Certains citent UML(2), Merise etc.
Est-ce que papier/crayon ça ne peut pas suffir, même pour des projets complexes ? (ou un simple blackboard)
Je conçois que des outils (désolé si l'appellation ne convient pas) genre UML permettent de formaliser les conceptes, mais l'acte de créer un design est-il très souvent assisté par un tel "utilitaire" ? Autrement dit, est-ce que vous utilisez ça pour générer une conception ou plutôt pour la formaliser ?
UML, 1 ou 2, n'est pas une méthodologie.
De temps à autre je mets au propre les choix de conception, mais souvent c'est papier-crayon pour tracer des diagrammes de classes, et des diagrammes de séquence dans un formalisme pseudo UML.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Idem pour mes nouvelles applications et j'essaie d'intégrer cela dans les anciennes qui nécessitent du nettoyage.Par contre, je te certifie que j'utilise beaucoup de ces principes et techniques au quotidien là
J'applique la méthode "café / clope, papier, crayon"
Comprend par là que je me donne le temps de réfléchir "un tout petit peu" au problème soulevé avant de me remettre à table avec un papier et un crayon pour mettre au propre, dans un format généralement UML (quand il s'agit de classes) le résultat de mes premières cogitation.
Mais, si le problème est "uniquement algorithmique", je peux très bien décider, après cogitation, de partir sur une analyse basée sur le jackson (s'il s'agit d'une gestion de ruptures) ou sur du nassischneiderman (j'hésite toujours sur l'orthographe)
Le but étant de pouvoir corriger mes idées premières
Par la suite, si le besoin s'en fait sentir (projet "de longue haleine ou nécessitant une documentation de conception "tip top"), je n'hésiterai pas à me tourner vers des outils permettant de formaliser entièrement la conception sous forme de schémas UML
[EDIT]La conception peut aussi n'être qu'une expression claire et précise en bon français... Mais ce n'est pas réellement applicable comme seul manière de transmettre les info sur les gros projets
Un pointeur de fonction vers une lambda appelé depuis un foncteur dans un foreach \o/
Ma variante : café / coca, whiteboard, marqueursJ'applique la méthode "café / clope, papier, crayon"
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
La conception commence surtout comme t'a bien mentionner par un crayon-papier et idéalement un tableau.
et je rejoins Luc et Koala pour dire c'est juste une manière de formaliser soit:
- dans un souci de documentation pour tout ceux qui rejoignent l'équipe peuvent se retrouver rapidement
- générer du code a partir des diagrammes.
pour la première raison on tombe de plus en plus dans le piège d'un diagramme avec plusieurs classes ou ça devient inutilisable vu le nombre de relations qui peuvent exister surtout pour un grand projet, et c'est tout l'intérêt de l'approche orienté composants ou on a que quelques composants qui collaborent entre eux via leurs interfaces et on peut entrer a l'intérieur d'un composant pour découvrir les différentes classes qui le compose, ça reste lisible pour tout le monde.
et pour le deuxième point l'absence d'outil parfait qui gère toutes les possibilités de C++ rend la synchronisation a un moment très difficile ou il faut intervenir a la main pour synchroniser.
En quelques mois, on peut apprendre le C++ "moderne" sans problème. Il faut juste être bien encadré
Elles ne fuient pas tant le C++ qu'elles ne prennent un outil plus adapté à leurs besoin !
Il y a une différence fondamentale : la solution deux fait appel à une fonction, et à ce moment les arguments sont fixés lors de l'appel, et pas besoin de recalculer la fin de la boucle à chaque itération. C'est une des raisons des gains de temps d'exécution de la STL.
Répondre avec citation
Partager