Discussion :

[Ulmo]

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

Code :

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

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) ?

[3DArchi]

La norme dit que map[x] retourne

Code :

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

1
2
(*((insert(make_pair(x,T()))).first)).second

Donc, à priori, je dirais :oui. Tu es assuré d'avoir une initialisation à 0.

[Ulmo]

Alors ce que je n'ai pas compris, c'est pourquoi le T() va initialiser à 0.

[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.

[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).

[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.

[r0d]

Mais pourtant

Code :

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

int i;

n'initialise pas i à 0. Enfin pas toujours (par exemple vc++ en mode Debug le fait).

[Ulmo]

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.

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é.

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 :-)

[Jean-Marc.Bourguet]

[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.

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".

[r0d]

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

[screetch]

Code :

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

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
  }
};

[3DArchi]

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 :

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

1
2
 
int i = int();

Est une initialisation.

Code :

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

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.

[Jean-Marc.Bourguet]

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.

[3DArchi]

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 ...

[screetch]

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

[Sylvain Togni]

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.