Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ vector et constructeur

vector et constructeur

15 réponses
Avatar
Nicolas Aunai
salut,


j'ai une classe Objet, et une classe TabObjet qui contient un
vector<Objet>

chaque Objet à pour membre :

un unsigned int ID, que le caractérise facilement.
un string Name, sorte d'id mais pour l'utilisateur.

et quelques autres paramètres pas très importants...

bref, le constructeur de Objet demande entre autre, l'ID et le Name, et
le constructeur par défaut lui, fixe un ID qui est égal à
l'incrémentation de un, d'une vairable statique initialisée a 0, ainsi
qu'un Name par défaut.

Objet::Objet()
:Name("SansNom"),ID(nb++) //avec static unsigned int nb = 0; dans la
classe
{
}

alors là, ça va bien lorsque j'appelle le constructeur "manuellement",
cependant je ne comprends pas ce qui se passe lorsque j'apelle le
constructeur de TabObjet.

TabObjet::TabObjet():mon_tab(100)
{
}

va créer un vector de 100 Objet, mais comment ceux-ci vont-ils être
crées ? par le constructeur par défaut ?

je me demande en fait, si les Objet de mon vector auront bien des bons
ID


merci d'avance pour les explications !!!

--
Nico,
http://astrosurf.com/nicoastro
messenger : nicolas_aunai@hotmail.com
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Fabien LE LEZ
On Sat, 07 Feb 2004 12:07:49 +0100, Nicolas Aunai
wrote:

TabObjet::TabObjet():mon_tab(100)
{
}

va créer un vector de 100 Objet, mais comment ceux-ci vont-ils être
crées ? par le constructeur par défaut ?


Si je ne m'abuse, tu appelles ainsi le constructeur suivant :
std::vector<>::vector<> (size_t nombre, Objet const& o= Objet())

Donc, le constructeur de Objet est appelé une fois, et ensuite les 100
objets contenus dans le vector<> sont créés en appelant le
constructeur de copie Objet::Objet (Objet const&)

Si j'ai tout bien suivi, tu crées ainsi un vector<> de 100 objets
parfaitement indentiques.

Le code suivant, par contre, fonctionnera comme tu veux :

TabObjet::TabObjet()
{
static int NB_OBJETS= 100; // D'où sort ce nombre, au fait ?
for (int i=0; i<NB_OBJETS; ++i)
{
mon_tab.push_back (Objet());/* Rajoute ici un commentaire pour
bien mettre en valeur que les objets créés ont des ID différents */
}
}


--
;-)

Avatar
Nicolas Aunai



Le code suivant, par contre, fonctionnera comme tu veux :

TabObjet::TabObjet()
{
static int NB_OBJETS= 100; // D'où sort ce nombre, au fait ?
for (int i=0; i<NB_OBJETS; ++i)
{
mon_tab.push_back (Objet());/* Rajoute ici un commentaire pour
bien mettre en valeur que les objets créés ont des ID différents */
}
}




ah ok d'accord, 100 c'était pour l'exemple, le constructeur TabObjet
par défaut prendra un nombre d'Objet par défaut, par exemple 10, et il
y aura bien sûr un constructeur surchargé prenant un nombre d'Objet a
stocker.

en fait Objet est un objet Particule, et TabObjet représente un tableau
de Particules, chaque particule à un ID facilitant le calcul de la
resultante des forces conséquence de l'intéraction avec les n-1 autres
particules du tableau.

--
Nico,
http://astrosurf.com/nicoastro
messenger :

Avatar
Fabien LE LEZ
On Sat, 07 Feb 2004 12:42:35 +0100, Nicolas Aunai
wrote:

en fait Objet est un objet Particule, et TabObjet représente un tableau
de Particules, chaque particule à un ID facilitant le calcul de la
resultante des forces conséquence de l'intéraction avec les n-1 autres
particules du tableau.


L'index dans le tableau ne suffit-il pas ?

--
;-)

Avatar
Fabien LE LEZ
On Sat, 07 Feb 2004 12:42:35 +0100, Nicolas Aunai
wrote:

