Les languages de haut niveau plus rapide que ceux de bas niveau - Page 1

Cette article qui est passé sur slashdot m'a parru intéressant: http://www.informit.com/articles/article.asp?p=486104&rl=1

En gros, ça explique que des languages de bas niveau comme le C ne sont plus adapté pour exploiter toute la puissance des nouveaux processeurs.

Hmmm ça fleure bon le troll, mais ça m'intéresse, je lirai ça demain

Jyaif :
En gros, ça explique que des languages de bas niveau comme le C ne sont plus adapté pour exploiter toute la puissance des nouveaux processeurs.

Je n'ai pas encore lu l'article, mais c'est une évidence, le modèle de C est complètement séquentiel : les accès mémoires sont bordéliques et tout peut pointer n'importe où, donc chaque instruction dépend potentiellement de la précédente et on est obligé de tout exécuter dans l'ordre... Pour paralléliser efficacement, il faut une représentation mémoire plus précise, idéalement comme un langage fonctionnel pur où on sait exactement quelles sont les entrées et les sorties de chaque fonction, et une bibliothèque de fonctions de haut-niveau pour pouvoir faires des choses de façon concurrente ^^ (par exemple une boucle C qui lit un tableau est purement séquentielle, alors qu'un langage de haut niveau peut fournir des fonctions de lecture de tableau parallèles)

Avec les processeurs à x coeurs qui vont voir le jour il faut se mettre sérieusement à la programmation parallèle multi-threadée. ^^

Je ne suis pas d'accord avec la problématique sur l'inadaptation des languages tels que le C pour les nouveaux processeurs, j'aurais plus tendance à parler de la problématique de créer un compilateur qui tienne la route.
Pour le multicœur, c'est pas vraiment le problème puisque la parallélisation est gérée au niveau noyau.
Par contre pour ce qui est des multiples ALUs parallèles... Bon les processeurs font leur propre gestion des dépendances et réordonnancement du code (je vous renvoie aux nombreux articles sur le core 2 duo ).
Quant à l'article, je suis dubitatif quand aux arguments du type. Et puis on n'utilise pas le C et le Java pour faire la même chose, je me demande même pourquoi la question se poserait.
Pour les instruction étendues (MMX, SSEx, etc) je ne dis pas qu'un peu d'assembleur en ligne ne serait pas nécessaire, ou un compilo bien intelligent (il y a déjà des compilos qui sortent ces instructions), mais la différence n'est pas dans le fait que le language ne soit pas adapté, juste qu'il faille le faire soit-même.
Pour le passage de paramètres il ne parle pas du passage par registre.
Pour les fonctions inline, et les macros ?
Pour la parralélisation de lecture des tableaux, etc, finalement ça revient plus à un problème d'algorithmique masquée par le haut niveau mais nullement impossible en bas niveau.
C'est d'ailleurs dit dès le début en distinguant haut et bas niveau

Je suis d'accord avec toi quand tu dis que les arguments du types sont foireux, mais pour le reste...

Dans la façon dont je vois les choses, un algorithme exprimé en C, est l'expression de l'algorithme en lui même (souvent déjà optimisé par le cerveau humain... tiens donc le compilo C sait pas le faire à notre place ? ^^), et le même algorithme en un langage bien plus évolé, sera plus la représentation conceptuelle de l'algorithme que l'algorithme lui-même.

