Discussion :

[metagoto]

J'applique la méthode "café / clope, papier, crayon"

Voila qui me rassure
Je rajouterai aussi, et surtout, dormir.

Donc j'imagine que vous qui êtes des pros, vous ne devez parfois rien br*nler de la journée pour qu'à la fin de la semaine vous ayez les things done ? (je ne parle pas des profs biensûr)

[Alp]

Un pointeur de fonction vers une lambda appelé depuis un foncteur dans un foreach \o/

Si le foncteur est template et qu'il y a un peu de métaprogr sous le capot, c'est parfait

[pseudocode]

Donc j'imagine que vous qui êtes des pros, vous ne devez parfois rien br*nler de la journée pour qu'à la fin de la semaine vous ayez les things done ? (je ne parle pas des profs biensûr)

Hum... Faut tout de même se coltiner les interview des parties prenantes, l'extraction des besoins fonctionnels et des contraintes techniques, pondre des architectures candidates, organiser les brainstorms/focus avec les équipes de dev, faire les analyses de risques, marchander avec la gestion de projet (planning, WBS, budget), supporter (dans les 2 sens du terme) le V&V, rédiger des docs, faire le suivi,...

Et le reste du temps, effectivement, on bulle sur DVP.

[loufoque]

C'est pas le boulot de l'ingénieur besoins ça ?

[befalimpertinent]

Topic intéressant à suivre si on enlève les écarts HS du type XML (il aurait fallu "forké")

Ma pierre à l'édifice :

@Issam_Lahlali
Ce que tu vois comme un inconvénient beaucoup ici (dont moi) le voit comme un avantage. Je veux parler du fait que le C++ soit multi-paradigmes et que donc il offre plus de possibilités. Cela le rend peut être (et même surement) plus complexe à apprendre mais bon ceux qui survivent ()dispose d'un langage extrêmement puissant dans sa capacité à pouvoir travailler bas niveau comme haut-niveau.
Son grand atout est donc de laisser le choix au programmeur.

Au niveau de la conception, comme beaucoup je suis adepte du papier/crayon puis si je passe sur des outils UML plus pour documenter le soft que la retravailler.
Je n'ai pas l'impression de faire moins de conception que mes collègues Javaistes et Csharpistes (voir même plus concernant ceux ci vu que les entends raler quand le GC décide de nettoyer la mémoire et que leur appli se met à ramer sec)

La où je te donne un +1 dans ton postulat de départ en corrigeant :
"La communauté C++ s'intéresse autant à la technique qu'a la conception?"
Et la réponse est : parce que la puissance et la richesse de possibilités qu'il offre permet d'envisager des solutions nouvelles et efficaces pour un type de problème donné.

(ça se voit pas trop que je suis C++-addict ? )

[Matthieu Brucher]

Dans la pratique, vous utilisez quoi pour la phase de conception ?
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 ?

Une approche top down pour découper les problématiques puis une bottom-up lors de la phase de conception réelle qui se fait soit avec du UML-like, soit dans la tête selon la complexité de ce qu'il y a à faire.
En général, ça ne me sert à rien de passer par un outil pour générer le code : j'utilise beaucoup de paradigmes différents (rien que le côté statique/dynamique) et ça prendrait trop de temps à décrire ça sous forme logiciel. Si c'est nécessaire de faire un dessin, les outils comme umbrello peuvent relire le code et générer le diagramme.

[Issam_Lahlali]

@Issam_Lahlali
Ce que tu vois comme un inconvénient beaucoup ici (dont moi) le voit comme un avantage. Je veux parler du fait que le C++ soit multi-paradigmes et que donc il offre plus de possibilités. Cela le rend peut être (et même surement) plus complexe à apprendre mais bon ceux qui survivent ()dispose d'un langage extrêmement puissant dans sa capacité à pouvoir travailler bas niveau comme haut-niveau.
Son grand atout est donc de laisser le choix au programmeur.

je ne vois pas du tout que le fait que c++ est multi-paradigmes pose probléme, d'ailleurs a chaque fois je dis que le problème n'est pas forcement au niveau du langage ou de la norme mais dans la manière de l'appréhender.

et c'est le but de la question, parce que si on l'appréhende d'une manière trop technique forcement il sera très compliqué mais si on s'intéresse aussi a la conception on va savoir comment découpler les problématiques et finalement ça sera très très simple.

