Discussion :

[iori11]

Bonjour,

J'aimerais créer une map avec pour valeur un tableau de double de taille fixée, et je n'arrive pas à initialiser ma map.

Pour un double, je fais:

Code :

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

1
2
3
4
5
6
7
8
 
// déclaration
 
map<A*,double> mymap;
 
//initialisation
 
mymap = map<A*,double>();

Mais pour un tableau double[20] ??!

Je ne trouve rien... Est-ce trop tordu d'avoir un tableau en valeur d'une map?

[ptyxs]

Je ne comprends pas bien ta question. Que représente ton 'A' ?
Une map associe une 'clé' à une 'valeur', quelles seraient au juste les clés et les valeurs de ta map ?

[iori11]

La clé serait un pointeur vers un objet de classe A.
Et la valeur serait un tableau de double.

[Goten]

Code :

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

map<A*, std::vector<double> > myMap;

Ou alors j'ai pas compris ce cque tu voulais. Peut être une taille fixe et connu à la compilation?

[iori11]

Code :

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

map<A*, std::vector<double> > myMap;

Ou alors j'ai pas compris ce cque tu voulais. Peut être une taille fixe et connu à la compilation?

oui, une taille fixe... En fait, mon vrai objectif est de pouvoir accéder facilement sur le ième élément de mon tableau de double.

[Arzar]

Je ne trouve rien... Est-ce trop tordu d'avoir un tableau en valeur d'une map?

Non, pas du tout, c'est assez raisonnable. Le problème c'est que ce sont les tableaux à taille fixe du C qui sont tordus.

Par exemple tu obtiendrais la même erreur avec le code suivant :

Code :

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

1
2
3
4
 
double d1[20];
double d2[20];
d1 = d2; // erreur ici !

Pour des raisons historiques, qui remontent aux années 70, les tableaux du C se comportent très différement de... absolument tout le reste. Par exemple, on ne peut pas les affecter ou les copier. On ne peut pas les placer dans des conteneurs (car il faudrait pouvoir les copier). Ce sont en fait des sortes de pointeurs déguisés. Le problème c'est qu'ils sont profondement enracinés dans le langage et on ne peut pas y faire grand chose.

Si tu veux éviter les ennuis, le plus simple est d'utiliser leur équivalent C++ :

std::vector pour des tableaux dynamiques (redimensionnables) et plutôt de grande taille. Equivalent C : double d = new double[size]

std::array, qui n'est malheureusement disponible que sur les compilateurs assez récent ou dans Boost, pour les tableaux de taille fixe et plutôt de petite taille. Equivalent C : double d[20];

std::vector et std::array peuvent être mis sans problème dans un conteneur, et possèdent la même sémantique qu'un type de base comme int ou float ( on peut les copier, les affecter etc...). Ils s'utilisent comme leur équivalent C, par contre ils sont un peu plus lourd à déclarer.



HS : Quelqu'un connait-il la justification historique pour laquelle les tableaux du C se comportent si bizarrement ? Je suppose que c'est pour des raisons de performance - à l'époque le passage d'un tableaux par valeur ne devait même pas être concevable vu la taille de la mémoire disponible - mais en vérité je n'en sais trop rien.

[metagoto]

HS : Quelqu'un connait-il la justification historique pour laquelle les tableaux du C se comportent si bizarrement ? Je suppose que c'est pour des raisons de performance - à l'époque le passage d'un tableaux par valeur ne devait même pas être concevable vu la taille de la mémoire disponible - mais en vérité je n'en sais trop rien.

C'est une bonne et légitime question
des éléments de réponse ici, par Mr Ritchie en personne
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
A partir de Embryonic C

The solution constituted the crucial jump in the evolutionary chain between typeless BCPL and typed C. It eliminated the materialization of the pointer in storage, and instead caused the creation of the pointer when the array name is mentioned in an expression. The rule, which survives in today's C, is that values of array type are converted, when they appear in expressions, into pointers to the first of the objects making up the array.

This invention enabled most existing B code to continue to work, despite the underlying shift in the language's semantics. The few programs that assigned new values to an array name to adjust its origin—possible in B and BCPL, meaningless in C—were easily repaired. More important, the new language retained a coherent and workable (if unusual) explanation of the semantics of arrays, while opening the way to a more comprehensive type structure.

Apparemment c'est un degré d'abstraction supérieur des pointers du C par rapport à B et BCPL nécessaire pour manipuler des structures complexes. Le fait que les pointers ne sont plus calqués sur des words mais sur les objets du array (possiblement complexes). "how could I handle the technical problem of properly initializing these pointers when allocating a complicated object, perhaps one that specified structures containing arrays containing structures to arbitrary depth? ".

[Arzar]

Mon dieu.
Alors cette vilaine épine qu'on se traine depuis des décennies.... c'était pour garder la compatibilité avec le B !!