Quelqu’un pourrait m’expliquer l’intérêt que les variables soient constantes par défaut dans ce langage ? Dans ce que je programme, il y a rarement plus de constantes que de variables. Du coup je n’y vois qu’un allongement inutile de la syntaxe.

Encore merci pour vos réponses.

BarbossHack a dit:

Et au final après quelques temps à coder comme ça tu te rendra compte qu’assez peu de variables ont vraiment besoin d’être mutables.

Quand je lis ça, je pense effectivement aux variables que l’ont crée pour condenser l’écriture du code qui vient derrière, genre éviter d’écrire partout truc.machin.bidule.chose et remplacer ça par une seule variable, qui n’existe d’ailleurs plus forcément une fois compilé. Ou celles destinées à seulement stocker la valeur de retour d’une fonction. Possible que j’en sous-estime leur nombre en effet.

Et oui on ne nomme pas une variable i, j’ai pour habitude de leur donner des noms explicites sans compter les caractères.

Uther a dit:

On ne peut avoir une seule référence mutable active a la fois sur une valeur, ça permet d’interdire les accès concurrent a une variable. A l’inverse un nombre illimité de référence peuvent accéder à une valeur, à condition de ne pas la modifier.

C’est un principe que je comprends mieux (vu que ça désigne souvent des ressources partagées) et qui ne devrait pas me poser de problème, j’utilises déjà beaucoup les références et pointeurs constants. Là comme ça j’ai juste un peu peur que ça pose des problèmes d’interopérabilité avec des binaires écrit dans d’autres langages (et donc avec d’autres paradigmes de programmation).

ben51 a dit:

Oublie la boucle for et passe au récursif final.

On peut toujours transformer un code itératif en code récursif, et inversement. Mais le choix d’utiliser l’un ou l’autre, et la clarté de la syntaxe finale, dépend grandement du problème posé. Je n’ai pas connaissance qu’une méthode soit universellement meilleure qu’une autre.

