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).Citation:
Envoyé par koala01
Version imprimable
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).Citation:
Envoyé par koala01
ooopps.. je suis resté bloqué sur le sigle de la VUB :aie::aie:Citation:
Envoyé par Jean-Marc.Bourguet
Je t'invite à suivre ce post de Alp:Citation:
Envoyé par Arzar
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.Citation:
Envoyé par koala01
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.
Je comprend ton point de vue, mais je n'y adhère pas entièrement...Citation:
Envoyé par pseudocode
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".Citation:
Envoyé par koala01
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.
Ce bouquin devrait *beaucoup* t'intéresser.Citation:
Envoyé par Issam_Lahlali
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.Citation:
Envoyé par pseudocode
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 ?Citation:
Envoyé par Alp
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 !Citation:
Envoyé par pseudocode
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 :mouarf:).
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 :)Citation:
Envoyé par Alp
Dans la pratique, vous utilisez quoi pour la phase de conception ?Citation:
Envoyé par koala01
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.
Idem pour mes nouvelles applications et j'essaie d'intégrer cela dans les anciennes qui nécessitent du nettoyage.Citation:
Envoyé par Alp
J'applique la méthode "café / clope, papier, crayon" :D
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 ;) (mais il m'arrive aussi de mettre mes schémas au propre simplement avec Paint :D)
[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 :P
Un pointeur de fonction vers une lambda appelé depuis un foncteur dans un foreach \o/Citation:
Envoyé par Alp
Ma variante : café / coca, whiteboard, marqueurs :DCitation:
J'applique la méthode "café / clope, papier, crayon"
La conception commence surtout comme t'a bien mentionner par un crayon-papier et idéalement un tableau.Citation:
Envoyé par metagoto
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é ;)Citation:
Envoyé par Issam_Lahlali
Citation:
Envoyé par Issam_Lahlali
Elles ne fuient pas tant le C++ qu'elles ne prennent un outil plus adapté à leurs besoin !Citation:
Envoyé par Issam_Lahlali
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.Citation:
Envoyé par fcharton