"Bah on peut déclarer plus de trucs sur la pile que Java ou Python, c’est sûr. ^ Mais map et fold sont des méthodes qui existent déjà pour certains types en Rust."
Le principal, c'est la mémoire static qui ne devient pas une variable global mais qui lié à chaque site d'appel de la fonction.
Genre tu écris un
pid(e){
static i, past_error;
err = e-s;
i += err;
d = error - past_error;
past_error = error;
return P*e+I*i+D*d;
} //P I D étant des constantes // J'espère que le code est bon :)
Dans le cas habituel, tu as une variable global pour la mémoire "i" et "past_error", si tu appelles 2 fois ce code, cela ne marche plus. Si le static fonctionne pour chaque appel et non globalement, cela marche.
"À mon avis, c’est pas la philosophie de Rust de «modifier» ce que fais le développeur..."
Le compilo ne modifie rien du tout. Si tu utilises un abstractString, tu demandes explicitement au compilo de choisir. Si tu colles une String, tu aura une String.
[^] # Re: idées en plus ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Quelques nouvelles sur Rust à l’occasion de la 0.9. Évalué à 4.
"Bah on peut déclarer plus de trucs sur la pile que Java ou Python, c’est sûr. ^ Mais map et fold sont des méthodes qui existent déjà pour certains types en Rust."
Le principal, c'est la mémoire static qui ne devient pas une variable global mais qui lié à chaque site d'appel de la fonction.
Genre tu écris un
Dans le cas habituel, tu as une variable global pour la mémoire "i" et "past_error", si tu appelles 2 fois ce code, cela ne marche plus. Si le static fonctionne pour chaque appel et non globalement, cela marche.
"À mon avis, c’est pas la philosophie de Rust de «modifier» ce que fais le développeur..."
Le compilo ne modifie rien du tout. Si tu utilises un abstractString, tu demandes explicitement au compilo de choisir. Si tu colles une String, tu aura une String.
"La première sécurité est la liberté"