Pourquoi il y aurait un problème ?Citation:
S'il y a le moindre problème, on a du mal à savoir ce qui s'est mal passé.
Les macros font derrière appel a connect.
Version imprimable
Pourquoi il y aurait un problème ?Citation:
S'il y a le moindre problème, on a du mal à savoir ce qui s'est mal passé.
Les macros font derrière appel a connect.
Le problème, ce n'est pas l'appel à connect, c'est tout ce qui est attenant aux macros, les erreurs qui peuvent en découler, l'obligation d'avoir une macro pour le début de la table, pour la fin et s'il y a le moindre souci, le message d'erreur est incompréhensible.
Ce que je ne comprend pas , c'est pourqoi il y aurait une erreur.
Au mieu il ya une erreur dans le type d'argument que la fonction recoit ou plus con on a oublie de définir la fonction.
Mais en 1.5 and d'utilisation de wx , je n'ai jamais eu de problème de ce coté.
Il peut y avoir une erruer :
- s'il y a un type template
- s'il y a une opération à effectuer sur la variable
- si on oublie de fermer la table
- ...
[QUOTE=Miles]Il peut y avoir une erruer :
- s'il y a un type template
On utilse peut/aps de template avec les composant de wx.
http://www.wxwidgets.org/manuals/sta...html#templates
Après pour les partie crée de toutes pièces , ca c'est une autre hsitoire.
?? .On la fait , c'est tout.Citation:
Envoyé par Miles
Ca ce voit sans difficulté pour put qu'on indente correctement sa table.Citation:
Envoyé par Miles
c'est hors sujet, mais
c'est quand meme un peu du foutahe de tronche ca. Ca sent la vieille excuse pour dire j'ai pas envie d'en faire.Citation:
Envoyé par Doc WX
GCC (meme la version mingw) et Visual 2003 sont tous les deux assez proche au niveau de la gestion des templates (meme si j'ai note des differences irritantes).
En code template j'ai souvent atteint les limites de visual C++ 2005 (erreurs de compil alors que ca devrait marcher, etc) mais j'ai toujours trouve un moyen de faire du code compatible gcc/comeau/intel C++/visual C++. Et pourtant mon code templatise est pas trivial.
Boost fait des trucs bien pire que mes templates et leurs trucs sont portables sur de nombreuses platformes
Qt a admis avoir fait un preproc parce que a l'epoque de Qt le support des templates etait moisi. Depuis ils en sont revenus.
L'explication est vaseuse, sérieusement...Citation:
Envoyé par Davidbrcz
Et rien n'empêche d'utiliser un widget maison template qui pourra avoir un souci (faut rajouter des parenthèses pour que ça passe)
Le truc, c'est que si on passe a+b, on n'est pas sûr du résultat, et je ne parle pas de a++. C'est typiquement pour ce genre d'erreur qu'on déconseille les macros.Citation:
Envoyé par Davidbrcz
Il aurait été plus facile d'utiliser d'une certaine manière le RAII pour cela, mais bon.Citation:
Envoyé par Davidbrcz
+1...Citation:
Envoyé par screetch
Je me sers souvent des templates (trop ? :aie:) depuis un bon moment, et j'ai du pour des petits projets ou simplement par défi faire en sorte que mon code soit accepté par des compilateurs pas assez à jour sur le sujet.
La preuve vivante que c'est possible est Boost. ASL et Loki se servent aussi pas mal des templates, et pourtant aucun soucis.
Et pourtant, comme Qt le montre, le policy-driven development pour des GUI ça se passe très bien, par exemple.
Ca sent la decision faite au debut du projet pour des raisons vraies a ce moment-la (1992) et qu'on commence (un peu tard peut etre) a remettre en cause.Citation:
Envoyé par screetch
A part que le preprocesseur est toujours necessaire.Citation:
Qt a admis avoir fait un preproc parce que a l'epoque de Qt le support des templates etait moisi. Depuis ils en sont revenus.
Memes causes, memes effets. On vit avec le passe.
Comme quelqu'un l'a deja ecrit, gtkmm est plus proche de ce qu'on concevrait maintenant.
Oui , mais c'est rare d'avoir besoin de templétiser des widgets de base.Citation:
Envoyé par Miles
Euh la heule des macros dans les table d'event c'est ca :Citation:
Envoyé par Miles
Et celle des fonction c'est ca :Code:
2
[/CODE]Code:
2
Il aurait été plus facile d'utiliser d'une certaine manière le RAII pour cela, mais bon.[/QUOTE]
On peut : Connect dans le constructeur , Disconnect dans le destructeur.
Edit : je commence a avoir mare de répondre surtout qu'il y personne pour m'aider a argumenter mais plusieurs pour argumenter contre moi :cry: .
Je vais donc tier ma conclusion partielle:
Pour des applications bureautique 'normale' : wx vaut Qt.
Pour une utilisation plus poussé : Qt a un avantage car il définit plus de widgets de base et son sytème d'event est dans doute légerement plus modulable.
En conclusion , je mettrai 4.5/5 a Qt et {3.5|4}/5 a wx (3.5 car certain widgets de Qt sans pas dispo chez wx).
Cela veut dire quoi policy-driven development ?Citation:
Envoyé par Alp
C'est lorsque l'on donne la possibilité de personnaliser le comportement des classes. Ceci est fait grâce aux templates.
Pour plus d'infos, mon article :)
ok merci.Citation:
Envoyé par Alp
Par contre je ne vois pas le rapport avec Qt... tu aurais le nom d'une class Qt pour illustrer cela?
Si mes souvenirs sont bons, on peut faire cela pour le redimensionnement (comportement lors d'un redimensionnement -> personnalisable), et quelques autres endroits que je ne me rappelle plus.
Le "policy-driven development" c'est sensé être fait avec les paramètres des template non?Citation:
Envoyé par Alp
Pas forcément, on peut aussi faire ça avec un héritage, on palre alors plus de pattern stratégie, mais c'est en gros la même chose.
C'est la même chose sauf que l'un est déterminé à l'exécution, l'autre à la compilation.
En combinant les deux, on peut avoir quelque chose de sympa, dont une partie est fait à la compilation, et l'on peut cependant changer le comportement pendant l'exécution.
Citation:
Envoyé par screetch
Ah si si, au boulot, j'utilise C++ Builder et Delphi pour écrire une application Web. :-)
Vive la galère
C'est parce que tu n'utilises pas les bons outils.
Au contraire, C++ est bien plus adapté pour faire ce genre de choses que les langages de script populaires.
En particulier, du côté performance et extensibilité, en C++, les applications web peuvent réellement être écrites de manière asynchrone, sécurisée, et très réactive, en décomposant l'acceptation, le chargement et la gestion des requêtes.
Bien évidemment ce n'est possible qu'avec FastCGI ou SCGI.
Voir par exemple Boost.CGI, bibliothèque en cours de développement.
Il y a aussi simplement des abstractions de haut niveau simples pour créer facilement des "scripts CGI" en C++, et non pas des serveurs complets, come cgicc.
tu perds aussi pas mal de temps à recompiler le projet quand tu veux simplement corriger un bug, C++ est p-e bien, mais oublie borland à ce niveau là.
Je préfère de loin m'amuser à développer en D pour obtenir la même qualité.
Le problème que j'ai, est que j'utilise de mauvais outils, que mes classes C++ sont partagées avec Delphi, et Java via un binding SWIG.
D'ailleurs, je me demande si le partage de classes via un connecteur C++->Delphi écrit en C++ est intéressant par rapport à des outils comme COM, & Co.