Il ne s'agit pas forcément de cas si particuliers que ça. Par exemple, les compilateurs sont très bons pour optimiser du code avec des accès réguliers à la mémoire (et le matériel aide aussi quand il peut). Si on doit y rajouter les indirections dues aux objets (accès aux méthodes et membres des classes), tout un tas de if, etc., on peut perdre le compilateur. Même si le branchement est prédit non pris au bout d'un moment, il y a un certain nombre limité de branches qu'il peut conserver en mémoire.
De plus dans le cas de code scientifique par exemple, typiquement un solveur itératif, il n'est pas rare d'avoir des accès de type
for (i=1; i<m ; ++i) {
____for (j = 1; j < n; ++j) {
________v1[i][j] += a + (v1[i][j-1] *v1[i][j+1]) + b + v1[i-1][j] * v1[i+1][j] + ...;
}
Bien entendu il s'agit d'un code factice, mais l'idée est là. On a même des cas où plusieurs vecteurs se mélangent. Dans ce cas précis j'ai pris un tableau 2D, donc le terme de « vecteur » n'est certes pas le meilleur, mais c'était pour illustrer mon propos.
Concernant mon post précédent, je faisais 2 remarques, orthogonales l'une de l'autre :
1/ Un langage n'est pas obligé d'imposer une seule façon de traiter les structures de données, pour tout un tas de raisons (et je prenais C++ en exemple, qui propose les deux mécanismes, à cause de certains problèmes de perf); de plus même si le langage n'impose qu'une seule façon (« Java »), il n'est pas dit que ce soit la seule bonne façon de faire, et la façon de gérer cela par d'autres langages n'est pas nécessairement moins mauvaise : tout dépend des objectifs qu'on se fixe.
2/ Concernant Ruby spécifiquement, renvoyer nil (ou undef en Perl) n'est pas nécessairement une mauvaise chose, et je parlais du fait que parfois j'ai une sortie « imparfaite » de mes scripts Perl, mais « suffisamment bonne » pour que je puisse quand même me servir de ces résultats, ne serait-ce que partiellement (je me sers beaucoup de Perl pour analyser la sortie de fichiers au format CSV ou pas très loin du CSV dumpés par mes programmes, et adapter les données à mes besoins). Par exemple, à cause d'une erreur de ma part, le script peut avoir raté une ligne (je n'avais pas prévu un certain type de format de ligne, et du coup mon script ne sait pas le gérer), mais le calcul en lui-même n'est pas forcément faux pour le reste des autres lignes du fichier que je veux traiter. Dans ce cas je préfère un warning qui me dit que je divise par 0, que j'essaie de faire des trucs avec une variable non-définie, etc, mais que le programme continue de tourner pour pouvoir quand même espérer détecter une tendance par exemple, plutôt qu'avoir un programme qui s'arrête parce que euh, ben, « Y'a une exception, là, et je sais pas quoi en faire, donc je stoppe tout. ».
[^] # Re: Code le toi même
Posté par lasher . En réponse à la dépêche Sortie de Moonlight 1.0. Évalué à 2.
De plus dans le cas de code scientifique par exemple, typiquement un solveur itératif, il n'est pas rare d'avoir des accès de type
for (i=1; i<m ; ++i) {
____for (j = 1; j < n; ++j) {
________v1[i][j] += a + (v1[i][j-1] *v1[i][j+1]) + b + v1[i-1][j] * v1[i+1][j] + ...;
}
Bien entendu il s'agit d'un code factice, mais l'idée est là. On a même des cas où plusieurs vecteurs se mélangent. Dans ce cas précis j'ai pris un tableau 2D, donc le terme de « vecteur » n'est certes pas le meilleur, mais c'était pour illustrer mon propos.
Concernant mon post précédent, je faisais 2 remarques, orthogonales l'une de l'autre :
1/ Un langage n'est pas obligé d'imposer une seule façon de traiter les structures de données, pour tout un tas de raisons (et je prenais C++ en exemple, qui propose les deux mécanismes, à cause de certains problèmes de perf); de plus même si le langage n'impose qu'une seule façon (« Java »), il n'est pas dit que ce soit la seule bonne façon de faire, et la façon de gérer cela par d'autres langages n'est pas nécessairement moins mauvaise : tout dépend des objectifs qu'on se fixe.
2/ Concernant Ruby spécifiquement, renvoyer nil (ou undef en Perl) n'est pas nécessairement une mauvaise chose, et je parlais du fait que parfois j'ai une sortie « imparfaite » de mes scripts Perl, mais « suffisamment bonne » pour que je puisse quand même me servir de ces résultats, ne serait-ce que partiellement (je me sers beaucoup de Perl pour analyser la sortie de fichiers au format CSV ou pas très loin du CSV dumpés par mes programmes, et adapter les données à mes besoins). Par exemple, à cause d'une erreur de ma part, le script peut avoir raté une ligne (je n'avais pas prévu un certain type de format de ligne, et du coup mon script ne sait pas le gérer), mais le calcul en lui-même n'est pas forcément faux pour le reste des autres lignes du fichier que je veux traiter. Dans ce cas je préfère un warning qui me dit que je divise par 0, que j'essaie de faire des trucs avec une variable non-définie, etc, mais que le programme continue de tourner pour pouvoir quand même espérer détecter une tendance par exemple, plutôt qu'avoir un programme qui s'arrête parce que euh, ben, « Y'a une exception, là, et je sais pas quoi en faire, donc je stoppe tout. ».