Discussion :

[wafiwafi]

Bonjour,
Une petite question!
Pourquoi dans le cas d'une création d'un tableau d'objets, on fait appel obligatoirement au constructeurs sans arguments?
j'ai mis en pluriel "constructeurs" puisqu'un tableau peut contenir des objets de différents types (cas de l'héritage par exemple où il arrive qu'on référencie les objets par la classe mère.). D'ailleurs, je pense que c'est la raison des appels des constructeurs sans arguments; question de suivre une même politique et surtout de s'y trouver du point de vue création des différents objets dans le tableau; mais je ne suis pas sûr.
Merci à vous

[r0d]

Bonjour,

si j'ai bien compris ce que tu as dit, tu as raison.
Lorsqu'un tableau est instancié, il va allouer la mémoire nécessaire. Pour cela, et à cause de certaines contraintes du c++ (en particulier celle de la contigüité des éléments en mémoire), c'est le constructeur par défaut (ce que tu appelles toi "constructeur sans argument") qui va être utilisé pour calculer cette allocation de mémoire.

En vérité, dans un tableau C++, que ce soit un std::vector ou un tableau "C-style", tous les objets sont du même type. Lorsque tu fais allusion au stockage d'objets qui héritent d'une classe mère, en vérité, les éléments du tableau sont tous des pointeurs sur la classe mère, ce qui est un type à part entière (ce qui peut porter à confusion, c'est que le downcast est implicite en c++, donc parfois on a l'impression de stocker un pointeur sur une Fille alors qu'en vérité c'est un pointeur sur une Mere que l'on stocke).

[wafiwafi]

Merci pour ta réponse.

Lorsqu'un tableau est instancié, il va allouer la mémoire nécessaire. Pour cela, et à cause de certaines contraintes du c++ (en particulier celle de la contigüité des éléments en mémoire), c'est le constructeur par défaut (ce que tu appelles toi "constructeur sans argument") qui va être utilisé pour calculer cette allocation de mémoire.

Tu parles de la contigüité en mémoire des objets du tableau?
Comme tu le sais certainement, cette contiguïté est une vision conceptuelle que le compilateur/runtime fournit à l'utilisateur. Logiquement et puisqu'il s'agit de vision, elle ne participe pas à la réalité et donc je ne vois pas son intérêt dans la question (appel du constructeur par défaut); mon raisonnement est personnel et peut être erroné; tu veux certainement dire un truc que je n'ai pas compris.
Pour moi, quand tu appelles un constructeur, il y a appel de code pour chaque objet. Et il vaut mieux appeler un seul code pour les objets de même type qu'allers chercher en mémoire un code pour chaque objet. C'est peut être une question d'optimisation (accès mémoire, branchements, importation de codes, ...
Bien à toi

[Klaim]

Comme tu le sais certainement, cette contiguïté est une vision conceptuelle que le compilateur/runtime fournit à l'utilisateur. Logiquement et puisqu'il s'agit de vision, elle ne participe pas à la réalité et donc je ne vois pas son intérêt dans la question (appel du constructeur par défaut); mon raisonnement est personnel et peut être erroné; tu veux certainement dire un truc que je n'ai pas compris.

Cette contiguïté n'a rien de conceptuelle, du moins pas en C et en C++. Les objets sont réellements contigü en mémoire, d'où la rapidité d'accès aléatoire et les contraintes liées.
Dans d'autres languages, elle peut être effectivement conceptuelle. Ce n'est pas le cas ici.

Pour moi, quand tu appelles un constructeur, il y a appel de code pour chaque objet. Et il vaut mieux appeler un seul code pour les objets de même type qu'allers chercher en mémoire un code pour chaque objet. C'est peut être une question d'optimisation (accès mémoire, branchements, importation de codes, ...

Je ne suis pas sur de comprendre ce que tu veux dire par là. Un constructeur "construit" une seule et unique instance d'objet. Si tu as n objects dans ton tableau, tu dois appeler forcément n constructeurs par défaut, un pour chacun de ces objets.

Quand il sagit de pointeurs, ce sont les pointeurs qui sont construits. Si ce sont des pointeurs vers une classe mère d'autres classes, alors on peut assigner ces pointeurs à des instances de classes filles. Mais le tableau lui ne contiens bien que des pointeurs.

[JolyLoic]

Bonjour,
Une petite question!
Pourquoi dans le cas d'une création d'un tableau d'objets, on fait appel obligatoirement au constructeurs sans arguments?

Parce qu'il faut bien en appeler un, et qu'il serait plus difficile de prévoir une syntaxe pour spécifier une valeur d'argument à chacun des éléments d'un tableau (à noter qu'avec C++0x, une telle syntaxe existera). A noter que si tu utilises des vecteurs, tu peux déjà construire les éléments par copie d'un élément de référence, plutôt que par le constructeur par défaut. Et qu'avec des tableaux à la mode C et des objets de type POD, tu peux aussi les initialiser directement (mais je suis moins certain).

j'ai mis en pluriel "constructeurs" puisqu'un tableau peut contenir des objets de différents types (cas de l'héritage par exemple où il arrive qu'on référencie les objets par la classe mère.)

Non. Un tableau ne contient qu'un seul type.

[koala01]

Merci pour ta réponse.


Tu parles de la contigüité en mémoire des objets du tableau?
Comme tu le sais certainement, cette contiguïté est une vision conceptuelle que le compilateur/runtime fournit à l'utilisateur. Logiquement et puisqu'il s'agit de vision, elle ne participe pas à la réalité

Absolument pas

S'il est vrai qu'il s'agit d'une vision de la manière dont la mémoire est représentée, elle participe néanmoins activement à la manière dont les différents éléments sont placés en mémoire:

En effet, si un objet est de taille T et que tu déclares un tableau d'éléments dont le premier se trouve à l'adresse M, le deuxième doit se trouver à M + T, le troisième à M + (2 * T) et ainsi de suite.

Deux éléments successifs de tableau ne prendront jamais place ailleurs qu'en deux adresse mémoire successives, en considérant comme successives le fait que deux adresses mémoires ne soient séparées que de exactement le nombre d'adresses nécessaire pour représenter l'ensemble des informations d'un objet.

Il y a, il est vrai, un phénomène d'alignement qui assure le fait qu'un type primitif dont le nombre de bytes correspond à ce qu'un ordinateur peut traiter avec un registre se trouvera systématiquement à une adresse qui est multiple du nombre de byte traitable par le registre en question, mais les adresses restent tout à fait contigües:

Si le phénomène d'alignement fait que la taille d'une structure proche de

Code :

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

1
2
3
4
5
6
struct S
{
    char c1; // 1 byte
    int i;   // évalué à 4 bytes
    char c2; // 1 byte
};

sera évaluée, sur une architecutre 32 bits, à 12 bytes, afin d'assurer l'adressage par multiples de 4 (qui est le nombre de bytes gérables en une fois par un registre); il n'en demeure pas moins qu'un tableau de 2 S utiliisera les adresses allant de M+0 à M+11 pour le premier et de M+12 à M+23 pour le second.

et donc je ne vois pas son intérêt dans la question (appel du constructeur par défaut); mon raisonnement est personnel et peut être erroné;

Il est, effectivement erroné, principalement parce que basé sur une idée fausse

Pour moi, quand tu appelles un constructeur, il y a appel de code pour chaque objet. Et il vaut mieux appeler un seul code pour les objets de même type qu'allers chercher en mémoire un code pour chaque objet. C'est peut être une question d'optimisation (accès mémoire, branchements, importation de codes, ...
Bien à toi

C'est effectivement aussi une raison possible

[3DArchi]

Et qu'avec des tableaux à la mode C et des objets de type POD, tu peux aussi les initialiser directement (mais je suis moins certain).

Oui, si ce n'est qu'un type POD n'a pas de constructeur défini par l'utilisateur.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct point
{
    int x;
    int y;
};
 
int main()
{
    point tableau_c_pt[]={
        {1,2},
        {3,4}
    };
    return 0;
}

à noter qu'avec C++0x, une telle syntaxe existera

Ca fera certainement parti des évolutions les plus appréciables.
code C++0x déjà compilable avec gcc 4.4.X (pas testé avec visual 10) :

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
#include <string>
#include <vector>
struct my_struct
{
   my_struct(){}
   my_struct(std::string s_):i{0},s(s_){}
   my_struct(int i_):i{i_}{}
   my_struct(int i_, std::string s_):i{i_},s(s_){}
 
   int i;
   std::string s;
};
int main()
{
   std::vector<my_struct> vect={
      1, // appel de my_struct(int)
      std::string("tutu"), // appel de my_struct(std::string)
      {1,std::string("1")}, // appel de my_struct(int, std::string)
      {} // appel de my_struct()
   }; // vecteur de 4 éléments !
   return 0;
}

C'est pas C++0x ?

[Klaim]

code C++0x déjà compilable avec gcc 4.4.X (pas testé avec visual 10) :

Ca ne fera pas partie des features C++0x dispo dans vc10. Peut être dans un Service Pack futur, sait on jamais.

[koala01]

Ca ne fera pas partie des features C++0x dispo dans vc10. Peut être dans un Service Pack futur, sait on jamais.

Il faut l'espérer...

Mais, tant que la norme n'est pas finalisée...

[wafiwafi]

Je vous remercie pour toutes ces réponses.
Néanmoins, un dilemme m'est posé!
Lors d'une discussion au forum Langages, j'ai posé une question qui s'intitule :
Le fichier binaire produit par le compilateur
Le message date du 10/10/2009.
Le dernier intervenant en question est Mac LAK.
Je vous invite à regarder le dernier message posté qui explique le fonctionnement mémoire/ compilateur; il n'est pas du tout en phase avec vous.
Je vous laisse d'abord le lire et me dire votre avis.

[koala01]

Ce que dit Mak Lak (son intervention est ==>ici<== pour ceux qui auraient la flegme de chercher ) est tout à fait juste, mais l'un n'empêche pas l'autre, tu as en fait affaire à deux principes totalement transversaux

En effet, tu n'a aucune possibilité de prévoir l'adresse à laquelle commencera l'en-tête de ton fichier exécutable une fois qu'il sera chargé en mémoire...

Tout ce dont tu es certain, c'est que si

• l'en-tête fait 80 bytes, que
• la table d'importation en fait 200, que
• la table de relocation en fait 100, que
• le segment code en fait 1000 et que
• le segment donnée en fat 500,

(toutes valeurs prises au hasard

Quelle que soit l'adresse à laquelle l'exécutable sera chargé en mémoire, (que

• nous représenterons par M pour la facilité),
• l'en-tête s'étendra de M à M+79 inclus,
• la table d'importation s'étendra de M+80 à M+279 inclus,
• la table de relocation s'étendra de M+280 à M+379 inclus,
• le segment code s'étendra de M+380 à M+1379 inclus et
• le segment données s'étendra de M+1380 à M+1879 inclus.

Mais, quelle que soit la valeur de M, si tu as, dans le segment données un tableau de trois entiers (considérés comme faisant 4 bytes chacun, toujours pour la facilité de la démonstration) commençant à 100 bytes du début du segment data, il commencera, quoi qu'il arrove à l'adresse M+1380 (début du segment data) +... 100 (allez, ca fait à M+1480 et s'étendra sur... 12 bytes, (donc jusqu'à M+1491 inclus).

C'est la raison pour laquelle tu constatera (retour à du code) qu'un code proche de

Code :

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

1
2
3
4
5
6
7
 
int main()
{
    int tab[3]; // voila le tableau
    cout<< tab; // on affiche... l'adresse du premier élément du tableau
    return 0; 
}

t'affichera des valeurs très différentes d'une exécution à l'autre, le programme étant chargé en mémoire à des adresses différentes selon les circonstances

Qu'il s'agisse d'un tableau créé statiquement (sans recours à l'allocation dynamique) ou non ne changera, au final, pas grand choses:

seul la manière dont l'espace mémoire nécessaire à la représentation de ce tableau sera géré sera différente, mais, quoi qu'il arrive, s'il faut 12 bytes pour représenter ce tableau et que le premier élément se trouve à une adresse M, ton tableau s'étendra entre M et M+11 inclus.

Si tu as interprété ce que disait Mak Lak autrement, c'est que tu as mal interprété ses écrits

[wafiwafi]

Je te remercie pour ces écrits intéressants.
Si si, j'ai compris les dires de Mak Lak en sens que le compilateur travaille avec des adresses mémoires relatives et non en dur. Il a parlé de relocation mais je ne savais que cela se passait de cette manière.
J'ai remarqué que ta relocation se fait comme de simples translations des différentes zones (segment code, segment données,....). J'ai du mal à l'accepter mais tu as certainement raison. Le Runtime connait l'os et y est adapté!
D'autre part, Si je prend l'exemple du segment data, et si mes rappels sont bons, on aura la pile et le tas. Si un utilisateur propose de programmer une structure de donnée tel qu'un tableau. Supposons qu'il utilise des pointeurs afin de proposer à l'utilisateur finale une implémentation contigüe du tableau. Si j'ai bien compris, les emplacements mémoires seront réellement contigües?
Le compilateur respecte le choix du programmeur?
Si c'est le cas, c'est un grand plus attribué à C++ par rapport à java même s'il ne s'agit pas de la même philosophie.
Voila une discussion qui m'a révélé autre chose. Mais j'espère me tromper.
La discussion est La programmation des structures de données

[wafiwafi]

Je viens de me rendre compte que la discussion que j'ai évoqué concerne java. Ce qui change tout suite à la présence de la JVM, qui fait à sa sauce. Mais il serai intéressant de voir le cas de C++.

[koala01]

Je te remercie pour ces écrits intéressants.
Si si, j'ai compris les dires de Mak Lak en sens que le compilateur travaille avec des adresses mémoires relatives et non en dur. Il a parlé de relocation mais je ne savais que cela se passait de cette manière.
J'ai remarqué que ta relocation se fait comme de simples translations des différentes zones (segment code, segment données,....). J'ai du mal à l'accepter mais tu as certainement raison. Le Runtime connait l'os et y est adapté!

C'est simplifié, mais c'est, à peu de choses près, effectivement une "simple relocation"...

D'autre part, Si je prend l'exemple du segment data, et si mes rappels sont bons, on aura la pile et le tas. Si un utilisateur propose de programme une structure de donnée tel qu'un tableau. Supposons qu'il utilise des pointeurs afin de proposer à l'utilisateur finale une implémentation contigüe du tableau. Si j'ai bien compris tes dires, les emplacements mémoires seront réellement contigües?
Le compilateur respecte le choix du programmeur?

Si le programmeur demande un tableau d'objet contigus en mémoire, il aura, effectivement un tableau d'objet contigus en mémoire...

On s'en rend plus facilement compte en C, où l'on demande l'allocation dynamique d'un tableau sous la forme de

Code :

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

Type * tab=malloc(nb_element*sizeof(Type) );

qui demande réellement d'allouer un bloc mémoire dont la taille est suffisante pour représenter l'ensemble des objets du tableau.

Lorsque tu utilise new en C++, le phénomène est strictement identique

[wafiwafi]

Tu viens de me fournir une autre vision de ce côté mémoire et je t'avoue que je la préfère sur le raisonnement sur une vision fourni à l'utilisateur.
Certaines discussions m'ont donné l'impression de l'inverse; je vais donc piocher et venir avec quelques unes pour que mise au point soit faite.
En tout cas un grand merci.
As tu visité la discussion que j'ai fourni?

Je reviendrai donc très bientôt!

[3DArchi]

Salut,
J'ai l'impression qu'il y a 2 notions mélangées :
-> La norme C++ garantit qu'un tableau (T[n] ou new T[n]) possède n éléments continus de type T ;
-> L'O.S., sa gestion de la mémoire virtuelle et l'association d'une pile et d'un tas.
Le compilateur fait l'articulation entre les deux et c'est pour ça qu'il cible un OS particulier.

[wafiwafi]

Justement, c'est tout le problème!! Le compilateur/runtime doivent s'aligner à l'os. Mais l'os gère des pages et le compilateur/runtime gère (allez en 98%) ce qui se passe à l'intérieur des pages. La mémoire virtuelle n'est donc pas une affaire de compilateur/runtime mais d'os.
La pile et le tas est plus une affaire de compiltaeur/runtime, l'os ne fait qu'accorder des quantités de mémoire au runtime.
Encore une fois je peux me tromper.
Êtes vous allés à la discussion que j'ai indiqué auparavant et qui dit le contraire?
ça serait intéressant d'en débattre pour éclaircir les idées. Je vous avoue que tout cela est floue.
Bien à vous

[r0d]

Justement, c'est tout le problème!! Le compilateur/runtime doivent s'aligner à l'os. Mais l'os gère des pages et le compilateur/runtime gère (allez en 98%) ce qui se passe à l'intérieur des pages. La mémoire virtuelle n'est donc pas une affaire de compilateur/runtime mais d'os.
La pile et le tas est plus une affaire de compiltaeur/runtime, l'os ne fait qu'accorder des quantités de mémoire au runtime.

Effectivement, la pile et le tas sont des notions propres au compilateur. Peut-être même au C et au C++? En C++ c'est même un peu plus complexe (je ne sais pas en C), car il y a d'autres types de mémoire (je ne m'en souviens plus, mais en tout il y en a 5 ou 6, dont le pile, le tas, la memoire statique, et je ne sais plus les autres).

Mais ça se sont des notions au niveau du compilateur. Ensuite c'est effectivement l'os qui s'occupe "physiquement" de la mémoire. C'est lui qui gère les blocks et tout le toutim. Par exemple, c'est lui qui envoie une interruption si le runtime lui demande d'allouer quelque chose qu'il ne peut pas. Autre exemple, c'est lui (l'os) qui décide si on va allouer sur en RAM ou swapper sur le disque dur.

Enfin je dis ça mais je ne sais pas si ça va répondre... en fait j'avoue que je ne comprends pas trop quelle est la question de cette discussion

Êtes vous allés à la discussion que j'ai indiqué auparavant et qui dit le contraire?

Ils disent le contraire de quoi? Peux-tu donner un lien stp?

[wafiwafi]

La question est posée au premier message de cette discussion.

Les coordonnées de la discussion à visiter se trouve également dans un message de cette même discussion; mais je vais la rappeler :

Voila une discussion qui m'a révélé autre chose. Mais j'espère me tromper.
La discussion est
La programmation des structures de données
à la date du 9/9/2009.

Merci à toi

[wafiwafi]

En fait je me trouve devant un dilemme!
Dans le forum de Java ou langage générale, on me précise qu'une vision conceptuelle en ce qui concerne la gestion de la mémoire(code,pile,tas,...), est fournie à l'utilisateur qui n'a rien à voir avec la façon et encore une fois avec laquelle le compilateur gère la mémoire (voir la discussion que j'ai indiqué dans mon précédent message). Alors qu'ici (C++), on m'affirme le contraire.
Bien à vous