Pour donner un exemple [plus ou moins] concret, immagines que tu codes une fonction WordCount qui compte le nombre de mots différents (uniquement caractères aphanumériques) dans un texte. La meilleure façon de procéder à mon avis (je peux me tromper là dessus mais là n'est pas la question) c'est d'utiliser une table de hachage.
En C tu va coder ta fonction HashString(char *string);, ta fonction AddString(char * string); et ainsi de suite, et à la fin tu retournera juste le nombre d'éléments de la table de hash.
En C# (je dis C# parce que je ne connais pas suffisemment Java pour pouvoir garantir que c'est la même chose, mais en réalité le langage n'a *absolument* aucune importance, c'est juste pour donner quelque chose d'un peu concret) tu va te contenter d'utiliser la classe Hashtable toute faîte, pour le reste ça sera pareil qu'en C...
Maintenant, je ne parle plus de ce qui est réel, mais de ce qui est potentiellement la différence. En C tu utilises des fonctions, et C# le concept de Hashtable dans la librairie standard (ça veut dire que, dans un hypothétique cas idéal, le compilo sait sans problème ce que c'est).
On va mettre dans la fonction principale des deux programmes, uniquement return WordCount("");.
Dans le cas idéal (en réalité actuellement ça ne l'est probablement pas :/) le compilo C va inliner la fonction... Puis basta...
Dans le cas idéal (ce n'est pas le cas actullement ! :'() le compilateur (comprendre par là le JIT, pke because reflexion toussa le compilo C# en lui même peut quasiment rien optimiser hein) C# va inliner la fonction. Là par contre il y a autre chose.
Dans la boucle de lecture des caractères... tu auras un truc genre for (int i = 0; i < strlen(string); i++) { } en C, et en C# for (int i = 0; i < string.Length; i++) { }, (dans la réalité n'importe quel programmeur pas trop con aura décalé le strlen() et le string.Length dans une variable locale, mais là osef)... Toujours dans le cas idéal, le compilateur (JIT toujours) étant au courant du concept de string, il sait que "".Length = 0. Par conséquent, il sait que le code de la boucle for ne sera jamais éxécuté, par conséquent il peut le virer... Du coup le code de hashtable, étant contenu dans le for, ne sera jamais compilé, les fonctions correspondantes non plus, et après une dernière optimisation dûe à la conaissance du concept de hashtable par le compilateur, il restera tout simplement return 0;

Evidemment ça reste encore purement immaginatif, mais tu ne peux pas nier que d'une part cette optimisation en C# parrait très simple à mettre en oeuvre (encore une fois à cause de la réflexion ce n'est pas le cas, mais ça reste loin d'être impossible...), et que d'autre part elle est complètement impossible à implémenter en C.

Bref, j'espère que cet exemple convaincra tout le monde, parce que je crois pas avoir jamais trouvé d'aussi bon exemple pour exprimer mes idées

l'idée qu'on peut mieux appliquer des optimisations de haut niveau dans un langage de haut-niveau est effectivement bonne, cela dit à mon avis ton exemple est pas convaincant du tout : supprimer du code inutile, ça ne sert pour ainsi dire à rien, ça n'a aucune incidence sur la vitesse d'exécution du programme, et ça a un impact marginal sur la taille... (en général, on rajoute pas du code inutile juste pour le fun ^^) ce qui serait utile au niveau de l'optimisation, ce serait plutôt l'analyse des dépendances entre instructions

En général on ajoute pas du code inutile juste pour le fun => Et ben dans ce cas suppose simplement que le code est dans une librairie... (Oui bon, j'aurai carrément du mettre ça dans l'exemple)
En C t'aura absolument aucune optimisation, et en langage de plus haut niveau genre Java ou C#, et bien tu aurai (toujours dans le cas où le JIT serait un peu plus évolué que ceux qui existent actuellement) toujours les optimisations
Par exemple, pour une librairie que tu n'aurais pas codée toi même, et dont tu appellerais une fonction avec un ou plusieurs des paramètres étant toujours à la même valeur, tu pourrais faire une optimisation (enfin là c'est un peu trop poussé pour faire du JIT) exactement du même type mais qui pourrait se révéler très avantageuse pour le programme... Bref c'est exactement la même chose sur le principe de base, mais dans certains cas ça peut modifier bien plus le programme que l'exemple tout con que j'ai donné Bon, mais flemme de trouver un exemple là...
Sinon on peut aussi penser à de la réoptimisation dynamique dans le cas d'utilisations de pointeurs de fonctions ou assimilés (delégués en C#, interfaces/classes dérivées en C#/Java), par exemple une classe qui prendrait un callback (pas un event multicast comme en C#...), donc un truc intrinsèquement lent du fait des méthodes virtuelles, pour ses opérations... Si on le jugeait nécéssaire, il serait possible de recompiler le code a chaque changement de ce callbak, afin d'avoir toujours des appels optimisés. Bien sûr ça demande une analyse assez poussée du code, donc impossible a aire avec les JIT actuels, mais il y a toujours moyen d'améliorer (*profiler* hem)

y n'agit pas sur Object, var v1 = Object.FunctionA(toto); Display(v1); Object.FunctionB(); var v2 = Object.FunctionA(toto); Display(v2);Sinon quand tu parles d'analyse des dépendances entre insructions, c'est genre vérifier si, en supposant que Displav); Display(v);

est équivalent àvar v = Object.FunctionA(toto);
Object.FunctionB();
Display(

c'est ça ? En tout cas c'est pas la première chose qui me vien a l'esprit, mais c'est clair que c'est intéressant niveau optimisation,
Et ça montre bien que les possibilités d'optimisations sont bien plus nombreuses qu'en C (enfin surtout que l'optimiseur fait le boulot à notre place... Mais bon c'est aussi un peu le principe à la base :d)
Quoique certaines optimisations de ce type doivent se retrouver dans le compilateur Visual C++ avec ses Global Optimizations

GoldenCrystal
: Par exemple, pour une librairie que tu n'aurais pas codée toi même, et dont tu appellerais une fonction avec un ou plusieurs des paramètres étant toujours à la même valeur, tu pourrais faire une optimisation (enfin là c'est un peu trop poussé pour faire du JIT) exactement du même type mais qui pourrait se révéler très avantageuse pour le programme...

Oui enfin si la différence est suffisamment importante pour avoir une différence de performance significative à un endroit critique du programme et que les gens de la lib n'ont pas pensé à faire une version sans ce paramètre supplémentaire, c'est peut-être que cette lib n'est pas adaptée et pas pensée pour l'optimisation ? (sans compter que si ça a déjà un impact important sur la performance avec des optimisations faites par le compilo, ça risque d'être nettement mieux avec une fonction de la lib plus adaptée)

Sinon on peut aussi penser à de la réoptimisation dynamique dans le cas d'utilisations de pointeurs de fonctions ou assimilés (delégués en C#, interfaces/classes dérivées en C#/Java), par exemple une classe qui prendrait un callback (pas un event multicast comme en C#...), donc un truc intrinsèquement lent du fait des méthodes virtuelles, pour ses opérations... Si on le jugeait nécéssaire, il serait possible de recompiler le code a chaque changement de ce callbak, afin d'avoir toujours des appels optimisés. Bien sûr ça demande une analyse assez poussée du code, donc impossible a aire avec les JIT actuels, mais il y a toujours moyen d'améliorer (*profiler* hem)

Un peu comme les templates en C++, en quelque sorte ? (sauf que les templates C++ c'est un peu naze parce que c'est pas du tout général : il faudrait par exemple pouvoir préciser que n'importe lequel des paramètres doit être inliné dans le code de la fonction, sans restriction de type et sans redéfinition de la fonction)

y n'agit pas sur Object, var v1 = Object.FunctionA(toto); Display(v1); Object.FunctionB(); var v2 = Object.FunctionA(toto); Display(v2);Sinon quand tu parles d'analyse des dépendances entre insructions, c'est genre vérifier si, en supposant que Displav); Display(v);

est équivalent àvar v = Object.FunctionA(toto);
Object.FunctionB();
Display(

c'est ça ?

Oui ^^

En tout cas c'est pas la première chose qui me vien a l'esprit, mais c'est clair que c'est intéressant niveau optimisation,

C'est pourtant important pour la parallélisation automatique : scheduling des instructions, optimisations SIMD (bon ça c'est à plus petite échelle), génération de code threadé, etc...

le SIMD c'est pas forcement a petite echelle (enfin ça depend de ce que tu entend par "petite echelle" )
mais si tu fais un soft qui fait de gros calculs en // (genre par ex plein de multiplications sur des entiers 16bits, plein genre 4 ou 8 a la fois, le SIMD peut grandement améliorer la vitesse de calcul de ton soft, perso j'appelle pas ça "petite echelle"

je veux dire que tu essayes de voir si des petits blocs d'instructions commutent, i.e. que tu regardes le code à plus petite échelle que si tu essayais de voir si des gros blocs d'instructions commutent comme dans l'exemple de GC ^^

ok ^^

GoldenCrystal :
tu auras un truc genre for (int i = 0; i < strlen(string); i++) { } en C, et en C# for (int i = 0; i < string.Length; i++) { }, (dans la réalité n'importe quel programmeur pas trop con aura décalé le strlen() et le string.Length dans une variable locale, mais là osef)

c'est marrant que tu dises ça tout en défendant les langages de haut niveau ... pour moi ça devrait typiquement être le travail du compilo d'optimiser ce genre de choses. Un coup de static flow analysis pour être sûr que string.length ne change pas et puis voilà.

(euh oui j'ai pas fait la remarque mais complètement crayon ^^ enfin de façon encore plus idéale ça se ferait en évitant d'utiliser un concept inapproprié comme une boucle for (condition;condition;condition), qui est peu adapté à cet usage parce que trop générique, mais plutôt à un itérateur du genre for (char c in string.Chars) ou encore for (int i in string.Indices) ou encore for (int i in 0...string.Length), où on se fixe au début un ensemble, *puis* on itère dessus)

Pollux
:Oui enfin si la différence est suffisamment importante pour avoir une différence de performance significative à un endroit critique du programme et que les gens de la lib n'ont pas pensé à faire une version sans ce paramètre supplémentaire, c'est peut-être que cette lib n'est pas adaptée et pas pensée pour l'optimisation ? (sans compter que si ça a déjà un impact important sur la performance avec des optimisations faites par le compilo, ça risque d'être nettement mieux avec une fonction de la lib plus adaptée)

Ben pas forcément... J'ai parlé de paramètres appellés avec toujours la même valeur, pas forcément apellés à leur valeur par défaut... Dans une (très très) moindre mesure, apeller toujours memcpy avec une taille de 32 octets, c'est carrément optimisable (pas forcément inlinable), mais osef de toute les compilateurs que ça concerne ne peuvent pas le faire (compilation séparée)... Et même dans le cas des paramètres par défaut, à moins de trucs très poussés, on se contente souvent d'apeller la fonction qui implémente tout avec ses paramètres par défauts (mm principe que les paramètres optionnels dans certains langaes) plutôt que de s'amuse rarement a recopier/recoder la même chose dans 50 fonctions juste pour l'optimisation... La redondance ça rend le code carrément moins, voire pas du tout maintenable quand même, et ça c'est pas négligeable hein ^^

Pollux :
Un peu comme les templates en C++, en quelque sorte ? (sauf que les templates C++ c'est un peu naze parce que c'est pas du tout général : il faudrait par exemple pouvoir préciser que n'importe lequel des paramètres doit être inliné dans le code de la fonction, sans restriction de type et sans redéfinition de la fonction)

Je connais pas assez les templates en C++, mais je suppose que c'est ça ^^ (Mais bon le C++ tout comme le C, même avec optimisations globales, reste limité par la compilation séparée (sux) et ça ne changera ceratinement pas de si tôt.)

./13 > Effectivement un compilo évolué peut optimiser ça (reste à voir dans quels cas), et je pense que le compilateur (et non pas le JIT cette fois) C# doit certainement le faire, mais là j'ai juste recopié la même chose qu'en C pour le C# c'est tout ...
Et si je défends les hauts niveau sur le fait qu'ils simplifient la vie aux programmeurs, je les défends pas sur le fait de les rendre cons hein...
Si tu vois une [vraie] optimisation à faire (simple qui plus est), alors fais là... Le compilateur l'aurait peut-être fait ou peut-être pas, mais là au moins tu sais que c'est fait. Parce que bon, avec des "le compilateur devrait" tu finis par faire des codeurs fainéants qui ne cherchent même pas l'optimisation, et le compilateur derrière ne doît jamais être une excuse pour ça.
./14 > Pour la question des itérateurs, ça se défend... ou pas ^^ Perso j'aime pas tellement utiliser ça sur les chaînes puisque ça ne te permet pas de connâitre la position où tu es, donc je n'ai pas mis ça dans l'exemple, mais sinon, ça dépend vraiment de la manière dont le langage gère les chaînes... En .NET c'est assez pourrave, bien que totalement compréhensible, (une chaîne est définie comme un type valeur...) mais heureusement tu peux utiliser un StringBuilder qui corrige très bien le défaut, et en Java je sais pas, mais dans tous les cas il faut vraiment pouvoir avoir accès a un équivalent correct à ce que tu ferais en C (buffer temporaire + strncpy).

Pollux :
(euh oui j'ai pas fait la remarque mais complètement crayon ^^ enfin de façon encore plus idéale ça se ferait en évitant d'utiliser un concept inapproprié comme une boucle for (condition;condition;condition), qui est peu adapté à cet usage parce que trop générique, mais plutôt à un itérateur du genre for (char c in string.Chars) ou encore for (int i in string.Indices) ou encore for (int i in 0...string.Length), où on se fixe au début un ensemble, *puis* on itère dessus)

Oui mais bon y a pas que les boucles for, un exemple typique et générique serait « f(_,g(_)) » : si il est pas trop compliqué de montrer que « _ » ne fait pas d'effets de bord, alors le compilateur devrait optimiser à ma place.

Enfin faut pas oublier quand même quelque chose, les langage de haut niveau on été fait avec des langages de bas niveau, donc a un moment ou un autres le haut niveau deviens plus générique que ce qu'on peut faire en bas niveau. Il est sur que pour certain trucs que proposent le C# (pour ne citer que lui) n'est possible en C ou ASM (pour parler du "pire") qu'en demandant plus d'effort. Mais avec plus d'effort, en C ou ASM on arrivera toujours a faire un peu mieux (voir bcp mieux dans le pire des cas) C'est comme la comparaison entre C et ASM

Faut mieux un mauvais programmeur C qu'un mauvais programmeur ASM car le compilo C est moins permissif que l'assembleur ASM et donc même en programmant mal le compilo C empêchera certaines bêtises d'arriver, ce qu'en ASM ne ferras pas.
Le seul vrai avantage des langages de haut niveau c'est d'apporter un niveau d'abstraction supplémentaire permettant de ce concentrer sur ce qu'on a a faire plutôt que sur comment le faire. (pour prendre un exemple simple, code un soft qui affiche dans un treeview (sous windows bien sur) avec la lib MSXML en C++, et fait la même chose en .NET avec C#. C# rend les choses bcp plus simple, et sûrement beaucoup plus facilement bug-free. Mais dire que les langages de haut niveau sont plus rapide, oui il sont plus rapide si c'est comparé a un "mauvais" programmeur en langages de bas niveau, ce qui fausse la comparaison. Meme un mauvais programmeur en "haut niveau" grace au facilitées d'optimisation & co fourni par celui-ci.

Ben tant que ton compilateur ne fait pas une bête traduction en C avant d'appeler gcc, on peut pas dire que ton langage de haut niveau dépend du C. C'est pas parce que ton compilateur est écrit en C que t'es condamné à aller plus lentement que le C hein ^^

un itérateur du genre for (char c in string.Chars) ou encore for (int i in string.Indices) ou encore for (int i in 0...string.Length), où on se fixe au début un ensemble, *puis* on itère dessus)

^^
Le C++ dispose d'un for_each.

apeller toujours memcpy avec une taille de 32 octets, c'est carrément optimisable (pas forcément inlinable), mais osef de toute les compilateurs que ça concerne ne peuvent pas le faire

ben justement....
mauvais exemple memcpy ^^

La redondance ça rend le code carrément moins, voire pas du tout maintenable quand même

On a les templates pour ça justement. Ca se limite pas au type, ça peut également recopier du code automatiquement pour plusieurs valeurs d'une variable.

./8> GCC sait réordonnancer les instructions, et sait faire du dépliage de boucles depuis bien longtemps. Le RISC est pas tout neuf (1982), le SIMD non plus (1976). Et le VLIW a plus de 20 ans déjà. Les dépendances entre instructions ne sont pas un problème nouveau, et la plupart des compilateurs savent déjà faire de très nombreuses choses sur le sujet.

GoldenCrystal :
./14 > Pour la question des itérateurs, ça se défend... ou pas ^^ Perso j'aime pas tellement utiliser ça sur les chaînes puisque ça ne te permet pas de connâitre la position où tu es

C'est bien pour ça que j'ai dit qu'on pouvait itérer sur les indices de la chaîne plutôt que sur ses caractères eux-mêmes si besoin est

Moumou :
Oui mais bon y a pas que les boucles for, un exemple typique et générique serait « f(_,g(_)) » : si il est pas trop compliqué de montrer que « _ » ne fait pas d'effets de bord, alors le compilateur devrait optimiser à ma place.

C'est assez orthogonal : ce que tu dis s'applique dans les cas simples, et c'est effectivement très utile. Mais adopter une boucle for qui n'est optimisée que dans les cas simples et se casse la gueule si on peut faire un accès mémoire difficile à analyser, ce n'est pas non plus une bonne idée : c'est pour ça que je parlais d'itérer sur un ensemble fixé au départ plutôt que de recalculer systématiquement les bornes à chaque itération ^^

spectras
:

un itérateur du genre for (char c in string.Chars) ou encore for (int i in string.Indices) ou encore for (int i in 0...string.Length), où on se fixe au début un ensemble, *puis* on itère dessus)

^^Le C++ dispose d'un for_each.

... qui en pratique n'est pas du tout équivalent au for niveau facilité d'utilisation (et pour cause, définir une classe qui prend en paramètre toutes les variables dans le scope de ton bloc for c'est pas franchement pratique...), résultat si tu regardes le code d'un projet C++ au hasard je pense que tu trouveras quasiment que des for :/

... qui en pratique n'est pas du tout équivalent au for niveau facilité d'utilisation (et pour cause, définir une classe qui prend en paramètre toutes les variables dans le scope de ton bloc for c'est pas franchement pratique...), résultat si tu regardes le code d'un projet C++ au hasard je pense que tu trouveras quasiment que des for :/

for. possible.
Déjà si tu prends un projet C++ au hasard et que tu trouves des STL dedans, c'est que t'as affaire à des développeurs largement au dessus de la moyenne. Ne parlons même pas des streams.

Moumou :
Ben tant que ton compilateur ne fait pas une bête traduction en C avant d'appeler gcc, on peut pas dire que ton langage de haut niveau dépend du C. C'est pas parce que ton compilateur est écrit en C que t'es condamné à aller plus lentement que le C hein ^^

C'est pas ce que j'ai dit ^^

ce que je voulait dire dans mon pavé mal foutu, c'est que ce que tu peut faire avec le "haut niveau", tu peut le faire aussi bien en "bas niveau" voir meme peut etre mieux car tu n'est pas bridé par le fonctionnement dudit haut niveau

spectras
:

... qui en pratique n'est pas du tout équivalent au for niveau facilité d'utilisation (et pour cause, définir une classe qui prend en paramètre toutes les variables dans le scope de ton bloc for c'est pas franchement pratique...), résultat si tu regardes le code d'un projet C++ au hasard je pense que tu trouveras quasiment que des for :/

for. possible.
Déjà si tu prends un projet C++ au hasard et que tu trouves des STL dedans, c'est que t'as affaire à des développeurs largement au dessus de la moyenne. Ne parlons même pas des streams.

Moui mais là ce n'est pas une question d'être "au-dessus" de la moyenne : c'est complètement impensable même pour qqun qui connaît le C++ sur le bout des doigts d'écrire un projet avec ne serait-ce qu'autant de for_each que de for... (alors que si je regarde dans mes scripts ruby pour yn, j'ai 2 boucles while et 76 boucles 'each' ou 'map', preuve qu'on peut très bien se passer des for)

Oui. Encore que je sais pas comment travaille ruby, mais les foreach de php sont boiteux dès lors que tu veux modifier les éléments de la collection sur laquelles tu boucles. T'es obligé d'itérer sur les clefs et de déréférencer à chaque accès, c'est ignoble.

ce que je voulait dire dans mon pavé mal foutu, c'est que ce que tu peut faire avec le "haut niveau", tu peut le faire aussi bien en "bas niveau" voir meme peut etre mieux car tu n'est pas bridé par le fonctionnement dudit haut niveau

Bien entendu. C'est toujours le même équilibre, aussi vieux que le premier assembleur : temps de développement / temps d'exécution.

spectras :
Oui. Encore que je sais pas comment travaille ruby, mais les foreach de php sont boiteux dès lors que tu veux modifier les éléments de la collection sur laquelles tu boucles. T'es obligé d'itérer sur les clefs et de déréférencer à chaque accès, c'est ignoble.

i.e. tu voudrais qu'ils fassent quoi ?

Ce qu'ils font depuis la dernière version : qu'ils donnent une référence aux éléments itérés, et non une copie.

C'est parce-que PHP n'est pas objet a la base..

Ma remarque est vraie même pour un simple tableau d'entiers ^^

$a = array(1, 2, 3, 4, 5);
foreach($a as $v) {
    if ($v == 3)
        $v = 42;
}
// $a vaut toujours  array(1, 2, 3, 4, 5)

t'es obligé de faire

$a = array(1, 2, 3, 4, 5);
foreach(keys($a) as $k) {
    if ($a[$k] == 3)
        $a[$k] = 42;
}
// $a vaut bien array(1, 2, 42, 4, 5)

Euh le principe d'un itérateur n'a jamais été de modifier la valeur des éléments... :/
Sauf bien sûr dans le cas particulier où tu considères des objets et dans ce cas la valeur est une référence, donc tu peux modifier l'objet... Enfin ça me parâit normal

GoldenCrystal :
Euh le principe d'un itérateur n'a jamais été de modifier la valeur des éléments... :/
Sauf bien sûr dans le cas particulier où tu considères des objets et dans ce cas la valeur est une référence, donc tu peux modifier l'objet... Enfin ça me parâit normal

bah pas en C++...
d'ou les const_iterator et les iterator

Pour les boucles for_each en C++, on retrouve exactement le meme fonctionnement si on utilise des iterators de la STL, c'est juste plus long a ecrire...