Discussion :

[souviron34]

Pour revenir au thème du thread, je dirais que cela revient à de l'optimisation..

L'optimisation est un vaste sujet, et, bien qu'intéressant, le débat ci-dessus n'en représente qu'un pouième...

• La question du stockage (et donc du déroulement d'une boucle) en ligne ou colonne est un vrai problème, où quicquonque qui n'a pas eu à alterner entre Fortran et autre chose se perdra (et fera drastiquement chuter les performances).
  
  
• Il y a la factorisation autant que faire se peut d'opérations répétitives, mêmes élémentaires (calculs d'adresses (même élément d'un tableau référencé N fois), assignations, opérations simples, etc etc).
  
  
• Il y a éviter le surdécoupage (merci procédural, bouh l'OO ), diminuer le nombre d'appels de fonctions (à bas les "normes" de longueur de fonctions)
  
  
• Il y a aussi les "dirty tricks", comme par exemple faire des tableaux d'adresses d'éléments de listes chaînées pour attaquer directement une liste à un endroit et non pas la dérouler..
  
  
• Pour la sûreté, il y a au contraire ajouter des tests (pas des asserts, des TESTS) partout où il y a possibilité de crash, d'erreur, de segfault, etc etc..

[Mac LAK]

Dans mes codes, ne devoir traiter qu'un intervalle plutôt que la totalité d'une collection, ça arrive plus rarement (je parle pour moi).

Disons que le mot "totalité" est parfois subjectif, cf. l'exemple de la file que j'ai cité...

2 choses, est-ce que la majorité des scénarios de parcours itératifs se font dans des contextes de concurrences? Dans mon cas quotidien la réponse est clairement non.

Disons que si tu n'as pas de concurrence, tu n'as (en général) pas de multithreading... Donc, rarement un programme performant quoi qu'il en soit. Tu n'as sûrement pas de communications réseau (on utilise des threads pour ça, ne serait-ce que pour éviter de bloquer le thread principal et "geler" l'IHM), pas de transferts conséquents vers la mémoire de masse, pas de calculs intensifs laissant la main sur l'IHM, voire pas d'IHM du tout...

Je ne veux pas être méchant, mais tu y fais quoi alors, dans tes programmes, si tu ne fais pas de réseau, pas de transfert de données, pas de calculs, et pas de multitâche ??

Or, si tu utilises ne serait-ce qu'un seul de ces points, tu arrives forcément sur le problème de la passation des données, ce qui implique des buffers en accès concurrent... Le cas peut être simplissime, certes, mais dans ce cas c'est rarement une application hautes performances et/ou sûre...

Pour ce qui est du parcours de X éléments d'une file d'attente par un thread consommateur à l'aide d'un for, tu n'as guère beaucoup de garantie si des éléments peuvent être enlevés de la listes des tâches derrière ton dos, soit par une action utilisateur, une modification prioritaire, ou un autre thread qui consomme la file.

J'ai parlé d'UN producteur et d'UN consommateur, dans l'exemple, ce qui peut se régler sans un seul mutex.

S'il y a plusieurs producteurs et/ou consommateurs, il faudra mettre des mutex entre eux... Mais pas entre le consommateur et le producteur actuellement autorisés, qui peuvent travailler simultanément sur le même buffer. C'est quand même toi, à l'origine, qui décide de qui prends et qui mets les données, c'est pas "mystique".

En gros il faudra une structure telle qu'une queue bloquante, et c'est des opérations du style push et pop individuelles qui seront utilisées et non des parcours.

Non. Un push/pop atomique ne sera utilisé que lorsqu'un consommateur (ou un producteur) ne mets qu'une seule et unique donnée à la fois, avec un temps "long" mais totalement imprévisible entre chaque ajout / retrait.
Sur un buffer de transfert (entre deux threads par exemple), ce n'est pas nécessaire, ni même souhaitable, d'utiliser un mutex : c'est une perte de temps CPU inutile.

En fait, comparer for et foreach en les mettant dans des contextes ou ils ne sont clairement pas adaptés, ça vaut pas la peine.

Je viens pourtant de te prouver que parcourir "tout" le conteneur est parfois sujet à interprétation, et que des effets de bords insoupçonnés peuvent se produire... A savoir soit une boucle infinie et un thread bloqué (cas le plus probable), soit, bien plus grave, le non respect d'une postcondition d'une instruction de base du langage !!!

Ce n'est pas en fonction de tes goûts qu'il faut utiliser l'un ou l'autre : il faut partir du principe que seul "for" existe, et n'utiliser "foreach" (par "feignantise", je dirais) que lorsque tu es certain qu'un effet de bord est totalement impossible, et que les performances ne sont pas critiques à cette étape (pour ce dernier point, jusqu'à correction de la différence de traduction, tout du moins).

je parlais d'un itérateur, pas d'un range... et en cachant un accumulateur dans ton itérateur, tu peux avoir un const_iterator sur un arbre quelconque.

Ah, je l'avais compris dans l'autre sens pour ma part... Reste qu'un range n'est pas applicable sur un arbre quand même.

L'optimisation est un vaste sujet, et, bien qu'intéressant, le débat ci-dessus n'en représente qu'un pouième...

Un fragment de poil de pouième, même... L'optimisation, c'est avant tout de comprendre certains principes, certaines méthodes "génériques".

Mais l'application de l'optimisation, c'est du cas par cas, et souvent de façon totalement unique dans les détails même si le principe général est plus ou moins toujours le même.

Dans tous les cas, cela demande un peu plus que savoir programmer dans un langage donné... Il faut réellement le maîtriser, connaître la cible (= la machine), et surtout pouvoir profiler le programme afin d'avoir des mesures objectives et quantifiables.

Il y a aussi les "dirty tricks", comme par exemple faire des tableaux d'adresses d'éléments de listes chaînées pour attaquer directement une liste à un endroit et non pas la dérouler..

Les listes chaînées indexées sont un de mes jouets favoris, c'est en plus très intéressant à développer... Et pas si simple qu'on pourrait le croire, du moins si l'on veut que ce soit robuste et non pas crado.

Un autre truc dans le même genre : l'allocation unique pour plusieurs buffers, par exemple une matrice... On alloue la taille totale, puis on dirige manuellement les pointeurs au sein de ce buffer pour recréer la matrice. Avantage : une seule allocation, donc une seule libération nécessaire.

Pour la sûreté, il y a au contraire ajouter des tests (pas des asserts, des TESTS) partout où il y a possibilité de crash, d'erreur, de segfault, etc etc..

Il y a aussi (côté sûreté) le concept de "hearbeat" entre threads / processus, et de watchdog logiciel (un processus qui surveille les autres et les "nettoie" s'ils plantent, avant de les relancer), qui peuvent demander des trucs assez immondes pour être implémentés efficacement... Avec pas mal de reboots lors des mises au point !

Personnellement, j'aime bien avoir des macros d'initialisation / vérification des paramètres dans mes fonctions critiques de sûreté. Par exemple, on peut avoir un truc dans le genre :

Code :

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

#define LOCAL(Type,Var) Type Var ; memset(&Var,0,sizeof(Type) ;

En test de paramètres, ce serait plutôt dans le genre :

Code :

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

#define CHECK_PARAM(Type,Param) if (Param==(Type)(0)) return EXIT_FAILURE ;

C'est supérieur à une assertion dans le sens où ce n'est pas désactivable par un réglage, donc c'est valide aussi bien en mode Debug qu'en mode Release... Ce qui ne m'empêche pas, assez souvent, d'avoir les deux (les assertions étant plutôt pour le respect des invariants / pré & postconditions).

[Nebulix]

En quoi
Code :

int sum = 0;
foreach(e : t)
sum += e;

fait une "inflation de la complexité des logiciel" par rapport à
Code :

int sum = 0;
int n = t.size();
for(int i = 0; i < n; ++i)
sum += t[i];

??

L'inflation c'est qu'on utilise deux syntaxes différentes dont il faut mémoriser le comportement exact, au risque de les mélanger, et alors...
Le "gain" apporté par foreach me parait assez limité.

J'envie les programmeurs qui ont toujours le même nombre de données à analyser. Moi j'ai plutôt à écrire
for i:=1 to le_nombre_de_données do
if elle_est_correcte(la_donnee[i]) then...

[alex_pi]

Pour revenir sur le foreach, deux choses :

En java sur un tableau, c'est compilé exactement de la même façon qu'une boucle. Même pas besoin de faire de bench

Quand on fait des programmes "sûrs", et que l'on doit écrire des triplets de Hoare (en gros, précondition/postcondition) pour prouver que le programme satisfait bien les specs, c'est bien plus simple sur un "foreach" dont la sémantique est plus facilement définissable (surtout dans des langages où il est autorisé de changer la variable de boucle dans le corps de la boucle, ce qui rend les boucles for potentiellement totalement foireuse.). Il n'y a pas toutes les preuves intermédiaires de respect des bornes, de non modification de la variable de boucle, etc. Tout ça est donné "gratuitement" par une sémantique certes moins générale mais bien plus précise. Ce que l'on perd en "souplesse", on le gagne en simplicité.

[Mac LAK]

En java sur un tableau, c'est compilé exactement de la même façon qu'une boucle. Même pas besoin de faire de bench

Ce qui ne change absolument rien à l'effet de bord principal du foreach : le parcours d'un conteneur modifié en même temps, notamment dans les conditions que j'ai indiqué...

Quand on fait des programmes "sûrs" <snip> Ce que l'on perd en "souplesse", on le gagne en simplicité.

Dans un programme "sûr" réel, c'est à dire ce que demandent réellement des clients, on ne prouve formellement qu'une infime partie du code : le système de watchdog, et celui de repli. Le reste est prouvé par une analyse statique, par une validation spécifiquement écrite dans ce but, et enfin par comparaison avec d'autres éléments certifiés de référence.

Le prix du moindre produit certifié serait totalement prohibitif, si ce n'était pas fait ainsi... Il faut quand même aussi conserver le sens des réalités économiques.

[alex_pi]

Ce qui ne change absolument rien à l'effet de bord principal du foreach : le parcours d'un conteneur modifié en même temps, notamment dans les conditions que j'ai indiqué...

Peut être que quand on fait de la programmation "sûr", on évite de faire des effets de bords sauvage sur la structure qu'on parcours généralement....

[Mac LAK]

Peut être que quand on fait de la programmation "sûr", on évite de faire des effets de bords sauvage sur la structure qu'on parcours généralement....

Quel effet de bord ?? Un effet de bord, c'est si tu ne le maîtrises pas, ou que tu ignores qu'il existe.
Quand c'est un comportement défini, connu et maîtrisé, où as-tu vu jouer que c'était un effet de bord ???

[ZoinX]

Ce qui ne change absolument rien à l'effet de bord principal du foreach : le parcours d'un conteneur modifié en même temps, notamment dans les conditions que j'ai indiqué...

C'est justement pour ça qu'en C# il est interdit de modifier le contenu d'une structure à l'intérieur d'une boucle la parcourant avec un foreach ou un énumérateur. Ca provoque une erreur de compilation. Comme ça, pas d'effet de bord

Et à la place, on a d'autres façons de par exemple supprimer tous les éléments d'une liste vérifiant une certaine condition, la méthode removeAll() appelée avec un délégué, c'est super pratique.

Pour le reste, il faut se contenter d'une boucle for standard, ce qui n'enlève rien à la simplicité et l'élégance du foreach dans les autres cas.

[Mac LAK]

C'est justement pour ça qu'en C# il est interdit de modifier le contenu d'une structure à l'intérieur d'une boucle la parcourant avec un foreach ou un énumérateur. Ca provoque une erreur de compilation. Comme ça, pas d'effet de bord

C'est justement pour souligner que l'argument "pas d'effet de bord" du foreach n'est pas "sain", car il en possède un intrinsèque à son fonctionnement... Et la phase de compilation ne gèrera pas l'accès concurrent à l'exécution, quoi qu'il en soit.

Pour le reste, il faut se contenter d'une boucle for standard, ce qui n'enlève rien à la simplicité et l'élégance du foreach dans les autres cas.

Ni à ses limites, son masquage de l'implémentation (parfois néfaste, cf. problème de traduction dont on parlait plus haut), ou à des bugs planqués liés à l'utilisation plus ou moins "inconnue" des itérateurs que le foreach pourrait faire.

Laisser faire la machine "toute seule", en terme de sûreté ou de performances, c'est rarement une bonne idée...

[ZoinX]

Laisser faire la machine "toute seule", en terme de sûreté ou de performances, c'est rarement une bonne idée...

Statistiquement, la machine se plante vachement moins souvent que le programmeur...

[gorgonite]

Statistiquement, la machine se plante vachement moins souvent que le programmeur...

la machine fait toujours ce qu'on lui demande... on ne peut en vouloir qu'au programmeur ou au hardware (float chez Intel Pentium ), pas à la machine en elle-même

la question est de savoir s'il est possible d'automatiser à 100% certaines optimisations pour être sûr d'avoir toujours le meilleur choix... et la réponse est bien souvent non, ce qui explique les compilateurs n'utilisent qu'un sous-ensemble du jeu d'intructions (enfin, y a aussi des vieilles instructions pouraves en CISC qui demandent à être jetées ^^)

[I_believe_in_code]

Quel effet de bord ?? Un effet de bord, c'est si tu ne le maîtrises pas, ou que tu ignores qu'il existe.

Non, un effet de bord c'est quand tu sais qu'il existe et que tu le maîtrise. Sinon c'est une erreur de programmation.

[alex_pi]

C'est justement pour souligner que l'argument "pas d'effet de bord" du foreach n'est pas "sain", car il en possède un intrinsèque à son fonctionnement...

C'est quoi l'effet de bord intrinsèque dont tu parles là ??

[_skip]

Or, si tu utilises ne serait-ce qu'un seul de ces points, tu arrives forcément sur le problème de la passation des données, ce qui implique des buffers en accès concurrent... Le cas peut être simplissime, certes, mais dans ce cas c'est rarement une application hautes performances et/ou sûre...

Ben en ce moment je bosse sur un algo de clustering en C++ (style agglomératif) et malheureusement ça se parallélise que super difficilement justement parce que les données à disposition évoluent à chaque opération et s'invalident rapidement au fil des calculs.

Et je suis justement en train de réfléchir à comment je peux couper en 2 les boucles de façon un minimum judicieuse. Mais soit OSEF de ma vie. En plus j'ai pas encore résolu tous les soucis supplémentaires que le C++ m'apportent par rapport au java.

Ce qui est marrant avec toi, c'est que j'ai l'impression qu'on serait presque d'accord sur le fond, si seulement on parlait les 2 des mêmes choses et dans le même contexte.

[Mac LAK]

Statistiquement, la machine se plante vachement moins souvent que le programmeur...

Comme l'a dit Gorgonite, et pour reprendre ce que j'ai déjà dit, il n'y a pas de chamanisme. L'ordinateur fait ce que tu lui dit de faire, si tu ne sais pas t'exprimer, ce n'est pas de sa faute...

L'automatisation (et le "masquage de code" inhérent à ce processus) est plus souvent néfaste que positif, du moins dans le contexte de hautes performances et/ou de sûreté de fonctionnement.

Il va sans dire que pour éditer un bon de livraison depuis l'appli de GPAO, on s'en fiche un peu... Toutefois, en terme de nombre d'unités en fonctionnement, il ne faut pas se leurrer : l'informatique de performances ou de sûreté est omniprésente dans notre monde actuel, bien plus que le nombre d'ordinateurs personnels, c'est juste qu'elle n'est pas autant "visible" que l'informatique "tape-à-l'œil".

Ton propre PC contient au bas mot une douzaine de composants de ce type, par exemple... Tout comme ta machine à laver, ta télé, ton lecteur DVD, ton baladeur MP3. Bref, pour UN PC chez toi, tu as sûrement une cinquantaine de composants embarqués dédiés à la performance, à la faible taille du code, ou à la sûreté de fonctionnement. Et pour chacun de ces composants, l'automatisation est une plaie.

Embedded wins.

(enfin, y a aussi des vieilles instructions pouraves en CISC qui demandent à être jetées ^^)

Pas touche à ces instructions !! Ce sont elles qui assurent la rétrocompatibilité binaire des PC, un des fondement de cette architecture !

Non, un effet de bord c'est quand tu sais qu'il existe et que tu le maîtrise. Sinon c'est une erreur de programmation.

Je suis ravi d'apprendre que la préemption du scheduler est une "erreur de programmation"... Tu sais qu'elle existe, mais de là à la maitriser...

Désolé, mais pour moi, un effet de bord est à prendre au sens "mathématique" du terme, c'est à dire quand il n'est pas désiré ni maîtrisé. Si c'est au sens "langage fonctionnel", j'appelle ça un effet secondaire, ou pour être précis, c'est une modification d'environnement.

C'est quoi l'effet de bord intrinsèque dont tu parles là ??

Quand tu arrives en milieu de conversation, pourrais-tu avoir la politesse de relire les topics précédents, s'il te plait ? Merci.

Tu vas quand même pas me dire que la majorité des boucles que tu écris servent à consommer une liste de workitems, si c'est le cas c'est TOI qui fait des choses peu communes.

Tout dépend du contexte de travail ! Dans du code bas niveau, c'est au contraire quelque chose de courant : une des tâches les plus fréquentes dans le bas niveau, c'est le transfert d'informations entre la couche du dessus et le hard (ou la couche soft, parfois) en dessous.
Tu as une fonction plus ou moins similaire aussi à haut niveau, dans des applications comme les serveurs, par exemple de bases de données ou web...

Ben en ce moment je bosse sur un algo de clustering en C++ (style agglomératif) et malheureusement ça se parallélise que super difficilement justement parce que les données à disposition évoluent à chaque opération et s'invalident rapidement au fil des calculs.

Si je n'étais "pas gentil", je te dirais "et où est le problème ?"...

Ceci étant dit, tu commences peut-être à apercevoir de façon superficielle en quoi peut consister mon boulot. Un système "basique" sur lequel je travaille comporte de un à quatre PC, et entre un et N (8, 16, ...) terminaux (CPU embarquées), le tout relié par réseau Ethernet. Et il faut faire travailler tout ça ensemble de façon synchronisée, soit de deux à plus de 20 machines simultanément. Le tout en temps réel à la milliseconde près, bien entendu, et une synchronisation à la microseconde...

Quand au principe général, c'est celui de la programmation impérative : boucles (acquisition/commande de bus de terrain), branchements (décisions liées à un script et/ou une configuration), et affectations (transfert de données)... Sauf que là où tu affectes normalement une donnée à une variable, moi j'"affecte" un ordinateur complet à un autre, je "boucle" sur un bus de terrain, et je "branche" un processus complet vers d'autres CPU...

Et je suis justement en train de réfléchir à comment je peux couper en 2 les boucles de façon un minimum judicieuse. Mais soit OSEF de ma vie. En plus j'ai pas encore résolu tous les soucis supplémentaires que le C++ m'apportent par rapport au java.

D'un autre côté, t'es sur un forum aussi pour apprendre et poser des questions !
L'algo que j'ai indiqué plus haut est parfaitement adapté à ce principe, et en fonction du type de données véhiculées, tu peux même l'implémenter sans utiliser un seul mutex... La communication réseau aide aussi pas mal pour synchroniser tout ça, car elle sert de mutex tacite lors de l'envoi des données, et permet une communication entre threads / processus / machines de façon identique et ceci sans requérir de synchronisation explicite, tout au plus un horodatage (timestamp) des données.

Ce qui est marrant avec toi, c'est que j'ai l'impression qu'on serait presque d'accord sur le fond, si seulement on parlait les 2 des mêmes choses et dans le même contexte.

Un algo est un algo : réaliser une application de comptabilité ou un noyau d'OS, cela reste de la programmation, ce ne sont juste pas les mêmes concepts qui sont mis en avant dans chacun des deux domaines. Si on te donne l'algo, tu es censé savoir l'implémenter quel que soit le domaine d'application derrière.

Si tu connais les concepts en question, c'est exactement la même chose... Mais tu prends aussi parfois certains automatismes "bénéfiques" que tu appliques systématiquement, pour la simple et bonne raison que cela t'es tellement naturel que toute autre méthode serait plus lente à coder.

Quand en plus l'automatisme en question est plus sûr et plus performant, il n'y a alors absolument aucune raison de ne pas l'appliquer systématiquement, même si cela n'a pas forcément d'effet visible à l'œil nu. Dans tous les cas, tu es allé à ta vitesse maximale de développement, et ton code est au plus proche de l'optimal, tout est donc pour le mieux dans le meilleur des mondes...

[ZoinX]

Comme l'a dit Gorgonite, et pour reprendre ce que j'ai déjà dit, il n'y a pas de chamanisme. L'ordinateur fait ce que tu lui dit de faire, si tu ne sais pas t'exprimer, ce n'est pas de sa faute...

Je me suis mal exprimé, je ne voulais pas parler de chamanisme. Ce que je voulais dire, c'est que s'il y avait des erreurs dans la façon dont sont implémentés les foreach dans les langages de programmation, je pense qu'on s'en serait rendus compte depuis le temps... Par contre quand tu fais tes boucles for toi-même, sur une centaine de boucles il y a statistiquement de bonnes chances pour que tu en ai fait au moins une fausse, aussi génial et infaillible sois-tu.

L'automatisation (et le "masquage de code" inhérent à ce processus) est plus souvent néfaste que positif, du moins dans le contexte de hautes performances et/ou de sûreté de fonctionnement.

Chaque ligne de code est un bug potentiel. Un foreach par rapport à un for, c'est toujours ça de moins que tu peux bugger quand tu cherches juste à parcourir une structure de données. Voilà pour la sûreté.

Quant aux performances, comme cela a déjà été souligné en java un foreach se compile exactement comme un for, donc aucune différence de performances. Ca ne m'étonnerait pas que les autres langages disposant d'un foreach fassent de même.

Il va sans dire que pour éditer un bon de livraison depuis l'appli de GPAO, on s'en fiche un peu... Toutefois, en terme de nombre d'unités en fonctionnement, il ne faut pas se leurrer : l'informatique de performances ou de sûreté est omniprésente dans notre monde actuel, bien plus que le nombre d'ordinateurs personnels, c'est juste qu'elle n'est pas autant "visible" que l'informatique "tape-à-l'œil".

Et en dehors de l'embarqué, on peut très bien avoir des logiciels pour serveur nécessitant une très très forte scalabilité et donc d'excellentes performances, tout en utilisant des langages de haut niveau et en n'optimisant pas le moindre petit détail. Je dirais même que pour les *gros* logiciels serveur (ceux pour qui il faut des centaines d'ingénieurs à plein temps pour les coder), ce serait juste humainement impossible à faire sans langage de haut niveau, car alors il ne faudrait plus des centaines mais des milliers d'ingénieurs sur le coup. Crois-moi, c'est mon boulot actuel.

[Mac LAK]

Ce que je voulais dire, c'est que s'il y avait des erreurs dans la façon dont sont implémentés les foreach dans les langages de programmation, je pense qu'on s'en serait rendus compte depuis le temps...

Non, pour la simple et bonne raison que tu n'as pas pu tester un foreach avec tous les itérateurs possibles et existants dans le monde... Et comme tu n'as aucune maîtrise du code généré, si erreur il y a, tu ne sauras pas pourquoi à priori. Et le développeur standard va alors virer le "foreach", mettre un "for" à la place, et comme il n'a pas de temps à perdre avec ça, il ne prendra même pas la peine de poster sur le forum de l'éditeur du compilateur pour alerter du bug.

Par contre quand tu fais tes boucles for toi-même, sur une centaine de boucles il y a statistiquement de bonnes chances pour que tu en ai fait au moins une fausse, aussi génial et infaillible sois-tu.

Les erreurs sur les boucles proviennent rarement des bornes elles-mêmes, mais plutôt d'une erreur d'implémentation de l'itérateur (=bug dans le foreach aussi), ou du corps de boucle (=bug dans le foreach itou).

Il faudrait quand même que tu comprennes qu'on ne met pas de débutants sur des parties de code critiques, que ce soit pour la performance ou la sûreté de fonctionnement. Bien que tout développeur fasse des erreurs, de façon totalement inévitable, il y a des erreurs qu'on ne fait plus à partir d'un certain niveau d'expérience. On en fait d'autres, bien entendu, et nettement plus velues d'ailleurs. Mais plus celles-là.

Chaque ligne de code est un bug potentiel. Un foreach par rapport à un for, c'est toujours ça de moins que tu peux bugger quand tu cherches juste à parcourir une structure de données. Voilà pour la sûreté.

C'est une ligne de code utilisateur. Le code derrière est plus volumineux avec un "foreach" qu'avec un "for", voilà pour la sûreté.

De plus, un système d'analyse statique se baserait sur un modèle mathématique du "foreach", donc dépourvu de toute erreur d'implémentation... En cas d'erreur d'implémentation du "foreach", notamment en cas d'effet de bord, ton analyse statique passe au travers et ne voit pas le bug. Tandis qu'avec un "for", il sera forcément détecté...

Quant aux performances, comme cela a déjà été souligné en java un foreach se compile exactement comme un for, donc aucune différence de performances. Ca ne m'étonnerait pas que les autres langages disposant d'un foreach fassent de même.

D'un autre côté, si tu veux des performances brutes, ce n'est certainement pas du Java que tu vas prendre comme langage... Mais comme je l'ai précisé, ce que je reproche au "foreach", c'est le masquage d'implémentation.

Et en dehors de l'embarqué, on peut très bien avoir des logiciels pour serveur nécessitant une très très forte scalabilité et donc d'excellentes performances, tout en utilisant des langages de haut niveau et en n'optimisant pas le moindre petit détail.

Tu as donc sûrement une liste complète de tels logiciels ? Parce que moi, ce genre de "monstres", je les vois toujours écrits en C/C++ pour le moteur, seules les IHM ou les consoles de contrôle sont écrites dans des langages de plus haut niveau. Bref, ce qui n'a pas de besoins de performances...
Ou alors, nous n'avons absolument pas la même notion de "performance", et ce que tu appelles "performant" est ce que j'appelle "acceptable".

Je dirais même que pour les *gros* logiciels serveur (ceux pour qui il faut des centaines d'ingénieurs à plein temps pour les coder), ce serait juste humainement impossible à faire sans langage de haut niveau, car alors il ne faudrait plus des centaines mais des milliers d'ingénieurs sur le coup. Crois-moi, c'est mon boulot actuel.

Et alors ?

Le projet sur lequel je suis correspond à plusieurs centaines d'hommes-ans, et c'est "humainement possible" de le faire, et en langage de bas niveau pour absolument toute la partie traitement, communication et "fonctionnel".

Le code de haut niveau est exclusivement réservé aux IHM, aux scripts de configuration, ou à tout ce qui n'est pas dans le chemin d'exécution des requêtes / traitements... Cela ne veut pas dire que le "noyau" lui-même est écrit en langage de haut niveau, bien au contraire.

Après, tu as toujours la possibilité de rajouter du hard pour compenser l'utilisation de langages moins performants, mais au bout d'un moment, le coût du matériel (achat, remplacement, maintenance, consommation électrique) dépasse de très loin le coût d'un logiciel optimisé... On ne fait le logiciel qu'une seule fois, le matériel est à racheter à chaque fois qu'on vend une solution, c'est une réalité économique dont il faut tenir compte... L'autre réalité économique à prendre en compte, c'est la concurrence : un logiciel optimisé tourne sur du matériel moins performant, donc moins cher, et c'est une bonne démarche en général pour griller la concurrence en étant moins chers qu'eux.

De plus, le matériel hautes performances est en général plus fragile qu'un matériel moins performant, mais dont la technologie est plus éprouvée... Ce qui augmente la sûreté de fonctionnement du programme, car sa plate-forme matérielle est elle-même plus sûre. Pour certains domaines, il est carrément impossible de trouver du matériel durci (tenue industrielle ou plus, donc) au delà d'un certain niveau de performances, ce qui limite de facto le matériel disponible, qui n'est alors pas extensible à volonté.

[_skip]

Juste un élément par rapport aux performances for vs foreach, les différences que mentionnaient l'article que j'ai cité remontent à environ 2006. Avec les nombreuses MAJ qu'il y a eu sur le framework .Net en 3 ans, ce n'est peut être plus du tout conforme à la réalité.

[gorgonite]

L'automatisation (et le "masquage de code" inhérent à ce processus) est plus souvent néfaste que positif, du moins dans le contexte de hautes performances et/ou de sûreté de fonctionnement.

tout dépend si cette transformation a été "prouvée" statiquement... auquel cas on connait exactement le coût de cette transformation (voire ses avantages )

Pas touche à ces instructions !! Ce sont elles qui assurent la rétrocompatibilité binaire des PC, un des fondement de cette architecture !

je parlais de les jeter du sous-ensemble des instructions machine utilisées par le back-end du compilateur

De plus, un système d'analyse statique se baserait sur un modèle mathématique du "foreach", donc dépourvu de toute erreur d'implémentation... En cas d'erreur d'implémentation du "foreach", notamment en cas d'effet de bord, ton analyse statique passe au travers et ne voit pas le bug. Tandis qu'avec un "for", il sera forcément détecté...

pas d'accord, dans certains cas d'analyse statique, on ne part pas du source mais du binaire... et on traitera donc le code généré et non le code écrit (sinon ça exige "théoriquement" que le compilateur soit aussi certifié, ainsi que toutes les librairies potentiellement utilisables). ça nous arrive tous les jours dans notre labo quand une partie de l'analyse consiste à trouver un WCET (Worst Case Execution Time)

après clairement, on monte en abstraction à un moment, sinon l'explosion combinatoire nous empêcherait de pouvoir analyser des composants "de taille industrielle" (pour ceux qui ont lu un de mes articles, vous verrez qu'on va jusqu'à l'analyse complète du STBus)

De plus, le matériel hautes performances est en général plus fragile qu'un matériel moins performant, mais dont la technologie est plus éprouvée... Ce qui augmente la sûreté de fonctionnement du programme, car sa plate-forme matérielle est elle-même plus sûre. Pour certains domaines, il est carrément impossible de trouver du matériel durci (tenue industrielle ou plus, donc) au delà d'un certain niveau de performances, ce qui limite de facto le matériel disponible, qui n'est alors pas extensible à volonté.

certains domaines comme l'aéronautique utilisent encore des 68'000

[alex_pi]

L'automatisation (et le "masquage de code" inhérent à ce processus) est plus souvent néfaste que positif, du moins dans le contexte de hautes performances et/ou de sûreté de fonctionnement.

http://www.rtca.org/
http://www.eurocae.net/
http://www.esterel-technologies.com/...s/scade-suite/
http://www.eads-nv.com/xml/content/O...6/41400565.jpg
http://en.wikipedia.org/wiki/B-Method
http://www.springerlink.com/content/6270q55856qu7783/

Quand tu arrives en milieu de conversation, pourrais-tu avoir la politesse de relire les topics précédents, s'il te plait ? Merci.

Sauf que j'insiste, il n'y a pas d'effet de bord "inhérent" à la notion d'ittérateur. Ne t'en déplaise, sur un "'a container", tu peux très bien avoir un type "'a iterator", et trois fonction

Code :

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

1
2
3
init : 'a container -> 'a iterator
next : 'a iterator -> 'a iterator option
get : 'a iterator -> 'a

sans aucun effet de bord que peut ensuite utiliser l'implémentation de foreach.

Non, pour la simple et bonne raison que tu n'as pas pu tester un foreach avec tous les itérateurs possibles et existants dans le monde... Et comme tu n'as aucune maîtrise du code généré, si erreur il y a, tu ne sauras pas pourquoi à priori.

J'espère que quand tu compiles, t'es toujours au niveau 0 des optimisations. Parce que sinon, sans vouloir t'inquiéter, il y a quand même beaucoup plus de chance que les bugs du compilo soient dans l'allocation de registre
ou le software pipelining, que dans le foreach...

Les erreurs sur les boucles proviennent rarement des bornes elles-mêmes, mais plutôt d'une erreur d'implémentation de l'itérateur (=bug dans le foreach aussi), ou du corps de boucle (=bug dans le foreach itou).

Qui a déjà vu un dépassement de borne dans le descriptif d'une faille de sécurité ????

C'est une ligne de code utilisateur. Le code derrière est plus volumineux avec un "foreach" qu'avec un "for", voilà pour la sûreté.

Oui, on appelle ça l'expressivité.

De plus, un système d'analyse statique se baserait sur un modèle mathématique du "foreach", donc dépourvu de toute erreur d'implémentation... En cas d'erreur d'implémentation du "foreach", notamment en cas d'effet de bord, ton analyse statique passe au travers et ne voit pas le bug. Tandis qu'avec un "for", il sera forcément détecté...

Et pourquoi il serait forcément détecté ? Non mais sérieusement, tu crois qu'un compilo ne fait rien avec une boucle ? Qu'il la laisse telle quelle ? Qu'il ne la déroule jamais, ne fais jamais de software pipelining ? D'élimination de code mort ? De permutation d'instruction ?