simple application QT avec paint() - Page 2

La documentation de Qt dit qu'il ne faut surtout pas dériver d'un QObject sans mettre la macro Q_OBJECT, il y a des cas où ça peut foirer, par exemple le nom de classe donné par le système QMetaObject ne sera pas bon.
Cela dit, je l'ai fait aussi quelques fois et ça a marché... (M'en fous du nom de classe donné par QMetaObject.)

oué, idem.
en plus ça m'a agacé de voir qu'un connect() raté affiché une trace à l'écran. Ca veut dire que c'est dynamique, donc bof, ça me plait pas (le mec arbitraire )

disons en résumé, j'ai pas besoin des features apportés par moc et ses copains.

Tu vas sans doute en avoir besoin plus tard, le système de signaux et de slots est un peu l'essence de Qt...
Et effectivement, connect est résolu en temps d'exécution, c'est bien pour ça qu'on a besoin de tout le système d'introspection proposé par QMetaObject.

squalyl (./30) :
sinon je passe tout en pointeurs "comme java" et j'expliciterai les copies #bourrin#

C'estaussi ce que je faisait au début mais les fonctions QT utilisent massivement le passage par référence. Du coup, je me suis retrouvé dans des cas ou j'étais plus ou moins contraint de garder ce fonctionnement.

Normalement, l'idée derrière l'API de Qt 4, c'est que les références ne sont utilisées que si on ne remarque pas que c'est une référence (passage par const Foo & pour des raisons de performance), sinon on passe un pointeur. Le constructeur de QApplication est bizarre sur ce point, il ne respecte pas ce concept.

Je ne comprends pas : on ne remarque jamais le passage par référence en C++. Qu'est-ce que tu as voulu dire ?

Essaye d'utiliser intensivement les classes QList et QMap, tu vas forcément remarquer que ça utilise les références. Si j'avais fais attention a ça, j'en serais sagement resté à la STL pour contenir des pointeurs.

Uther (./36) :
Essaye d'utiliser intensivement les classes QList et QMap, tu vas forcément remarquer que ça utilise les références.

Je ne comprends pas trop ce que tu veux dire là.

Sasume (./35) :
Je ne comprends pas : on ne remarque jamais le passage par référence en C++. Qu'est-ce que tu as voulu dire ?

class Foo {
  public:
    Foo(int &toto) : m_toto(toto);
    int use_toto() {return m_toto;}
  private:
    int &m_toto;
};

Foo *pFoo;

void foo()
{
  int toto=42;
  pFoo = new Foo(toto);
}

int bar()
{
  foo();
  return pFoo->use_toto();
}

Ici, tu remarqueras que toto est passé par référence au constructeur de Foo, parce que ce code va foirer, alors qu'il marchera si on utilise des copies.

C'est ça la situation avec le constructeur de QApplication.

Kevin Kofler (./32) :
sans doûte

(je t'avais déjà fait la remarque il y a qqs années, mais comme je l'ai vue une quinzaine de fois depuis et que c'est à peu près la seule faute que tu fais en français je me permets de te corriger : "doute" ne prend jamais d'accent circonflexe)

En fait, les signaux Qt, c'est un peu comme les événements .Net ?

Les signaux sont des évènements, les slots sont des gestionnaires (handlers) d'évènements.

OK merci.

tiens, genre de truc qui m'énerve.

struct antenna {
    double dir;
    double antenna;
};

class Cell {
public:
    Cell();
    void addAntenna(double dir, double span);
    ..........
private:
    QList<struct antenna> antennas;
    ..........
};

void Cell::addAntenna(double dir, double span)
{
	struct antenna a;
	a.dir=thedir;
	a.span=thespan;
	antennas.add(a);
}

je sais que a sera supprimé en quittant la fonction, pourtant, la liste contiendra a. y'a bien copie de l'objet, sinon ça foirerait. Qn peut confirmer ça?

Oui, les objets sont copiés quand tu les insères dans une QList.

ouf

y'a des cas ou c'est pas copié?

Si tu prends l'adresse et la mets dans un QList<struct antenna *>.

ouais.

