Discussion :

[Davidbrcz]

S'il y a le moindre problème, on a du mal à savoir ce qui s'est mal passé.

Pourquoi il y aurait un problème ?
Les macros font derrière appel a connect.

[Matthieu Brucher]

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.

[Davidbrcz]

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é.

[Matthieu Brucher]

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
- ...

[Davidbrcz]

[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.

- s'il y a une opération à effectuer sur la variable

?? .On la fait , c'est tout.

- si on oublie de fermer la table
- ...

Ca ce voit sans difficulté pour put qu'on indente correctement sa table.

[screetch]

c'est hors sujet, mais

wxWidgets does not use templates (except for some advanced features that are switched off by default) since it is a notoriously unportable feature.

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.

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.

[Matthieu Brucher]

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.

L'explication est vaseuse, sérieusement...
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)

?? .On la fait , c'est tout.

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.

Ca ce voit sans difficulté pour put qu'on indente correctement sa table.

Il aurait été plus facile d'utiliser d'une certaine manière le RAII pour cela, mais bon.

[Alp]

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.

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.

+1...

Je me sers souvent des templates (trop ? ) 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.

[Jean-Marc.Bourguet]

wxWidgets does not use templates (except for some advanced features that are switched off by default) since it is a notoriously unportable feature.

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.

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.

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.

A part que le preprocesseur est toujours necessaire.

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.

[Davidbrcz]

L'explication est vaseuse, sérieusement...
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)

Oui , mais c'est rare d'avoir besoin de templétiser des widgets de base.

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.

Euh la heule des macros dans les table d'event c'est ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
EVT_BUTTON  (BUTTON1,MyFrame::OnButton1)

Et celle des fonction c'est ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
void MyFrame::OnButton1(wxCommandEvent & event){/*... */}

[/CODE]
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 .

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).

[yan]

Et pourtant, comme Qt le montre, le policy-driven development pour des GUI ça se passe très bien, par exemple.

Cela veut dire quoi policy-driven development ?

[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

[yan]

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.
Par contre je ne vois pas le rapport avec Qt... tu aurais le nom d'une class Qt pour illustrer cela?

[Alp]

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.

[yan]

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?

[Matthieu Brucher]

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.

[Alp]

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.

[swirtel]

Je parle de webapp, pas de pages generees par script. Je parle plutot de Tomcat, Cocoon, etc, qui sont des outils Java. Je suis pas a mon aise dans ce sujet mais je sais que les sites Web sont soit scriptes en PHP/ASP/perl/autres, soit sont geres par des machines virtuelles Java qui repondent aux requetes. Mais l'important est que le C++ n'apparait jamais dans cette liste !

Ah si si, au boulot, j'utilise C++ Builder et Delphi pour écrire une application Web. :-)

Vive la galère

[loufoque]

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.

[swirtel]

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.