et pour XML même si je voulais pas y revenir mais il y des choix a prendre un moment donné pour les librairies qui peuvent faciliter amplement leur utilisation, et c'est dans le cœur du sujet et ça fait parti d'un choix de conception d'une librairie.

[Issam_Lahlali]

juste pour être clair pour une remarque qu'on me donne tout le temps comme quoi les autres langages ont les mêmes problèmes.

sincèrement je m'en fout royalement si les autres ont les mêmes problèmes , la on s'intéresse au cas C++ et c'est pas le fait qu'ils ont les mêmes problèmes que je vais les tolérer en C++.

et je ne la considère pas du tout comme argument , c'est juste se cacher derrières les erreurs d'autres langages.

je veux que le C++ soit le meilleur et je me concentre sur les choix a prendre pour le C++ , et s'il ya des complications je ne vais pas laisser tomber parce que les autres ont le même probléme.

a l'inverse il faut qu'on bataille pour être les premiers a résoudre les différentes problématiques et être le modèle pour d'autres communautés.

mais actuellement il ya plus de nouveautés coté dotnet ou java avant c++:
les lambda,les annotations,AOP ainsi que d'autres.

juste pour vous montrer que je suis aussi ou peut être plus que vous C++ addict et j'aimerais qu'il soit le TOP

[metagoto]

je veux que le C++ soit le meilleur et je me concentre sur les choix a prendre pour le C++ , et s'il ya des complications je ne vais pas laisser tomber parce que les autres ont le même probléme.

[...]

juste pour vous montrer que je suis aussi ou peut être plus que vous Pro C++ et j'aimerais qu'il soit le TOP

N'est-ce pas déjà le cas, que le C++ soit le meilleur, et ce depuis longtemps ?
Même s'il ne restait que 2 personnes au monde à l'utiliser (ça ne pourait être que Stroustrup et Koenig), ça ne changerait pas le fait que le C++ soit le meilleur

[Vilmir]

Cet article suppose que la partie conception fonctionnelle et la partie développement du produit se font par les mêmes personnes.
C'est le cas pour les petites structures, pratiquement jamais pour les grandes.
J'ai été responsable de composant C++ pendant 2 ans, avant j'étais spécialisé dans le Java et la recherche fondamentale. Je retire de cette expérience que en travaillant dans un gros framework C++ sans documentation, il est extrêmement time consuming de faire tenir le produit dans ses spécifications à cause de la complexité du langage et de ses API. Mais aussi de la complexité des outils et environnements autour du produit.

Travailler sur un code C++ multi-environnement sans équipe de design fonctionnel revient à vouloir créer un produit certe innovant et plus rapide que les autres, mais aussi horriblement lent à maintenir et faire évoluer, et souvent bardé de user scenarios aussi simples que remonter un moteur de moto 4 cylindres sans manuel.

Encore une fois, tout est histoire de choix. Je suis persuadé qu'on peut faire un super produit au niveau fonctionnel et user friendly en C++, à condition de bien voir les pièges dans les lesquel tomber et pouvoir y mettre les ressources.

[Matthieu Brucher]

C'est le cas pour les petites structures, pratiquement jamais pour les grandes.
J'ai été responsable de composant C++ pendant 2 ans, avant j'étais spécialisé dans le Java et la recherche fondamentale. Je retire de cette expérience que en travaillant dans un gros framework C++ sans documentation, il est extrêmement time consuming de faire tenir le produit dans ses spécifications à cause de la complexité du langage et de ses API. Mais aussi de la complexité des outils et environnements autour du produit.

Ca marche aussi avec d'autres langages. Un gros framework sans volonté de documentation ou de tests, c'est courant en recherche et très casse-gueule.

[jabbounet]

Ca marche aussi avec d'autres langages. Un gros framework sans volonté de documentation ou de tests, c'est courant en recherche et très casse-gueule.

c'est vrai que l'on ne trouve jamais de soft pas ou mal documenté dans nos métier

[Invité]

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.

C'est en tous cas la justification la plus fréquemment donnée pour l'utilisation des foreach(). Je pense qu'elle est spécieuse, surtout dans le contexte des lambdas.

Il y a deux possibilités.

Soit la valeur de la fin de boucle n'est pas connue lors de l'appel. On devra alors passer à foreach() une lambda expression pour la valeur de fin, et l'optimisation dont tu parles n'aura pas lieu.