en fait je me rends compte que j'ai des problèmes avec les références.

Justement, de qlist.

qq part dans le code, j'appelle addAntenna(), et juste après, la méthode count() de cette qlist me donne le bon nb d'éléments.

mais ailleurs dans le code, j'accède aux éléments de la liste (pour les dessiner) et je me rends compte que les listes "d'antennes" sont vides. Il y a sans doute un pb de copie d'objets qui ne transfère pas le contenu de la liste. Un constructeur de copie trivial ne change rien à l'affaire, pourtant je vois bien avec des traces qu'il est appelé souvent. Fuck! j'ai pas envie de changer tout mon code pour mettre des pointeurs (que je sais maitriser) partout

Cell::Cell(const Cell &old)
{
	antennas.clear();
	for(int i=0;i<old.antennas.count();i++) {
		antennas.append(old.antennas.at(i));
	}
}

(oui, on pourrait faire ça avec un itérateur, mais je le ferai plus tard, quand tout marchera)

Une QList est implicitement partagée.
http://doc.trolltech.com/4.3/shared.html

oué, ben ça marche pas

ça m'énerve, là!

bon, je m'en suis sorti avec des QList<Cell*>, comme ça, je crée les cell une fois au chargement, et je manipule plus que des VRAIES références vers des objets, ie des pointeurs.

vive le java

Ah, les joies du C++

et de Qt

là je m'excite avec QPainter::drawArc qui sait dessiner un arc de l'angle 30 à l'angle 60, de l'angle -30 à l'angle -60, mais pas de l'angle -n à l'angle +n

PUTAIN CA PEUT PAS ETRE SIMPLE, NON?

J'y connais rien en QT, mais tu as essayé avec n et 360-n ?

oué

mais rien à faire, il veut pas traverser zéro

t1, vais devoir me taper une routine à la con!

squalyl (./46) :
ouais.

en fait je me rends compte que j'ai des problèmes avec les références.

Justement, de qlist.

Ha ca me rassure que je sois pas le seul a trouver la gestion des référence dans les QList pas intuitive du tout. Du coup on se retrouve a l'utiliser avec des pointeurs ce qui fait qu'il y a peu d'interêt par rapport a la STL qui a l'avantage d'être standard.

oui, honnêtement je comprends pas pourquoi les listes sont pas copiées alors qu'elles devraient.

estime-toi heureux.

<troll pour la STL et les noobs qui font des tutos>
Trouve une doc qui explique comme il faut le fameux "vector" de la STL.
98% des exemples c'est

Vector v = new Vector();
v.add(3);
...
// Vous voyez? ca a ajouté 3!!

super et si c'est un objet bordel!? Ca copie ou ca copie le pointeur????? Bah tu peux chercher.
</troll pour la STL et les noobs qui font des tutos>

lol

en même temps si tu fais un Vector<Vector<trucmuche>> y'a pas bcp de nioobs-qui-vont-lire-le-tuto qui comprendront

Personnellement, je trouve que QList se comporte exactement comme attendu.

bah alors, c'est quoi le souci que j'ai eu? j'aurais bien évité, le coup des pointeurs, mais ça marche pas autrement!

J'utilise Qt est franchement c'est un bonheur. J'ai jamais vu une bibliothèque aussi performante et facile à utiliser en C++.
Pour l'histoire des conteneurs si on travail avec de cette façon:
QList<Cell*> on ajoute des pointeurs dont si on veut une copie il faut explicitement appellée une méthode clone genre:
MyList << MyCell->clone();

Dans le cas d'un QList<Cell> l'ajout d'un élément entraine l'appel du constructeur par copie de ta classe Cell.
Soit Cell(const Cell& cell) donc si elle n'est pas correctement implémentée tu n'auras pas une vraie copie dans ta liste.
Enfin, si tu copies ton objet qui contient une liste tu dois naturellement développer le constructeur par copie qui recopie la liste. Sinon le constructeur par défaut de QList<T> sera utilisé. Et enfin pour ne pas se prendre la tête avec la destruction d'une liste... On préfère utiliser un QList<std::auto_ptr<Cell> > par exemple.