Discussion :

[Invité]

Bonjour,
Au début je souhaitait simplement générer un nombre aléatoire entre x et y j'ai donc fait une petite fonction et j'aimerais avoir quelque explications concernant ce code : (les nombres générée sont toujours les mêmes ,j'ai beau chercher je ne trouve pas)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
int rand_n(void)
{
	int i = 0;
	BYTE tmp[10] = {0};
 
	while (i < 10){
		tmp[i] = (BYTE)rand() % 9;
		Sleep(200);
		i++;
	}
	return (int)tmp;
}
 
int _tmain(int argc, _TCHAR* argv[])
{
	srand(time(NULL));
	while (1){
		cout << rand_n() << endl;
		Sleep(100);
	}
	getchar();
}

J'aimerais aussi savoir pourquoi les nombre généré par rand sont seulement sur 16 bits ?

Merci.

[Neckara]

Bonjour,

Tu as oublié d'utiliser srand.

[Invité]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int _tmain(int argc, _TCHAR* argv[])
{
	srand(time(NULL));
	while (1){
		cout << rand_n() << endl;
		Sleep(100);
	}
	getchar();
}

srand est bien là , a chaque exécution j'ai un nombre différent mais si j’appelle plusieurs fois cette fonction pendant une même exécution, j'ai toujours la même chose je ne comprend pas et aussi autre chose que je ne comprend pas c'est lorsque j'ajoute des nombres dans mon tableau d'octet les nombres sont par exemple 5,8,7,1,5,0,5,8,5,3 et après le cast j’obtiens : 4716572

[Neckara]

Mea culpa, j'ai pas vu qu'on pouvait scroller le code.

Tu convertis un pointeur (ton tableau est implicitement convertit en un pointeur sur le premier élément) en entier. Tu retournes donc l'adresse de ton tableau.

[Emmanuel Deloget]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int _tmain(int argc, _TCHAR* argv[])
{
	srand(time(NULL));
	while (1){
		cout << rand_n() << endl;
		Sleep(100);
	}
	getchar();
}

srand est bien là , a chaque exécution j'ai un nombre différent mais si j’appelle plusieurs fois cette fonction pendant une même exécution, j'ai toujours la même chose je ne comprend pas et aussi autre chose que je ne comprend pas c'est lorsque j'ajoute des nombres dans mon tableau d'octet les nombres sont par exemple 5,8,7,1,5,0,5,8,5,3 et après le cast j’obtiens : 4716572

srand(time(NULL)) ?

time() ayant une précision de l'ordre de la seconde, cette fonction initialise 10 fois srand() avec la même valeur. Nécessairement, l'appel à rand qui suit va donner 10 fois de suite la même valeur.

(et le % 9, c'est niet : ça rend plus probable l'apparition de certaines valeurs).

Maintenant, puisqu'on est sur un forum C++, pourquoi ne pas utiliser des choses plus... C++ienne ? http://www.cplusplus.com/reference/random/

[Invité]

Mea culpa, j'ai pas vu qu'on pouvait scroller le code.

Tu convertis un pointeur (ton tableau est implicitement convertit en un pointeur sur le premier élément) en entier. Tu retournes donc l'adresse de ton tableau.

Et comment je peut faire pour faire cette conversion ? (tableau d'octets en entier)

srand(time(NULL)) ?

time() ayant une précision de l'ordre de la seconde, cette fonction initialise 10 fois srand() avec la même valeur. Nécessairement, l'appel à rand qui suit va donner 10 fois de suite la même valeur.

(et le % 9, c'est niet : ça rend plus probable l'apparition de certaines valeurs).

Maintenant, puisqu'on est sur un forum C++, pourquoi ne pas utiliser des choses plus... C++ienne ? http://www.cplusplus.com/reference/random/

mon srand n'est pas dans ma boucle.
%9 ? pour avoir un nombre entre 0 et 9 non ?
En faite rand me convient pour l'instant.

[Neckara]

Tu ne peux pas vu que le plus grand entier est (u)int64_t (= 8 octets).

Il te faut donc regarder du côté de bibliothèques permettant de manipuler de grands nombres.
Sinon quel est l'intérêt de transformer ton tableau de nombres aléatoires en un seul entier ?

[Ehonn]

Bonjour

Tu ne peux pas vu que le plus grand entier est (u)int64_t (= 8 octets).

std::intmax_t et std::uintmax_t http://www.cplusplus.com/reference/cstdint/

Si tu cherches à convertir dix chiffres en un seul entier, tu peux le faire (avec un petit calcul) car le plus grand nombre serait 9 999 999 999 et celui-ci passe dans un long long int (au moins de -9 223 372 036 854 775 807 à 9 223 372 036 854 775 807).

Emmanuel Deloget te propose des choses plus «C++ienne», c'est la bonne solution puisque rand() est "à éviter".

rand() retourne un entier entre 0 et RAND_MAX. La norme dit que RAND_MAX est d'au moins 32 767 (comme un int).

Pour information, std::vector (ou std::array selon les besoins) est le bon type pour utiliser des tableaux en C++, tu pourras utiliser ce type comme retour de fonction.

Pour tester rand(), teste le tout seul

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// g++ -Wall -Wextra -Wconversion -std=c++11 -pedantic -O3 -march=native -fopenmp main.cpp -o main && ./main
// g++ -Wall -Wextra -Wconversion -pedantic main.cpp -o main && ./main
 
#include <iostream>
#include <random>
#include <chrono>
#include <cstdlib>
 
 
int main()
{
	// http://www.cplusplus.com/reference/random/
	std::cout << "Solution C++" << std::endl;
	{
		std::default_random_engine engine(std::chrono::system_clock::now().time_since_epoch().count());
 
		std::uniform_int_distribution<int> distribution(0, 9);
 
		for (int i = 0; i < 5; ++i)
		{
			std::cout << distribution(engine) << std::endl;
		}
	}
	std::cout << std::endl;
 
	std::cout << "Solution C" << std::endl;
	{
		srand((unsigned int)(time(0)));
 
		for (int i = 0; i < 5; ++i)
		{
			std::cout << rand() << std::endl;
		}
	}
	std::cout << std::endl;
 
	return 0;
}

[Bousk]

Et pourquoi ne pas faire un seul random ?

[Ehonn]

Avec rand() ? Peut être à cause de la limite de RAND_MAX (selon la distribution voulue) (c'est une supposition).

[Invité]

En faite merci pour cette référence (<random>) mais ça fait encore un include a rajouter (edit: en plus comme je compte utiliser openssl je pense que je n'en aurais pas besoin), je voudrais savoir comment convertir un tableau de byte en int ? et je voudrais aussi savoir pourquoi rand est limité a RAND_MAX ?

[Neckara]

Est-ce que ton tableau de byte représente un nombre en base 10 ou un nombre en base 256 ?

Dans le premier cas, il suffit de parcourir ton tableau de byte et de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
nombre *= 10;
nombre += chiffre;

Dans le second cas, je maintient ce que j'ai dit, le plus grand entier standard est sur 64 bits (uint128_t n'existant pas), il te faut donc passer par une bibliothèque permettant de manipuler les très grand nombres ou de créer ton propre type entier qui sera implémenté par une structure.

[Ehonn]

le plus grand entier standard est sur 64 bits

Plus exactement, est au moins sur 64 bits. int64_t est optionnel.

[Neckara]

Plus exactement, est au moins sur 64 bits. int64_t est optionnel.

Je ne suis pas d'accord.

Certes la norme garantit des tailles minimales et qu'on peut éventuellement avoir des entiers de plus de 8 octets sur des architectures spécifiques.
Mais ce n'est pas parce qu'une machine spécifique a un entier sur 16 octets que les autres machines en auront un aussi.

C'est bien pour cela qu'on a inventé les (u)intXX_t, pour "garantir" une taille "fixe" et ainsi rendre le code plus portable.
Il serait ridicule d'avoir un bout de code (hors embarqué) qui fonctionne sur une architecture spécifique d'ordinateur et pas sur une autre parce que sur l'un les long long int sont sur 10 octets.

Après même si l'architecture ne gère pas les nombres sur 64 bits, on peut toujours implémenter des uint64_t et à part dans l'embarqué sur des µProcesseurs 8/16bits, on ne retrouve pas des uint64_t mais je ne pense pas qu'on en soit là.

Actuellement sur nos ordinateurs, on a pas de uint128_t, donc le plus grand entier est bien uint64_t.
On a aussi des uint_fast64_t qui peuvent être plus grand que 64 bits, mais il ne faut surtout pas l'utiliser dans l'intention de stocker des nombres sur 72 bits par exemple, on a même pas à savoir qu'il est plus grand que 64 bits, juste qu'il peut être plus grand que 64 bits.

[Jean-Marc.Bourguet]

Je ne suis pas d'accord.

Avec laquelle de ces affirmations n'es-tu pas d'accord (pour moi elles sont toutes vraies) ?

1/ Le plus grand entier standard est intmax_t et fait au moins 64 bits.

2/ int64_t n'est pas garanti exister.

3/ Il n'y a aucun type a taille fixe garanti exister.

4/ Les implémentations qui n'ont pas de int64_t sont rares au point d’être anecdotiques et ont vraisemblablement d'autres caractéristiques peu communes, l'ensemble faisant que considerer la portabilite vers ces implementations sans en disposer d'une pour tester est un exercice probablement futile.

5/ Les implementations qui ont un int64_t mais pour lesquelles intmax_t n'est pas int64_t sont possibles, elles ont des chances d'etre plus pertinentes que celle du point 4 mais je n'en connais pas (gcc a un __int128_t mais son intmax_t a 64 bits, je trouve ca bizarre et mais je suppose que c'est du a la difficulte de definir PRIxMAX en particulier pour gcc qui n'est pas lie a la libc).

[Ehonn]

on peut toujours implémenter des uint64_t

Même si cela est aussi "anecdotique", implémenter uint64_t sur une machine qui a un CHAR_BIT qui ne divise pas 64 me paraît compliqué (?)

[Jean-Marc.Bourguet]

Même si cela est aussi "anecdotique", implémenter uint64_t sur une machine qui a un CHAR_BIT qui ne divise pas 64 me paraît compliqué (?)

Pas tant que ca. Il suffit d'utiliser un type nonsigne plus grand puis de masquer tous les resultats. (J'avais oublie que intN_t ne peut pas avoir de bits de padding)

[Ehonn]

Sauf que la taille n'est plus la même. A mon avis, si tu veux un int64_t, tu veux 64 bits, ni plus (ni moins).
Il n'y a pas très longtemps, quelqu'un sur le forum voulait une structure qui faisait exactement la même taille qu'une autre (déjà définie).

[Jean-Marc.Bourguet]

Sauf que la taille n'est plus la même. A mon avis, si tu veux un int64_t, tu veux 64 bits, ni plus (ni moins).
Il n'y a pas très longtemps, quelqu'un sur le forum voulait une structure qui faisait exactement la même taille qu'une autre (déjà définie).

J'avais oublie que intN_t n'autorise pas les bits de paddings.

[Neckara]

Avec laquelle de ces affirmations n'es-tu pas d'accord (pour moi elles sont toutes vraies) ?

1/ Le plus grand entier standard est intmax_t et fait au moins 64 bits.

2/ int64_t n'est pas garanti exister.

3/ Il n'y a aucun type a taille fixe garanti exister.

4/ Les implémentations qui n'ont pas de int64_t sont rares au point d’être anecdotiques et ont vraisemblablement d'autres caractéristiques peu communes, l'ensemble faisant que considerer la portabilite vers ces implementations sans en disposer d'une pour tester est un exercice probablement futile.

5/ Les implementations qui ont un int64_t mais pour lesquelles intmax_t n'est pas int64_t sont possibles, elles ont des chances d'etre plus pertinentes que celle du point 4 mais je n'en connais pas (gcc a un __int128_t mais son intmax_t a 64 bits, je trouve ca bizarre et mais je suppose que c'est du a la difficulte de definir PRIxMAX en particulier pour gcc qui n'est pas lie a la libc).

En tant que développeur, on a pas à savoir qu'un uint_fastXX_t est plus grand qu'un uintXX_t sur notre machine, juste qu'il peut être plus grand.
Donc en tant que développeur et sur les machines actuelles, l'entier le plus grand est uint64_t.

N'oublions pas aussi que si sur un parc de machines on a :

• pas de uint128_t sur 5% d'entre elles ;
• un uint128_t sur 95% d'entre elles.

Quel est l'entier le plus grand pour nous, développeur ? uint128_t ? Donc notre application ne pourra tourner que sur 5% des machines de notre parc ?

Même raisonnement si on a un uint_fastXX_t plus grand qu'un uintXX_t sur 60% des machines.

Si on commence à dire unsigned long long fait 10 octets sur ma machine donc je peux l'utiliser, que va-t-il se passer sur les archi où il faut que 8 octets ?