Soit elle peut être calculée à l'avance. Dans le cas 2, elle devra l'être, pour être passée en paramètre à foreach(). En général, elle le sera également pour une boucle for classique (via une variable intermédiaire). Les deux méthodes seront alors équivalentes. Cependant, dans le cas d'une boucle simple, ce précalcul ne sera même pas nécessaire : le compilateur fera le travail lors de la phase d'optimisation (voire le fera mieux que le programmeur, en déroulant les boucles, ou en utilisant une optimisation rusée).

En fait, dans pas mal de cas, on tournera le problème en se ramenant au cas précalculé (par exemple en utilisant des valeurs sentinelles), mais là encore, la différence entre foreach() et for() n'apparaitra pas.

De manière générale, l'idée que les écritures raccourcies de la STL (algos remplaçant des boucles explicites) produisent d'importants gains de vitesse, me parait douteuse. La quasi totalité des algos STL qui remplacent des boucles implémentent ces algorithmes comme ... des boucles inlinées!

Francois

[Issam_Lahlali]

Encore une fois, tout est histoire de choix. Je suis persuadé qu'on peut faire un super produit au niveau fonctionnel et user friendly en C++, à condition de bien voir les pièges dans les lesquel tomber et pouvoir y mettre les ressources.

le gros probléme que je vois venir de plus en plus est justement celui des ressources,vu que l'école enseigne de plus en plus d'autres langages, on a moins de moins de jeunes qui s'orientent vers C++ et pour les Ressources humaines ça devient un casse tète de trouver des profils C++.

comme conséquence directe c'est que pour un projet au lieu d'avoir 6 personnes on ne peut avoir que 3 même si on a les moyens d'embaucher d'autres mais ça commence a devenir une perle rare.

juste une anecdote : est ce que vous avez rencontrer des boites qui choisissent la techno a utiliser par rapport surtout a possibilité de trouver rapidement des ressources ou pas

moi oui et notamment pour C++ ou ils ont choisit même d'entamer une migration pour être sur d'éviter la pénurie de développeurs C++ après quelques années , question d'anticipation

donc le probléme de ressource est un gros probléme qu'il ne faut pas prendre a la légère, et c'est vrai pour d'autres langages mais c'est plus flagrant pour C++.

[Matthieu Brucher]

Soit la valeur de la fin de boucle n'est pas connue lors de l'appel. On devra alors passer à foreach() une lambda expression pour la valeur de fin, et l'optimisation dont tu parles n'aura pas lieu.

Dans ce cas, ce n'est pas une boucle for_each, tout simplement. C'est plus une while qu'une for.

Soit elle peut être calculée à l'avance. Dans le cas 2, elle devra l'être, pour être passée en paramètre à foreach(). En général, elle le sera également pour une boucle for classique (via une variable intermédiaire). Les deux méthodes seront alors équivalentes. Cependant, dans le cas d'une boucle simple, ce précalcul ne sera même pas nécessaire : le compilateur fera le travail lors de la phase d'optimisation (voire le fera mieux que le programmeur, en déroulant les boucles, ou en utilisant une optimisation rusée).

Donc on va devoir ajouter explicitement ce précalcul. C'est donc bien plus verbeux que ce que tu ne le dis.
Oui, dans le cas d'une boucle simple le compilateur va optimiser, mais dans de nombreux cas, ce ne sera pas possible.

De manière générale, l'idée que les écritures raccourcies de la STL (algos remplaçant des boucles explicites) produisent d'importants gains de vitesse, me parait douteuse. La quasi totalité des algos STL qui remplacent des boucles implémentent ces algorithmes comme ... des boucles inlinées!

La différence avec le code inliné, c'est qu'on sait de quoi on parle sans regarder le contenu de la boucle et la décrypter. De plus, ces versions sont testées, éprouvées, optimisées. Tu ne peux pas en dire de même pour ta boucle personnelle.

[Invité]

Dans ce cas, ce n'est pas une boucle for_each, tout simplement. C'est plus une while qu'une for.

Si tu utilises des lambdas, tu peux les mettre dans tous les paramètres de ta boucle foreach() non?

Donc on va devoir ajouter explicitement ce précalcul. C'est donc bien plus verbeux que ce que tu ne le dis.

C'est verbeux dans les deux cas. Pour une boucle foreach() tu es obligé de faire ce précalcul, pour passer le résultat en paramètre à la fonction. Dans le cas d'une boucle normale, tu ne devras le faire que dans les cas compliqués (dans les cas simples, le compilateur le fera pour toi). La boucle classique est donc soit moins, soit également verbeuse qu'un foreach(), mais jamais plus.