(quote:1874004:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Ca me rappelle le bon temps du C++ où tu pouvais avoir un pointeur constant vers un objet mutable ou un pointeur mutable vers un objet constant, ou les deux, selon que tu écrivais const MyClass p1 ou MyClass const p2

Tu sais que ce bon temps existe toujours, pour pas mal de gens. Et il ne me gêne pas le moins du monde.

(quote:1874059:brice.wernet)
Non, pas avec les passages de pointeurs. On peut accéder à une variable via un pointeur direct ou indirect dans une structure. Et avec des éléments de langage comme les lambdas + les outils de parallélisation, on peut aller dans des bugs sympatiques…

Si c’est une structure passée en argument par pointeur, ce n’est pas une variable locale puisqu’elle vient de l’extérieur. Une variable locale c’est une variable déclarée à l’intérieur d’une fonction, elle est crée au début de la fonction et détruite à la fin, et aucun autre code que cette fonction ne peut y accéder à moins que la fonction ne passe son adresse à une autre fonction, chose qu’il ne faut faire que si on est sûr que la deuxième fonction ne va pas garder cette adresse après s’être terminée.

(quote:1874184:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Et je dois vérifier, mais je crois qu’il y avait un goto quelque part dans ce code :-) Stricto sensu, il y avait une machine à états finis, est-ce qu’une transition peut être considérée un goto ?

Quand je dis goto, je veux dire écrire réellement goto dans le code. Les machines à états, je fais habituellement ça avec un switch plus ou moins gros dans une boucle infinie (ou presque), on pourrait l’assimiler à un goto. Après s’il y a un intérêt particulier à faire un goto et que ça ne rend pas le code illisible, y a qu’à en faire un, je dis juste que je n’ai jamais eu besoin d’en faire.

(quote:1874196:brice.wernet)
Oui, parce que la variable locale est créée sur la pile, et qu’un fois revenue au niveau de l’appelant, une prochaine routine appelée risque de reprendre cet emplacement mémoire.

Donc une variable locale.

Malheureusement, on manipule souvent des types qui sont passés par référence dans la plupart des langages, s’ils sont mutables, c’est risqué.

Donc une variable pas locale, et donc des règles d’utilisation différentes. D’ailleurs en C++ les références ou pointeurs sont très souvent passées en const pour éviter (une partie) des problèmes, mais personne ne fait l’effort de déclarer ses variables locales en const car l’intérêt est plutôt limité, d’où ma question au sujet du Rust.

Par ailleurs, certains langages permettent d’enfreindre cette règle très facilement (notamment avec la programmation par “promesses” ou avec des lambdas): les lignes de codes ne sont pas forcément exécutées dans l’ordre dans lequel on les voit.

Il faut toujours faire très gaffe avec les lambdas, se demander où elles peuvent finir, et quelles sont les variables capturées puisque la capture transforme des variables locales en non locales. Est-ce que c’est plus facile en Rust de ne pas se planter, je ne sais pas, c’est possible.

(quote:1874274:brice.wernet)
J’ai tenté de voir comment C# faisait pour ces captures: je n’ai pas compris. Il se comporte comme si la variable étaient maintenue à sa dernière valeur connue avant de quitter la routine, et les threads l’utilisent correctement APRES la sortie. Si je tente de l’écraser avec d’autres appels à des routines, elle n’est pas écrasée - donc la pile n’est pas réutilisée de façon simple comme en C.

En fait, plutôt que de chercher comment ça se comporte, je trouve plus simple de savoir comment c’est fait en réalité pour en mesurer directement les implications.

Quand le compilateur voit un lambda qui capture une variable locale, il remplace la déclaration de cette variable locale par une instance d’une classe anonyme dont la variable locale est un champ, et le lambda une méthode membre. Tous les accès hors lambda à la variable précédemment locale sont remplacés par un accès au champ de cette instance.

Ainsi, la déclaration int a = 0; devient (je mets des noms mais en vrai il n’y en a pas) :
class Anonymous
{
int var = 0;
type_retour lambda(arguments) { code }
}

Anonymous a = new Anonymous();

Les accès hors lambda deviennent a.var, et l’affectation devient a.var = val. Dans le lambda, var est directement accessible.

En appliquant les règles classiques de cycle de vie et de visibilité, on voit bien que la même instance de la variable précédemment locale est disponible à 2 endroits : dans le bloc où elle a été déclarée, et dans le lambda. Donc toute modification de sa valeur, que ce soit dans hors lambda (et ce même après la création du lambda), ou dans le lambda, aura un effet dans le code qui sera exécuté après et qui a accès à cette instance, qu’il soit hors lambda ou dans le lambda. On comprend mieux aussi le cycle de vie de cette instance, notamment pourquoi repasser plus tard dans ce bloc après en être sorti créera une nouvelle instance distincte de la première.

Il y a un cas un peu particulier à envisager, et qui d’ailleurs a fait l’objet d’une modification de comportement sur je sais plus quelle version : les variables déclarées entre les parenthèses des instructions for et foreach. Au début, le compilateur les traitait comme si elles étaient en dehors du bloc qui suit le for. Mais du coup, ça ne marchait pas avec les lambdas déclarés à l’intérieur de la boucle, puisqu’alors une seule instance de la classe anonyme était créée hors du bloc, passée à tous les lambdas lors de l’itération, donc tous les lambdas se retrouvaient avec la valeur qu’avait la variable après la dernière itération.

La solution était alors simplement de déclarer, avant le lambda, une variable locale en y affectant la valeur de la variable d’itération, et la donner au lambda. Ainsi, c’est la variable locale qui est remplacée par la classe anonyme et non la variable d’itération, et à chaque itération, une nouvelle instance de la classe anonyme est créée, et chaque lambda reçoit une valeur différente. Plus tard, ce comportement a été considéré comme contre-intuitif et le compilateur a été modifié pour considérer la variable d’itération comme étant déclarée au début du bloc au lieu de juste avant, ce qui a résolu le problème sans rupture de compatibilité.

Si tout ce que je dis n’est pas clair, un exemple ici. Comparer le code de la question avec celui de la 3ème réponse, et la 1ère réponse illustre la solution citée ci-dessus.

Et là j’ai pris l’exemple d’une variable locale capturée, mais il se passe la même chose si on capture une variable plus globale mais accessible (par exemple un membre de la classe parente), avec des effets bien plus dévastateurs vu la portée augmentée. Si on a quand-même besoin de le faire, la solution est la même que pour la boucle for, ajouter une variable locale pour que ce soit elle qui soit capturé et non la variable globale.

(quote:1874274:brice.wernet)
Ca devient ahurissant pour tout le monde le nombre de choses à penser/apprendre/comprendre quand on programme. Perso j’ai commencé il y a longtemps et j’ai appris au fur et à mesure que ça devenait “courant”, je ne sais pas comment font les nouveaux programmeurs.

Je pense qu’ils font comme tu as fait, ils apprennent au fur et à mesure, car même pour les choses qui existent déjà, on ne s’essaie pas à tout d’un coup, et on se fait toujours avoir plus ou moins par une seule chose à la fois.

(quote:1874274:brice.wernet)
Enfin, en vrai, si, je vois comment ils font: mal.

Ca c’est surtout du au fait que pas mal de langages dits “simples” (non, pas Rust) abstraient des concepts réels derrière des trucs plus ou moins intuitifs et magiques. Déjà ça n’encourage pas la rigueur, mais surtout, les choses réelles, même cachées, se produisent quand même, et selon la loi des abstractions qui fuient, il y a toujours des cas particuliers où soit ça merde, soit le concept réel fait que l’abstraction ne se comporte pas on le penserait. Et là, bonne chance à eux pour comprendre pourquoi s’ils n’ont pas un minimum d’idée de ce qui se passe derrière.