en fait Objet est un objet Particule, et TabObjet représente un tableau
de Particules, chaque particule à un ID facilitant le calcul de la
resultante des forces conséquence de l'intéraction avec les n-1 autres
particules du tableau.


Je viens de voir ton post sur fca, et franchement, je n'ai pas la
moindre idée de l'utilité de cet ID.

--
;-)

Avatar
Fabien LE LEZ
On Sat, 07 Feb 2004 16:31:11 +0100, Fabien LE LEZ
wrote:

Je viens de voir ton post sur fca, et franchement, je n'ai pas la
moindre idée de l'utilité de cet ID.



Allez zou, un bout de code pour expliquer ma réaction :

void TabObjet::CalculeInteractions (Temps dt)
{
for (vector<Objet>::iterator i= mon_tab.begin();
i!=mon_tab.end(); ++i)
{
Vecteur acceleration= 0;
for (vector<Objet>::const_iterator j= mon_tab.begin();
j!=mon_tab.end(); ++j)
if (&*i != &*j)
{
Scalaire distance_au_carre=
CalculeDistanceAuCarre ((*i).position, (*j).position);
if (distance == 0)
{
throw "Collision entre " + (*i).nom + " et " + (*j).nom;
}
else
{
acceleration+= (*i).masse * (*j).masse
/ distance_au_carre;
}
}
(*i).vitesse+= acceleration * dt;
}
for (vector<Objet>::iterator i= mon_tab.begin();
i!=mon_tab.end(); ++i)
{
(*i).position+= (*i).vitesse * dt;
}
}

--
;-)

Avatar
Nicolas Aunai
Fabien LE LEZ a exprimé avec précision :

Je viens de voir ton post sur fca, et franchement, je n'ai pas la
moindre idée de l'utilité de cet ID.


bah, dans mon idée, l'ID me permet de garder une trace d'une particule
donnée, puisque chaque ID est unique. Ainsi, si dans les calculs
d'intéractions les indices de boucles suffisent a dicerner une
particule d'une autre, si à un moment donné je veux faire
systeme.suppr(un_ID) toutes les particules se trouvant "a droite" de
un_ID seront décalées, et grâce à leur ID j'aurai toujours une main
dessus pour leur appliquer je en sais quoi par la suite...

--
Nico,
http://astrosurf.com/nicoastro
messenger :

Avatar
Fabien LE LEZ
On Sat, 07 Feb 2004 17:14:33 +0100, Nicolas Aunai
wrote:

pour leur appliquer je en sais quoi par la suite...


Donc, en gros, tu cherches à mettre un ID sur tes objets, avec tous
les inconvénients et complications que ça apporte, sans trop savoir
pourquoi tu le fais ?

--
;-)

Avatar
Nicolas Aunai
Fabien LE LEZ avait prétendu :


Donc, en gros, tu cherches à mettre un ID sur tes objets, avec tous
les inconvénients et complications que ça apporte, sans trop savoir
pourquoi tu le fais ?



j'appelle ça prévoir... quelles complications ça apporte ? incrémenter
une variable statique a chaque construction, définir un membre ID, un
accesseur en lecture, un en écriture... et voila.

je le fais pour que les particules ne soient pas "anonymes", ça peut
toujours servir par la suite.

--
Nico,
http://astrosurf.com/nicoastro
messenger :

Avatar
Fabien LE LEZ
On Sat, 07 Feb 2004 17:59:40 +0100, Nicolas Aunai
wrote:

j'appelle ça prévoir...


Justement, il faut savoir se limiter dans ses prévisions, et se
contenter de ce qui apporte plus de fonctionnalités utiles que de
problèmes.

quelles complications ça apporte ? incrémenter
une variable statique a chaque construction, définir un membre ID, un
accesseur en lecture, un en écriture... et voila.


Ce n'est pas si simple que ça (cf plus bas).

je le fais pour que les particules ne soient pas "anonymes",


