Je suis d'accord avec Nanoc, y'a un tuto d'ailleurs la dessus...

Je comprend pas pourquoi faire ça: "FenPrincipale::FenPrincipale() : tableauCellule(4), tableauLabel(8, QLabel)"

tu declare le tableau dans ton .h:

std::vector<QLabel*> TabLabel;

tu l'utilise direct dans ton .cpp:

QLabel* Un_Label = new QLabel;
TabLabel.push_back(Un_Label);

Et a priori y'avais pas de pb pour faire un tableau de cellule heritant de qlabel...

J'ai réglé le probleme avec un QTableView qui est vraiment fait pour ca.

j'ai plus qu'un seul probleme : Ajouter des cellule dans mon tableau :

tableauCellule.push_back(new Cellule());

C'est un pointeur donc ca marche pas.

Dans le doute j'ai tenté :

tableauCellule.push_back(Cellule());

Mais ça ça plante.

faut pas "essayer", faut utiliser la bonne méthode.
Quelle est la définitions actuelle de tableauCellule?

Celle qu'on a faite au tout début : un tableau de cellule.

std::vector<Cellule> tableauCellule;

FenPrincipale::FenPrincipale() : tableauCellule(2)
{

le new ne peut pas marcher ici alors.

Qu'entends-tu pas "ça plante"?

Citation : Hiura

le new ne peut pas marcher ici alors.

Bah oui c'est bien ce que je dis

Citation : Hiura

Qu'entends-tu pas "ça plante"?

C'est windows qui râle : le programme a cessé de fonctionner, windows cherche une solution au probleme etc...

Utilise un debuggeur pour situer l'erreur. (Si tu ne sais pas comment ça fonctionne tu n'as aucune excuse : Nanoc a fait un tuto. )

Citation : Aravis

J'ai réglé le probleme avec un QTableView qui est vraiment fait pour ca.

j'ai plus qu'un seul probleme : Ajouter des cellule dans mon tableau :

tableauCellule.push_back(new Cellule());

C'est un pointeur donc ca marche pas.

Dans le doute j'ai tenté :

tableauCellule.push_back(Cellule());

Mais ça ça plante.

