"exactement Kirva!
son seul inconvénient c'est la grande mémoire!dieu merci qu'on est dans l'époque des 1Go de RAM!
a bientot.."
Justement pour la mémoire il y a une optimisation : on peut juste utiliser un bit par nombre impair, ça diminue par 16 l'espace mémoire requis. Comme ça on gagne 8 ans sur la technologie (loi de Moore). Pour la rapidité je ne sais pas si ça rend plus rapide ou moins (je dirais moins mais on ne sais pas car les opérateurs << et >> sont extremement rapides).
Ben si, et c'est même très facile à prouver (ce qui ajoute à l'élégance de la démonstration ^^). Mais on parle ici de trouver tous les nombres premiers dans un intervalle fini, et ça, il y en a un nombre fini.
Peux-tu me donner un lien vers un site qui expliquerait l'algorithme de sieve, SVP ? Je n'en ai pas trouvé sur BibMath ni d'autres algo donnant et/ou calculant la suite des nombres premiers. Et ça m'intéresse. Merci.
Pour ma part je pense que le GC a tout à fait sa place dans les langages managés qui se veulent rapide et sure en terme de développement.
Maintenant il est sure qu'un "vrai logiciel" (à mon sens) a tout interet à etre codé en C/C++/ASM tout court.
+1 pour brunews, autant pour le café que pour le garbage collector :) et j'adore le café.
C'est une question d'habitude on va dire, garbge collector ou pas ... Mais je me sens terriblement impuissant quand je programme avec un GC personnellement :/. La gestion de la mémoire est vrmnt un souci central quand on programme. C'est déjà compliqué de savoir quand l'argument est passé par valeur ou par référence en Java O_o.
Du reste, le petit détail de syntaxe qui vous occupe est une extension GCC je crois. Suffit de ne pas l'utiliser.
Au fait: le screenshot est peut-être pas super utile, et bon ... "grande rangée", ça reste à voir. Pour les nombres premiers, couvrir tous les nombres représentables avec un int est assez standard, donc ne nous emballons pas ;).
Il y a des gens qui disent que "Java est une réligion".
Pas moi, mais je comprends ce qu'ils veulent dire. C'est le goût et l'extase de la programmation.
Personnellement, Je déteste le café et tout ses dérivées
void alala() {
int d = 50;
char *c = __alloca(50);
c[0] = 48;
}
la zone est bien dans la pile
je trouve ça utile, à part le fait d'appeler __alloca
(pourquoi pas un
sub $50, %esp
directement au lieu d'appeler __alloca ??)
Moi aussi j'ai du mal à comprendre comment ce genre de syntaxe peut etre géré efficacement dans un programme de plus grande échelle. D'ailleurs tu devrais etre content Brunews, mais apparement ce genre d'ecriture ferait partie des futures normes du c++ (selon un pote en iut info, qui le tient d'un de ses profs). On leur apprend même a utiliser l'ecriture ci dessus O_o
A remplacer bien evidemment par un char *flag = (char*)malloc (d*sizeof(char)) puis free (flag) en fin de programme, pour rester dans du C propre et portable. D'ailleurs ca ne compile pas sous visual C++ 6.
salut,
vraiment c'est formidable on ressent vraiment que le monde est vivant
avec 4 commentaires,merci pour votre soutien les gars.
je vous promis toujours mon meilleur possible!
Voila un exemple d'optimisation avec la mémoire. En plus avec les opérateurs basiques (&, |, <<, >>) on gagne beaucoup en vitesse.
son seul inconvénient c'est la grande mémoire!dieu merci qu'on est dans l'époque des 1Go de RAM!
a bientot.."
Justement pour la mémoire il y a une optimisation : on peut juste utiliser un bit par nombre impair, ça diminue par 16 l'espace mémoire requis. Comme ça on gagne 8 ans sur la technologie (loi de Moore). Pour la rapidité je ne sais pas si ça rend plus rapide ou moins (je dirais moins mais on ne sais pas car les opérateurs << et >> sont extremement rapides).