De plus, ces versions sont testées, éprouvées, optimisées. Tu ne peux pas en dire de même pour ta boucle personnelle.

La notion de testé, éprouvé, optimisé, pour un algorithme de tri, ou un truc notoirement délicat, je veux bien (même si les librairies historiques de grands langages de programmation, comme le C, fourmillent de contre exemples), mais pour une boucle de base?

Je pense que l'argument d'optimisation a été très important au début de la STL, quand les compilateurs C++, qui avaient déjà bien du mal avec les subtilités du langage, optimisaient mal. La STL régroupait ainsi des "bonnes pratiques" d'écriture, permettant une meilleure optimisation. Je crois que la plupart de ces arguments ne tiennent plus aujourd'hui.

Il y a toutes sortes de raisons d'utiliser la STL, le fait que cela accélère le code ne me parait pas en être une.

Francois

[Matthieu Brucher]

Si tu utilises des lambdas, tu peux les mettre dans tous les paramètres de ta boucle foreach() non?

Non, il ne me semble pas. Le début et la fin sont fixes et non recalculés.

C'est verbeux dans les deux cas. Pour une boucle foreach() tu es obligé de faire ce précalcul, pour passer le résultat en paramètre à la fonction. Dans le cas d'une boucle normale, tu ne devras le faire que dans les cas compliqués (dans les cas simples, le compilateur le fera pour toi). La boucle classique est donc soit moins, soit également verbeuse qu'un foreach(), mais jamais plus.

Tu viens de dire exactement le contraire. La boucle normale est au moins aussi verbeuse que la boucle for_each puisque tu dois dans les cas compliqués précalculer la fin, ce que tu n'as JAMAIS à faire de manière additionnelle pour le for_each, puisque c'est dans la nature du for_each.

La notion de testé, éprouvé, optimisé, pour un algorithme de tri, ou un truc notoirement délicat, je veux bien (même si les librairies historiques de grands langages de programmation, comme le C, fourmillent de contre exemples), mais pour une boucle de base?

J'ai parlé de cela car tu en as parlé en premier. Dans le cas d'une boucle de base, OK, sauf qu'une fois de plus, for_each, outre le fait qu'on sache exactement que c'est un for_each et non un for modifiant, est autant ou moins verbeux qu'une boucle normale.

Je pense que l'argument d'optimisation a été très important au début de la STL, quand les compilateurs C++, qui avaient déjà bien du mal avec les subtilités du langage, optimisaient mal. La STL régroupait ainsi des "bonnes pratiques" d'écriture, permettant une meilleure optimisation. Je crois que la plupart de ces arguments ne tiennent plus aujourd'hui.

Pourtant, c'est un argument toujours valable. Et par exemple avec Visual Studio, il y a encore en plus des vérifications comme les bords, ...

[metagoto]

Alex Stepanov: Abstraction Penalty Benchmark, version 1.2
http://www.stepanovpapers.com/Abstra...yBenchmark.cpp
(ses autres papiers sont à la racine du site)

Linux slackware 32bit. Mes resultats pour g++ 4.4.1 -03 -funroll-loops

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
test      absolute   additions      ratio with
number    time       per second     test0
 
 0        0.06sec    833.33M         1.00
 1        0.06sec    833.33M         1.00
 2        0.06sec    833.33M         1.00
 3        0.06sec    833.33M         1.00
 4        0.06sec    833.33M         1.00
 5        0.06sec    833.33M         1.00
 6        0.06sec    833.33M         1.00
 7        0.06sec    833.33M         1.00
 8        0.06sec    833.33M         1.00
 9        0.06sec    833.33M         1.00
10        0.06sec    833.33M         1.00
11        0.07sec    714.29M         1.17
12        0.06sec    833.33M         1.00
mean:     0.06sec    823.51M         1.01
 
Total absolute time: 0.79 sec
 
Abstraction Penalty: 1.01

La pénalité d'abstraction (décrite dans le fichier du code) est négligeable, du moins dans mes tests. Ce qui est sympa c'est qu'initialement Stepanov prévient que le test met du temps à tourner. C'est imédiat de nos jour (1 seconde).

[Invité]

La pénalité d'abstraction, c'est l'inverse, non? Le fait que l'utilisation de la STL ne pénalise pas en terme de vitesse. Pour que la STL accélère le code, on devrait trouver, dans les résultats ci dessus, des valeurs inférieures à 1, non?

Francois

[metagoto]

Oui, la STL engendre une pénalité par rapport à un code à la main "0 - uses simple Fortran-like for loop.".