tu fait tableauCellule.push_back(new Cellule()) alors que tu déclare std::vector<Cellule> et pas std::vector<Cellule*>
edit : (tu essayes d'insérer un pointeur dans un tableau contenant des Objets Cellules)


moi j'ai l'habitude de déclarer la variable avant:

std::vector<Cellule> tableaucellule;

Cellule Une_Cellule;
tableaucellule.push_back(Une_Cellule);

ou alors :

std::vector<Cellule*> tableaucellule;

Cellule* Une_Cellule = new Cellule;
tableaucellule.push_back(Une_Cellule);

Tu laisse donc entendre que tableauCellule.push_back(Cellule()); devrait fonctionner ?

Le tuto dont tu parle n'apparait pas sur la page des tuto c++ ni meme sur le profil de même que le tuto sur les std::vector n'apparait pas non plus. Donc si tu avait un lien.

leboy >> ca change rien au probleme

Peut être que ça ne change rien au problème... mais regarde mon edit plus haut, il faut rester cohérent
tuto sur les vector :

http://www.siteduzero.com/tuto-3-29540 [...] d-vector.html


Bon courage

Je suis coherant (enfin je crois)
J'ai un tableau de Cellule et j'essaye de lui rajouter des Cellule dedans. Je peux pas faire plus cohérent.

Pour le tuto je le lis depuis ce matin tkt

Citation : Aravis

Je suis coherant (enfin je crois)
J'ai un tableau de Cellule et j'essaye de lui rajouter des Cellule dedans. Je peux pas faire plus cohérent.

Bah c t pas si cohérent quand tu déclare un vector contenant des objets cellule et que tu essaye de mettre des pointeurs dedans mais bon ce ne qu'est mon avis

vector appel le constructeur de base ou celui mis en paramètre


Si tu déclare comme ça

class MaClasse
{
    std::vector<MonElement_t> monTableau;

public:
    MaClasse() : MonTableau( 10 )
    {
    }
};

Alors ici à la création de la classe l'attribut MonTableau contiendra 10 élément initialisé et valides... rien ne sert de faire 10 push_back() supplémentaires.

À noté que peu importe si les espaces mémoires sont créer avec des push_back ou avec le constructeur : le constructeur par copie du type d'élément est nécessaire !

Bon Aravis, maintenant il est bien de se poser des questions. Qui a la responsabilité de quoi ?

Est-ce que les Cellules doivent pouvoir s'afficher et être dépendantes de ton interface ou serait-ce à ton interface de savoir comment demander les informations affichable à tes cellules.

Couche Interface vs. Couche Traitement.

Il y a déjà des conteneurs en Qt. Soit graphiques : les layout. Soit utilitaires : comme QList. Ils sont adaptés à leurs classes. Le layout (Ou la classe de fenêtre (si tu préfère)) devrait posséder les QLabels. Mais tu peux toujours avoir un vector de pointeurs vers c'est QLabel déjà existant pour faciliter l'automatisation de l'affichage. La classe de fenêtre va se charger de les nettoyer à la fin de sa vie. Tes cellules ne devrait jamais connaitre qui s'occupe de les afficher... c'est même pas important. Un traitement devrais pouvoir se faire sans affichage ou avec plusieurs sans avoir à être modifié.

Les classes de traitement devrait offrir assez d'accesseur (et, pour les plus avancés, de callback événementiels*) pour que l'interface puisse intéragir éfficacement avec l'objet en traitement. Pour ton niveau penche toi seulement sur de bons accesseurs, sécuritaires.



* Pour les plus avancés :
Je ne sais pas comment les nommer. Ce que j'entends par callbacks événementiels c'est d'affecter un pointeur de fonction (ou une liste de pointeurs) à un événement défini par la classe. Exemple : une classe qui gère la lecture d'un fichier formaté. Elle peut très bien appeler des pointeurs de fonction à chaque "pourcent" de la lecture complète du fichier (Je parle d'un très gros fichier). Ainsi seuls les interfaces voulant être informées pourront ajouter une fonction à être appelée lors de la progression du traitement. Ceci permet de décharger l'interface d'avoir la responsabilité de rafraichir l'information périodiquement (Et cela probablement inutilement ou pas assez rapidement) et la classe traitement n'a pas à connaitre qui et comment elle est affichée. Un tel système peu être implémenté en Console, avec Qt ou avec la Win32 API sans changer la classe de traitement.

Citation : leboy

Bah c t pas si cohérent quand tu déclare un vector contenant des objets cellule et que tu essaye de mettre des pointeurs dedans mais bon ce ne qu'est mon avis

Mais j'ai pas fait ca. J'ai juste dis que ca marchait pas puisque c'était des pointeur. Bref osef

Citation

À noté que peu importe si les espaces mémoires sont créer avec des push_back ou avec le constructeur : le constructeur par copie du type d'élément est nécessaire !

Ah ! J'ai pas de constructeur de copie ! Pourtant le tableau que j'initialise marche.

Citation

Est-ce que les Cellules doivent pouvoir s'afficher et être dépendantes de ton interface ou serait-ce à ton interface de savoir comment demander les informations affichable à tes cellules.

Ça c'est bon. C'est l'interface qui va chercher les info et qui les affiche. Ca marche bien comme je veux ! J'ai utilisé un QTableView c'est exactement ce qu'il me faut.

Mon seul vrai problème maintenant c'est d'ajouter des cellules dans mon tableauCellule. Mais c'est peut etre parce qu'il n'y a pas de constructeur de copie ?

Il faut voir, souvent le constructeur de copie de base suffit. Y a-t-il des données qui ne peuvent pas être "bêtement" copiées? [Que sont les attributs de Cellule?]

Citation : Hiura

Y a-t-il des données qui ne peuvent pas être "bêtement" copiées? [Que sont les attributs de Cellule?]

Pour l'instant 2 attributs plus ou moins bidon :

• int m_energie;
• int m_age;

Et un pointeur vers le milieu dans lequel elle evolue. Mais celui ci doit être copié tel quel puisque toutes les cellules évoluent dans le même milieu.

• Milieu *m_milieu;

Donc non rien de bien folichon.

Citation

Il faut voir, souvent le constructeur de copie de base suffit

Ca veut dire quoi ? Que même sans écrire un constructeur de copie il en existe un de base ?

Oui, il existe toujours un constructeur de copie "par défaut". De même qu'un operator=.

Il est toujours suffisant à moins d'avoir des pointeurs alloués dynamiquement dans ta classe.

Pour emêcher qu'un objet soit copiable, on écrit un constructeur de copie dans la partie privée de la classe.

Citation : Nanoc

Il est toujours suffisant à moins d'avoir des pointeurs alloués dynamiquement dans ta classe.

Du coup c'est pas ca le probleme .

tu fais new Milieu ?


De toute façon la question importante n'est pas là. Ce serait plutôt:

Est-ce que ça a du sens de copier une Cellule ?

Non non en fait dans le constructeur de cellule je fais m_milieu = NULL;
Et apres dans la fenetre je fais cellule.setMilieu(&m_milieu);

Bien ce que je pensais. Mais réponds à ma question.

Attent tu édite j'ai pas le temps de répondre a tout

Est ce que ca a du sens ? Bah imaginons qu'on rajoute de l'adn dans la cellule et qu'on lui ajoute un fonction mitose ouais ca aurait du sens. Là non pas vraiment.

Mais la question de la copie se pose puisque vous dites que le std::vector a besoin de copier l'objet (ou un truc du genre)

On ajoute pas la copie parce qu'on utilise un vector. On autorise la copie si elle a un sens.

Après si c'est pas copiable, on peut toujours mettre des pointeurs dans le vector ou se débrouiller autrement. Il faut se poser les bonnes questions et dans le bon ordre surtout.

C'est copiable et autorisé. Y'a pas d'attributs qui posent problème.
La création du tableau marche bien :

std::vector<Cellule> tableauCellule;

FenPrincipale::FenPrincipale() : tableauCellule(5)
{

Y'a juste un probleme quand je fais un push_back. Le programme plante. Je l'ai peut être mal fait mais vous n'avez pas l'air de faire des histoire avec

tableauCellule.push_back(Cellule());

Tu as un constructeur par défaut ?

Bien sûr :

Cellule::Cellule()
{
   m_age = 0;
   m_energie = 50;
   m_milieu = NULL;
}

Que veut dire "il plante" ?

Citation : Hiura

Qu'entends-tu pas "ça plante"?

Citation : Aravis

C'est windows qui râle : le programme a cessé de fonctionner, windows cherche une solution au probleme etc...

et le débuggeur ? m_milieu est-il toujours nul lors de son utilisation?

Citation : Hiura

et le débuggeur ?

Je peux pas avoir le lien je l'ai déjà dis. Et google ne trouve pas non plus (j'ai peut être mal cherché).

Citation

Le tuto dont tu parle n'apparait pas sur la page des tuto c++ ni meme sur le profil de même que le tuto sur les std::vector n'apparait pas non plus. Donc si tu avait un lien.

Citation : Hiura

m_milieu est-il toujours nul lors de son utilisation?

Jamais ! D'ailleur c'est stupide de le mettre a null dans le constructeur. Je devrais avoir un constructeur surchargé qui prend en paramètre le pointeur et pas de constructeur pas defaut mais bon on vera ca apres...

Edit : Mais maintenant que tu le dis le probleme viens peut etre de là
Oui bien vu attendez deux minutes lors de la création avec le push back c'est la que ca doit deconner

J'essais un truc.