std::map et initialisation de double

Version imprimable

18/12/2008, 11h17
Ulmo

std::map et initialisation de double
Bonjour,
J'utilise un std::map<int, double> de la façon suivante :
Code:

1 2 3 4 std::map<int, double> sums; while (something) { sums[nextIndex()] += nextValue(); }
Puis-je être assuré que les valeurs initiales seront bien à zéro ?
D'après le code de la STL, la valeur initiale est donnée par le constructeur par défaut. Dans le cas d'un double, il me semble que je ne suis assuré de rien.
Faut-il donc spécialiser l'opérateur d'indexation dans le cas des doubles (et des int le cas échéant) ?
18/12/2008, 12h59
3DArchi
La norme dit que map[x] retourne
Code:

1 2 (*((insert(make_pair(x,T()))).first)).second
Donc, à priori, je dirais :oui. Tu es assuré d'avoir une initialisation à 0.
18/12/2008, 13h07
Ulmo

Alors ce que je n'ai pas compris, c'est pourquoi le T() va initialiser à 0.
18/12/2008, 15h09
3DArchi

[Sous réserves]
Tu as une autre règle qui dit que l'initialisation (double val = double(); ) pour les types scalaires se fait dans ce cas à 0.
18/12/2008, 15h50
r0d

Je n'ai pas le standard sous la main, je ne pourrais donc pas répondre à la question, mais je me demandes si dans ton cas l'utilisation d'une map est la meilleure solution. En effet, si tes clés sont des entiers successifs, pourquoi ne pas utiliser un simple tableau? Tu y gagnerais en simplicité et en vitesse d'exécution (gain sans doute dérisoire certes).

edit: je me demande également si ce ne serait pas plus propre de faire ta boucle en deux temps. Premièrement l'allocation et l'initialisation, et ensuite le remplissage, en utilisant un itérateur plutôt que l'opérateur [].

edit2: le standard ne parle quasiment pas des types primitifs (la seule chose qu'il spécifie c'est une comparaison de leur taille en mémoire), donc T(), lorsque T est un type primitif (ici un double), peut être implémenté différemment selon les compilateurs (implementation defined).
18/12/2008, 17h42
screetch

je ne pense pas que T() soit dépendant de l'implémentation, je suis même sur que ca serait une faute grave du standard.

int i = int(); va initialiser i a 0.
18/12/2008, 17h54
r0d

Mais pourtant

Code:

int i;

n'initialise pas i à 0. Enfin pas toujours (par exemple vc++ en mode Debug le fait).
18/12/2008, 18h15
Ulmo

Citation:

Envoyé par r0d

Je n'ai pas le standard sous la main, je ne pourrais donc pas répondre à la question, mais je me demandes si dans ton cas l'utilisation d'une map est la meilleure solution. En effet, si tes clés sont des entiers successifs, pourquoi ne pas utiliser un simple tableau? Tu y gagnerais en simplicité et en vitesse d'exécution (gain sans doute dérisoire certes).

Mes entiers ne sont pas consécutifs, il y aura des trous dans mon tableau.

Citation:

edit: je me demande également si ce ne serait pas plus propre de faire ta boucle en deux temps. Premièrement l'allocation et l'initialisation, et ensuite le remplissage, en utilisant un itérateur plutôt que l'opérateur [].

Effectivement, je vais plutôt faire quelque chose de ce genre là, la vitesse d'exécution à tranché.

Citation:

edit2: le standard ne parle quasiment pas des types primitifs (la seule chose qu'il spécifie c'est une comparaison de leur taille en mémoire), donc T(), lorsque T est un type primitif (ici un double), peut être implémenté différemment selon les compilateurs (implementation defined).

C'est ce qui m'intéressait principalement. Donc c'est bien un coup de bol si dans mon cas les valeurs de la map sont initialisées à 0.

Merci pour vos réponses :-)
18/12/2008, 18h41
Jean-Marc.Bourguet

Citation:

Envoyé par 3DArchi

[Sous réserves]
Tu as une autre règle qui dit que l'initialisation (double val = double(); ) pour les types scalaires se fait dans ce cas à 0.

Citation:

Envoyé par r0d

edit2: le standard ne parle quasiment pas des types primitifs (la seule chose qu'il spécifie c'est une comparaison de leur taille en mémoire), donc T(), lorsque T est un type primitif (ici un double), peut être implémenté différemment selon les compilateurs (implementation defined).

3DArchi a raison. Pour ceux qui voudraient des references: 5.2.3/2 Indique qu'il s'agit d'une "default-initialization" et 8.5/5 indique ce que c'est une "default-initialization".
18/12/2008, 19h24
r0d

J'ai donc dit une bêtise :oops:
Merci Jean-Marc :D

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
int i; //indéfini
int j = int(); // j = 0
 
class Test
{
  int t1, t2;
  Test()
  : t2()
  {
    // t1 indéfini
    // t2 = 0
  }
};

19/12/2008, 16h50
3DArchi
Citation:

Envoyé par Jean-Marc.Bourguet

3DArchi a raison. Pour ceux qui voudraient des references: 5.2.3/2 Indique qu'il s'agit d'une "default-initialization" et 8.5/5 indique ce que c'est une "default-initialization".

J'ai cru comprendre qu'ils emploient le terme de "zero-initialisation" dans lequel il est explicitement dit que pour les types scalaires l'initialisation est à 0.

Ensuite
Code:

1 2 int i = int();
Est une initialisation.
Code:

1 2 int i;
Est une déclaration sans initialisation. Ici, effectivement, la valeur de i est indéfinie et la norme dit que son utilisation est indéterminée.
19/12/2008, 16h57
Jean-Marc.Bourguet

Citation:

Envoyé par 3DArchi

J'ai cru comprendre qu'ils emploient le terme de "zero-initialisation" dans lequel il est explicitement dit que pour les types scalaires l'initialisation est à 0.

T() est une default-initialization. Pour les types scalaires, une default-initialization est une zero-initialization.

Note: le CD du C++0X introduit des value-initialization et une default-initialization ne devient pas une zero-initialization. Mais 5.2.3/2 a ete aussi modifie pour que T() soit une value-initialization.
19/12/2008, 17h32
3DArchi

Citation:

Envoyé par Jean-Marc.Bourguet

T() est une default-initialization. Pour les types scalaires, une default-initialization est une zero-initialization.

Note: le CD du C++0X introduit des value-initialization et une default-initialization ne devient pas une zero-initialization. Mais 5.2.3/2 a ete aussi modifie pour que T() soit une value-initialization.

OK !
Je trouve 'zero-initialization' beaucoup plus explicite ...
21/12/2008, 11h17
screetch

pour un double, 0.0 n'est pas obligatoirement représenté par des bits a 0
22/12/2008, 11h37
Sylvain Togni

Citation:

Envoyé par screetch

pour un double, 0.0 n'est pas obligatoirement représenté par des bits a 0

Oui mais peu importe, 'zero-initialization' n'est pas défini par la norme par la mise à zéro des bits mais par la conversion de la valeur 0 vers le type scalaire.