Discussion :

[yan]

Bonjour,

Pour faire des exemples pour la FAQ Qt, il est souvent aissé de tout mettre dans un main.
http://qt.developpez.com/faq/?page=q...er_dans_widget

Seulement ce n'est pas propre.

Je me demande donc, si il n'est pas preferable de faire les exemple correctement ( plusieurs fichier), pour ne pas donner de mauvaise habitude au personne utilisant la FAQ.

Qu'en pensez vous?

[IrmatDen]

Salut,

Faire plusieurs fichiers, non. Tout mettre dans la fonction main non plus
Juste un fichier main.cpp avec des belles classes toute propre, oui.

Le pourquoi de mon avis est qu'un exemple doit absolument être court, et qu'avoir 150--=200 lignes dans 3 fichiers différents (minimum... parce qu'après s'il y a 2 classes persos, et que tu fais un .h/.cpp par classe c'est abusé) ou 150 dans un seul... à choisir je préfère la 2nde.


Edit: juste pour souligner un point: je parle dans le cadre de la FAQ et non de tutos Dans ce dernier cas, tout dépend de la taille du code et du nombre de classe. Dans certains cas je fais un fichier, dans d'autres, j'en fais 3 (rarement plus en fait => en général je fais la classe principale servant à illustrer le tuto dans un couple h/cpp, puis les classes servant à supporter la démo dans le main => en général, c'est juste l'interface globale).

[yan]

Le problème arrive dans le cas ou il faut faire se signal et slot...
Et j'ai l'impression de montrer une mauvaise utilisation de Qt.

Je pense de plus en plus faire proprement un projet Qt avec de belle class dés qu'il faut faire au moins une class. Comme ça un petit téléchargement des sources, qmake et make et ça roule.

Je demande ça car j'ai commencé à voir des codes d'utilisateurs où tous est dans le main

[IrmatDen]

Ouaip, je vois ça aussi, mais t'y es pour rien. Ces gars là, faut les renvoyer aux tutos Qt où la stratégie principale est expliquée dès le tutoriel 6 ou 7 je sais plus. Sans compter que certains ne font pas la différence entre mettre le code dans main.cpp et mettre le code dans la fonction main. Là, faut carrément revoir le C++.

Parce que rassure toi, ce n'est absolument pas une mauvaise utilisation de Qt. Il y même des cas où c'est bon de mettre une classe avec des signaux/slots dans un seul fichier. Je pense tout particulièrement au pimpl. Tu peux t'assurer d'avoir ta classe d'implémentation dans le .cpp qui ne sera ainsi *jamais* visible tout en utilisant toujours correctement les signaux/slots.

Donc ce qui ne sont pas de l'école du copier/coller apprendront qu'il est possible de faire autre chose que séparer déclaration et implémentation; et avec un peu d'expérience quand utiliser telle ou telle approche.

[yan]

Parce que rassure toi, ce n'est absolument pas une mauvaise utilisation de Qt. Il y même des cas où c'est bon de mettre une classe avec des signaux/slots dans un seul fichier. Je pense tout particulièrement au pimpl. Tu peux t'assurer d'avoir ta classe d'implémentation dans le .cpp qui ne sera ainsi *jamais* visible tout en utilisant toujours correctement les signaux/slots.

Je parlais de tout mettre dans le main. C'est un début de trés mauvais conception.

Donc ce qui ne sont pas de l'école du copier/coller apprendront qu'il est possible de faire autre chose que séparer déclaration et implémentation; et avec un peu d'expérience quand utiliser telle ou telle approche.

Mais n'est ce pas aussi une bonne chose de montré l'exemple?

En faite c'est surtout pour les debutants

[IrmatDen]

Je parlais de tout mettre dans le main. C'est un début de trés mauvais conception.

Ok, ça oui, c'est à bannir. Mais le lien que tu montrais dans le premier post est un lien vers une bonne séparation main/classe. D'où le fait que je fasse la distinction depuis le premier post

Edit: d'ailleurs, j'ai pas fait gaffe, mais paintEvent n'est pas en protected au passage

Mais n'est ce pas aussi une bonne chose de montré l'exemple?

En faite c'est surtout pour les debutants

Si, mais il y a débutant en Qt et débutant en C++. Qt (comme tout autre framework digne de ce nom ) n'est pas destiné à être utilisé par des gens qui ne savent pas encore ce qu'est un attribut de classe, la portée des variables etc...

[yan]

Ok, ça oui, c'est à bannir. Mais le lien que tu montrais dans le premier post est un lien vers une bonne séparation main/classe. D'où le fait que je fasse la distinction depuis le premier post

ben c'est un peut pareil. Mettre la définition d'un class dans le fichier cpp d'un main... c'est pas terrible non plus. Surtout si on y met des signal et slot.

Edit: d'ailleurs, j'ai pas fait gaffe, mais paintEvent n'est pas en protected au passage

mais euh...

Si, mais il y a débutant en Qt et débutant en C++. Qt (comme tout autre framework digne de ce nom ) n'est pas destiné à être utilisé par des gens qui ne savent pas encore ce qu'est un attribut de classe, la portée des variables etc...

D'où l'autre thread

[IrmatDen]

ben c'est un peut pareil. Mettre la définition d'un class dans le fichier cpp d'un main... c'est pas terrible non plus. Surtout si on y met des signal et slot.

Pour un code de FAQ destiné à expliquer concisément l'utilisation d'une fonctionnalité, je vois pas le problème. Les gens doivent avoir fait les tutos (y'en a que 14, c'est pas la mer à boire) et connaître le C++. Ces personnes là, savent faire la différence entre un exemple et un découplage classique à utiliser dans un projet (qui est déjà expliqué dans les tutos donc bon).

(Edit: et j'ai déjà créé des classes utilisant signaux/slots dans un fichier cpp. Quand c'est adapté, ce n'est pas un mal)

Bien sûr, ça n'est que mon avis; mais à mes yeux, il ne faudrait pas se mettre à Qt, à gtkmm à wxWidgets Ogre etc etc... sans connaître le C++. Y'a trop de bases cruciales que tu ne peux pas expliquer, sauf à discuter C++... Mais c'est un autre sujet, et une autre section de DVP et de son forum

[Alp]

Je suis d'accord avec IrmatDen en ce qui concerne ta question Mongaulois.

[yan]

(Edit: et j'ai déjà créé des classes utilisant signaux/slots dans un fichier cpp. Quand c'est adapté, ce n'est pas un mal)

Quand j'avais essayé, le qmake ne les trouvais pas car c'était dans un .cpp au lieux d'un .h. Du coup pas de moc et donc erreur de vtable

[IrmatDen]

Quand j'avais essayé, le qmake ne les trouvais pas car c'était dans un .cpp au lieux d'un .h. Du coup pas de moc et donc erreur de vtable

Normal *si* tu ne l'inclus pas:
#include "nomdufichiercpp.moc"
Et zou, ta classe sera complétée par le moc

[manpe]

Si je puis me permettre de participer au debat, je rejoins IrmatDen sur le point fondamental : un exemple Qt ne peut pas reprendre toutes les bases C++ et notions fondamentales de Qt. Il doit se focaliser sur la thematique illustree par l'exemple, et le reste du code et surotut la "strategie" de conception etant propres a chaque utilisateur. Aussi je preconiserai avant tout un code COMPACT

[Alp]

De toute manière, c'est un fait, il faut une assez bonne connaissance du C++ pour entamer l'utilisation de Qt ...

[IrmatDen]

Si je puis me permettre de participer au debat

C'est mieux même, ce serait bien qu'encore plus d'avis soient fournis
C'est avec le plus d'avis que mongaulois pourra trancher pour telle ou telle approche.

[yan]

Normal *si* tu ne l'inclus pas:
#include "nomdufichiercpp.moc"
Et zou, ta classe sera complétée par le moc

?
ben je ressaierai alors.
Mais ça m'étonne que de mettre #include "nomdufichiercpp.moc" va indiquer au QMake d'ajouter l'utilisation de moc sur le .cpp

[IrmatDen]

Si ça ne fonctionnait pas IRL, je ne te le dirais pas

De plus, c'est écrit dans la doc:

For Q_OBJECT class declarations in implementation (.cpp) files, we suggest a makefile rule like this:

foo.o: foo.moc

foo.moc: foo.cpp
moc $(DEFINES) $(INCPATH) -i $< -o $@

This guarantees that make will run the moc before it compiles foo.cpp. You can then put

#include "foo.moc"

at the end of foo.cpp, where all the classes declared in that file are fully known.

Bien sûr, la partie sur la Makefile rule n'est absolument pas à utiliser lorsque tu utilises qmake puisqu'il s'en occupe. C'est utile pour les gens faisant leur propres Makefiles, ou plus communément les développeurs de solutions tierce (genre les gars de CMake qui maintiennent le support de projets type Qt).

[yan]

T'as raison ça marche nikel
merci.
Encore une fois tout est dans la doc