En gros, tu veux donner une sémantique d'identité (ou d'entité) à tes
objets. C'est un point de vue assez courant, mais loin d'être anodin.
Ta méthode est peut-être un bon début, mais n'est pas complète : tu
dois définir le constructeur par copie (et l'opérateur de copie qui
"va avec"), pour t'assurer que deux objets différents ne peuvent pas
avoir le même ID (le constructeur par copie généré par le compilateur
se contente de copier membre à membre, ce qui ne convient pas ici --
la preuve, ton erreur - qui a déclenché le présent thread - n'a pas
été repérée par le compilo). Une technique classique est d'interdire
l'usage du constructeur de copie et de l'opérateur =, en les déclarant
privés.
D'autre part, std::vector<> ne convient pas du tout, puisqu'il
n'accepte que des objets ayant une sémantique de valeur (il se permet
de copier allègrement les objets). Tu peux par contre utiliser un
vector<> de pointeurs -- et allouer tes objets dynamiquement, à la
main.

Bon, je fatigue, donc je m'en tiens à ces explications superficielles.
Et j'attends que les vrais spécialistes du C++ donnent leur avis sur
la question -- j'avoue que, n'ayant aucune expérience objet en-dehors
du C++, j'ai tendance à éviter au maximum d'utiliser des objets à
sémantique d'entité.
Mais tu as en tout cas raison sur un point : si tu as _vraiment_
besoin d'une sémantique d'entité, mets-la en place tout de suite, car
ça va modifier profondément ton programme.

--
;-)

Avatar
Nicolas Aunai
Fabien LE LEZ a formulé la demande :

Justement, il faut savoir se limiter dans ses prévisions, et se
contenter de ce qui apporte plus de fonctionnalités utiles que de
problèmes.


c'est justement parce que plus tard j'aurai peut-etre envie de faire
quelque chose a laquelle j'avais pas pensé avant que bâtir les bases
d'un programme de manière la plus "généraliste" possible me semble une
bonne idée, et ça implique donner une identité a mes particules. C'est
l'utilisation de bibliotheques c++ pour programmation graphique
evennementielle qui m'en a donné l'idée, dans ce genre de truc, chaque
composant d'un formulaire, un objet, est caractérisé par un ID, ce qui
permet de lui appliquer tout un tas de choses...


En gros, tu veux donner une sémantique d'identité (ou d'entité) à tes
objets. C'est un point de vue assez courant, mais loin d'être anodin.
Ta méthode est peut-être un bon début, mais n'est pas complète : tu
dois définir le constructeur par copie (et l'opérateur de copie qui
"va avec"), pour t'assurer que deux objets différents ne peuvent pas
avoir le même ID (le constructeur par copie généré par le compilateur
se contente de copier membre à membre, ce qui ne convient pas ici --
la preuve, ton erreur - qui a déclenché le présent thread - n'a pas
été repérée par le compilo). Une technique classique est d'interdire
l'usage du constructeur de copie et de l'opérateur =, en les déclarant
privés.


mais c'est pas parce que j'en avais pas parlé que je l'avais pas fait
:) mon constructeur par copie recopie membre a membre sauf l'ID qui est
toujours le nombre_de_particules++. quant à l'opérateur d'assignation
je l'ai mis en privé, mais il ne fait rien.


D'autre part, std::vector<> ne convient pas du tout, puisqu'il
n'accepte que des objets ayant une sémantique de valeur (il se permet
de copier allègrement les objets).



alors là... j'y pensais pas.


Tu peux par contre utiliser un
vector<> de pointeurs -- et allouer tes objets dynamiquement, à la
main.


commet ça ? qu'est-ce que ça change... je piges pas bien

Bon, je fatigue, donc je m'en tiens à ces explications superficielles.
Et j'attends que les vrais spécialistes du C++ donnent leur avis sur
la question -- j'avoue que, n'ayant aucune expérience objet en-dehors
du C++, j'ai tendance à éviter au maximum d'utiliser des objets à
sémantique d'entité.
Mais tu as en tout cas raison sur un point : si tu as _vraiment_
besoin d'une sémantique d'entité, mets-la en place tout de suite, car
ça va modifier profondément ton programme.



merci des explications, je sais pas si j'en ai besoin, c'est une
manière évidente est simple que j'ai trouvé non seulement pour ne pas
perdre mes particules, mais aussi pour les trier facilement par
exemple.

--
Nico,
http://astrosurf.com/nicoastro
messenger :

1 2