// voir source jointe // Projet MFC / Visual C++ 6
Télécharger le zip
Je comprends pas bien le mélange entre les threads et la fonction rand(). Je vois vraiment pas l'intérêt de l'exécution simultanée car tous les threads tapent dans la même variable 'nombre'. Et la boucle dans la THREADPROC fait que le programme monopolise 99% du temps processeur.
L'intéret c'est que l'execution des threads n'est pas prévisible, cela ajoute donc du hasard à la fonction rand(), ce qui est bonne idée. Par contre, cela n'a pas l'air pratique ni économique à utiliser dans un autre prog.
certes le programme n'est pas économe, mais c'est une méthode assez svt utilisée en fait. Mais en général, pour avoir un random qui soit un pur hasard on effectue par exemple un ou exclusif entre le rand et le numéro de processus du prog, cela nous donne une variable qui définit un hasard,...disons hasardeux :)
oui, puis on peut aussi prendre l'adresse mac de la carte réseau, l'id du dd sous windows et ainsi de suite... rand ne sort pas un nombre aléatoire normalement ? si oui, pourquoi se casser la tete a en demander + ?
rand() ne renvoit pas toujours des nombres vraiment au hasard. Par exemple, une trame IP contient un champ numérique généré aléatoirement (me demande pas lequel :) ). Si tu analyses des trames générées par Windows, tu remarques au bout d'un certains temps que les nombres aléatoires sont tous les mêmes. Ca permet d'identifier un OS gràce aux trames IP. Bien sûr pour le commun des mortels la fonction rand() suffit amplement.
Avant on pouvait sniffer les packets pour trouver le nombre d'incrementation (j'ai oublié le nom) qui sert a identifier les packets pour faire du connection hijacking, mais sur les OS actuels ces nombres sont plus difficilements prévisibles.
Se souvenir du profil
Mot de passe oublié ? / Activation de compteCréer un compte
1 903 514 membres 92 nouveaux aujourd'hui 16 195 membres club