 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Robert CHERAMY
Guest
|
 Posted: Sat Jan 28, 2006 3:06 pm Post subject: Re: Toolkit graphique « vraiment » C++ |
 |
|
Bonjour,
loufoque wrote:
| Quote: | Macros (pour les signaux principalement), préfixes, pointeurs directs
(donc gestion mémoire manuelle), framework complet qui fait doublon
avec de nombreuses autres bibliothèques (dont la bibliothèque standard)
Personnellement, je n'aime pas la STL ni la taille des exécutables qui |
en découle, donc je suis plutôt content que Qt4 mette un Framework à ma
disposition.
Pour ce qui est des pointeurs et de la gestion de mémoire manuelle, je
ne vois pas de quoi vous voulez parler. Peut-être pouvez-vous citer un
exemple provenant des tutoriels Qt [1] utilisant des pointeurs directs ?
1. http://www.trolltech.com/pdf/whitepapers/qt40-whitepaper-a4.pdf
| Quote: | Ce n'est tout simplement pas du C++ moderne et standard.
Quelle librairie graphique proposez-vous si vous n'aimez ni Qt ni GTK+ ? |
tibob |
|
| Back to top |
|
 |
loufoque
Guest
|
| Posted: Sat Jan 28, 2006 3:06 pm Post subject: Re: Toolkit graphique «Â vraiment » C++ |
|
|
Christophe de Vienne a écrit :
| Quote: | Sous mac os je ne sais pas, mais sous windows je trouve ça plutôt bien (cf
the gimp, gaim...).
|
Je crois me rappeler (je n'ai plus windows) qu'il y a tout de même
certains bugs et que c'est un peu lent à réagir.
Pour Mac OS X, il faut installer un serveur X pour faire tourner les
applications GTK. |
|
| Back to top |
|
|
John Deuf
Guest
|
| Posted: Sat Jan 28, 2006 4:01 pm Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
Robert CHERAMY :
| Quote: | Personnellement, je n'aime pas la STL ni la taille des exécutables qui
en découle, donc je suis plutôt content que Qt4 mette un Framework à ma
disposition.
|
La taille des executables dependent du compilateur/linker que tu utilises
et de comment tu le configures, pas de la STL.
Et je crois vraiment que la taille de ton applcation sera beaucoup plus
elevee avec la bibliotheque Qt qu'avec la STL.
win32gui, comme j'ai mentionne plus bas.
http://www.torjo.com/win32gui/
Elle utilise directement la STL (pour ne pas reinventer la roue), les
smart pointers, les namespace, etc.
--
John Deuf |
|
| Back to top |
|
|
Fabien LE LEZ
Guest
|
| Posted: Sun Jan 29, 2006 5:00 am Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
On Sat, 28 Jan 2006 15:00:19 +0100, Robert CHERAMY
<news (AT) r (DOT) cheramy.net>:
| Quote: | Ce n'est tout simplement pas du C++ moderne et standard.
Quelle librairie graphique proposez-vous si vous n'aimez ni Qt ni GTK+ ?
|
WxWidgets ?
Même si je reporte toujours le moment de m'y mettre sérieusement.
Par contre, le parti pris de wxWigdets est d'être compatible avec
plein de vieux compilateurs C++. Donc, elle fournit aussi quelques
classes "doublons" (chaîne de caractères, tableau de chaînes, etc.),
même si les concepteurs tentent de maximiser la compatibilité avec la
bibliothèque standard. |
|
| Back to top |
|
|
Fabien LE LEZ
Guest
|
| Posted: Sun Jan 29, 2006 5:00 am Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
On 28 Jan 2006 15:10:43 GMT, John Deuf <nomail (AT) dontuseit (DOT) com>:
Est-ce stable, fiable, et suffisamment robuste pour une application
sérieuse ?
| Quote: | comme j'ai mentionne plus bas.
|
Ça veut dire quoi, "plus bas" ? |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Mon Jan 30, 2006 8:00 am Post subject: Re: Sens de const |
|
|
Yoxoman wrote:
| Quote: | kanze <kanze@gabi-soft.fr> a écrit :
C'est subtil dans le sens où certains gens ne voient pas la
différence entre enlever et effacer.
Qui est ?
On ne peut pas les employer dans le même contexte :
|
Oui, mais... Pourquoi ? Ce qui m'intéresse, c'est comment tu
expliques cette différence à partir d'une différence sémantique.
| Quote: | - On enlève ses chaussures, on enlève les doigts de son nez,
etc. L'objet existe toujours, il est déplacé, mis de côté.
|
D'accord. Encore que je ne suis pas sûr qu'il n'y a pas de
contre-exemples : enlever les poussières d'en dessous le lit,
par exemple.
| Quote: | - On efface un tableau, on efface la mémoire, etc. L'objet
n'existe plus.
|
Le tableau ou la mémoire n'existe plus ?
Je crois que c'est plutôt un sens d'enlever quelque chose de son
support, ou de remettre à blanc le support. En tout cas, dans
l'anglais « erase », il y a bien l'idée d'un support qui est en
fait l'objet de l'action. En programmation, sans doute pour des
raisons historiques, on a tendance à utiliser « clear » dans ce
sens, plutôt qu'« erase » (alors qu'on dirait jamais « clear the
blackboard ».) Appliquer litéralement à un élément d'une
collection, « erase » signifierait « remettre l'élément à zéro,
sans l'enlever de la collection ».
Mais ce n'est pas là mon propos. Je n'ai rien contre
l'utilisation de « erase » dans ce contexte, même si ce n'est
pas le mot que j'aurais choisi moi-même. Où j'ai un problème,
c'est cette distinction entre « erase » et « remove ». Parce
qu'en fin de compte, list<>::erase() et list<>::remove font
exactement la même chose -- la seule différence, c'est dans leur
manière de choisir l'élément ou les éléments à enlever.
Et évidemment, le fait que std::remove() n'enlève rien.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
John Deuf
Guest
|
| Posted: Mon Jan 30, 2006 12:01 pm Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
Fabien LE LEZ a écrit :
| Quote: | win32gui,
Est-ce stable, fiable, et suffisamment robuste pour une application
sérieuse ?
|
Ca dépend ce que tu entends par "stable", "fiable", "robuste",
"application", "sérieuse" et "suffisament".
Pour un projet qui mobilise une centaine de personnes sur plusieurs
mois, je crois que souvent le toolkit graphique est programmé en
interne.
Pour les autres projets, ceux qui savent s'accomoder de MFC pour faire
du GUI, je ne vois pas ce qui empeche win32gui de convenir parfaitement
(pour ne pas dire mieux).
| Quote: | comme j'ai mentionne plus bas.
Ça veut dire quoi, "plus bas" ?
|
Ca veut dire le message qui se trouve plus bas dans la liste des
messages de mon logiciel de news. |
|
| Back to top |
|
|
Fabien LE LEZ
Guest
|
| Posted: Mon Jan 30, 2006 1:01 pm Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
On 30 Jan 2006 03:42:20 -0800, "John Deuf" <franvalent (AT) free (DOT) fr>:
| Quote: | Ça veut dire quoi, "plus bas" ?
Ca veut dire le message qui se trouve plus bas dans la liste des
messages de mon logiciel de news.
|
Ah, OK.
Question subsidiaire : dans quel ordre ton logiciel affiche-t-il les
messages ? |
|
| Back to top |
|
|
Falk Tannhäuser
Guest
|
| Posted: Mon Jan 30, 2006 10:01 pm Post subject: Re: Sens de const |
|
|
kanze wrote:
| Quote: | Yoxoman wrote:
- On enlève ses chaussures, on enlève les doigts de son nez,
etc. L'objet existe toujours, il est déplacé, mis de côté.
D'accord. Encore que je ne suis pas sûr qu'il n'y a pas de
contre-exemples : enlever les poussières d'en dessous le lit,
par exemple.
|
D'après <http://www.rijeka.com/phun/general/murphy.htm>,
il ne s'agirait pas d'un contre-exemple :
"IMBESI'S LAW OF THE CONSERVATION OF FILTH:
In order for something to become clean, something
else must become dirty.
FREEMAN'S EXTENSION:
...but you can get everything dirty without getting
anything clean."
SNCR,
Falk |
|
| Back to top |
|
|
Yoxoman
Guest
|
| Posted: Tue Jan 31, 2006 9:01 am Post subject: Re: Sens de const |
|
|
kanze <kanze@gabi-soft.fr> a écrit :
| Quote: | Où j'ai un problème,
c'est cette distinction entre « erase » et « remove ». Parce
qu'en fin de compte, list<>::erase() et list<>::remove font
exactement la même chose -- la seule différence, c'est dans leur
manière de choisir l'élément ou les éléments à enlever.
|
Ils ne font pas *exactement* la même chose, heureusement. Et cela peut
justifier leur différence terminologique : dans leurs actions, erase et
remove ne s'appliquent pas à la même structure.
De la même manière qu'on efface *le* tableau et qu'on enlève *quelque
chose sur le* tableau, list<>::erase s'applique à la liste elle-même (ou
à une de ses parties), tandis que list<>::remove s'applique à ses
éléments.
list<>::erase a une sémantique orientée ensemble : on invalide une
partie de la liste, en bloc.
list<>::remove a une sémantique orientée élément : on invalide des
éléments déterminés de l'ensemble "liste".
| Quote: | Et évidemment, le fait que std::remove() n'enlève rien.
|
Parce que les algorithmes n'en ont pas le droit. Mais l'action est tout
de même comparable à celle de list<>::remove, donc il peut sembler
normal d'avoir le même nom.
--
"Yo!"
Martin Heidegger |
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Jan 31, 2006 10:01 am Post subject: Re: STL et __gnu_cxx |
|
|
"kanze" <kanze@gabi-soft.fr> writes:
[...]
| G++ l'a déplacée dans __gnu_cxx (où, je
| crois que tout le monde en est d'accord maintenant) il aurait dû
| être dès le début. D'autres n'ont pas ôsé casser du code
| existant chez leurs clients, et l'ont laissée dans std::.
|
| Depuis, la classe a été normalisée sous le nom
| std::unordered_map.
std::tr1::unordered_map
^^^
et ce n'est pas encore normalisé (au sens norme ISO), mais
effectivement un document officiel ISO "TR" (Technical Report) -- en
gros si un vendeur veut fournir une table de hashage, c'est comme
cela que le comité recommande.
À noter que hash_map n'a pas été retenu parce que certains, notamment
l'inénarrable MS, ont dit qu'ils ont déjà mis un truc de ce nom dans
std:: (une erreur kolossale.) Donc, on s'est coltiné le curieux
« unordered_map. » Aux dernières discussions (moins de quelques
mois), il a été suggéré que std::hash_map n'existera plus chez MS --
mais le comité ne changera quand même pas unordered_map à hash_map.
À noter également que GCC n'a pas été le seul à corriger l'erreur assez
rapidement, d'autres comme CodeWarrior ou Rogue Wave l'ont également
corrigée.
-- Gaby |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Wed Feb 01, 2006 9:00 am Post subject: Re: Sens de const |
|
|
Yoxoman wrote:
| Quote: | kanze <kanze@gabi-soft.fr> a écrit :
Où j'ai un problème,
c'est cette distinction entre « erase » et « remove ». Parce
qu'en fin de compte, list<>::erase() et list<>::remove font
exactement la même chose -- la seule différence, c'est dans leur
manière de choisir l'élément ou les éléments à enlever.
Ils ne font pas *exactement* la même chose, heureusement.
|
Et qu'est-ce qu'ils font de différent ? list<>::erase() ôte des
éléments de la liste. list<>::remove() ôte des éléments de la
liste. La seule différence, c'est la manière de désigner les
éléments.
| Quote: | Et cela peut justifier leur différence terminologique : dans
leurs actions, erase et remove ne s'appliquent pas à la même
structure.
|
Ils s'appliquent tous les deux à list<>. Obligatoire, en fin de
compte, parce qu'elles sont des fonctions membre.
| Quote: | De la même manière qu'on efface *le* tableau et qu'on enlève
*quelque chose sur le* tableau, list<>::erase s'applique à la
liste elle-même (ou à une de ses parties), tandis que
list<>::remove s'applique à ses éléments.
|
Toutes les deux s'appliquent aux list<>. Toutes les deux en
ôtent des éléments. Puisque les collections STL contiennent
toujours par valeur, tous les deux détruisent les éléments
qu'elles ôtent. AMHA, c'est un effet naturel de la contenance
par valeur (qui est elle un effet naturel de la façon que
travaille le C++), et pas une caractèristique sémantique
importante à signaler dans le nom. Mais de toute façon, elles
le font toutes les deux, de la même façon.
| Quote: | list<>::erase a une sémantique orientée ensemble : on invalide
une partie de la liste, en bloc.
list<>::remove a une sémantique orientée élément : on invalide
des éléments déterminés de l'ensemble "liste".
|
Toutes les deux ôte des éléments déterminés. Elles ne diffèrent
que dans la façon à désigner les éléments.
Et en passant... elles n'« invalide » pas les éléments ; elles
les ôtent carrément, en les enlevant et en les détruisant.
| Quote: | Et évidemment, le fait que std::remove() n'enlève rien.
Parce que les algorithmes n'en ont pas le droit.
|
C'est une restriction arbitraire:-).
En fait, c'est une restriction due à la structure de la
bibliothèque. Avec une autre structure, on pourrait imaginer
qu'un algorithme modifie la topologie de la suite -- les
collections de Java le font, par exemple.
Est-ce une bonne idée ? Je ne sais pas. La structure de OSE, par
exemple, le permettra techniquement, mais l'interface pour le
supporter n'a pas été prévue sur l'itérateur (en fait,
OTC_Modifier).
| Quote: | Mais l'action est tout de même comparable à celle de
list<>::remove, donc il peut sembler normal d'avoir le même
nom.
|
L'action de déplacer un objet dans une suite est comparable à
l'action de l'ôter de la suite ? Tu m'étonnes de plus en plus.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
Yoxoman
Guest
|
| Posted: Wed Feb 01, 2006 11:02 am Post subject: Re: Sens de const |
|
|
kanze <kanze@gabi-soft.fr> a écrit :
| Quote: | Yoxoman wrote:
kanze <kanze@gabi-soft.fr> a écrit :
Où j'ai un problème,
c'est cette distinction entre « erase » et « remove ». Parce
qu'en fin de compte, list<>::erase() et list<>::remove font
exactement la même chose -- la seule différence, c'est dans leur
manière de choisir l'élément ou les éléments à enlever.
Ils ne font pas *exactement* la même chose, heureusement.
Et qu'est-ce qu'ils font de différent ? list<>::erase() ôte des
éléments de la liste. list<>::remove() ôte des éléments de la
liste. La seule différence, c'est la manière de désigner les
éléments.
|
Nicolas Sarkozy et Olivier Besancenot font exactement la même chose : de
la politique.
Tout dépend du degré de précision que tu donnes à la *chose*. Pour moi,
il y a une différence entre ôter des éléments déterminés (au sens où
*je* détermine), et ôter des éléments qui correspondent à une partie
déterminée de la liste.
| Quote: | Et cela peut justifier leur différence terminologique : dans
leurs actions, erase et remove ne s'appliquent pas à la même
structure.
Ils s'appliquent tous les deux à list<>. Obligatoire, en fin de
compte, parce qu'elles sont des fonctions membre.
|
J'avais remarqué, merci. Ce que je veux dire, c'est que list<>::erase
s'oriente (sémantiquement) vers la liste elle-même, tandis que list
<>::remove s'oriente (sémantiquement) vers les éléments de la liste.
Et je trouve que ça correspond bien avec la différence de niveau
auxquels s'appliquent les termes effacer et enlever.
L'action d'effacer quelque chose se base sur ce quelque chose et
s'applique au contenu de ce quelque chose, alors que l'action d'enlever
quelque chose se base sur ce quelque chose et s'applique à ce quelque
chose lui-même.
Ce qui donne :
list<>::erase se base sur une partie de la liste et s'applique à son
contenu (ses éléments, qu'il ôte), alors que list<>::remove se base sur
des éléments déterminés (par moi) de la liste, et s'applique sur ces
éléments eux-mêmes (il les ôte).
C'est mon point de vue, et j'espère être clair. Je trouve que ça
justifie leur différence terminologique. C'est tout ce que je voulais
dire.
| Quote: | list<>::erase a une sémantique orientée ensemble : on invalide
une partie de la liste, en bloc.
list<>::remove a une sémantique orientée élément : on invalide
des éléments déterminés de l'ensemble "liste".
Toutes les deux ôte des éléments déterminés. Elles ne diffèrent
que dans la façon à désigner les éléments.
|
Déterminés par qui ? Dans list<>::erase, je ne détermine pas les
éléments à ôter. Par contre, je détermine la partie de la liste dont je
veux ôter les éléments.
| Quote: | Et en passant... elles n'« invalide » pas les éléments ; elles
les ôtent carrément, en les enlevant et en les détruisant.
|
Si tu veux.
| Quote: | Mais l'action est tout de même comparable à celle de
list<>::remove, donc il peut sembler normal d'avoir le même
nom.
L'action de déplacer un objet dans une suite est comparable à
l'action de l'ôter de la suite ? Tu m'étonnes de plus en plus.
|
Si les actions se résument pour toi à *ôter* et *déplacer*, non. C'est
bien sûr ailleurs qu'elles se comparent.
#include <iostream>
#include <list>
#include <iterator>
int main()
{
std::list<int> l;
typedef std::list<int>::iterator list_iter;
l.push_back(1);
l.push_back(2);
l.push_back(3);
l.push_back(2);
//l.remove(2); (1)
//list_iter it = std::remove(l.begin(), l.end(), 2); (2)
std::copy(l.begin(), l.end(),
std::ostream_iterator<int>(std::cout, " "));
}
avec (1), on obtient 1 3.
avec (2), on obtient 1 3 3 2, it désigne le troisième élément, et donc
la plage [l.begin(), it), c'est 1 3.
Je trouve ça comparable. Si ça t'étonne, tant pis.
--
"Yo!"
Martin Heidegger |
|
| Back to top |
|
|
Casillux
Guest
|
| Posted: Thu Feb 02, 2006 10:00 am Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
| Quote: | Moi je m'attends à ce qu'un toolkit graphique ne fasse que ça, me
laissant choisir les autres bibliothèques que je veux pour mes autres
besoins (réseau etc.)
|
La réponse est simple : Qt n'est pas un toolkit graphique. Elle contient
un toolkit graphique. C'est pour faire comprendre cela que dans la
version 4 ils ont découpé Qt en modules (QtCore, QtNetwork, Qtsql,
QtGui, etc...).
Donc on peut très bien faire QUE du graphique, ou faire tout avec Qt.
Mais vraiment je ne vois aucune raison d'utiliser autre chose..
| Quote: | Qt n'a apparemment pas non plus de pointeurs intelligents pour des
éléments partagés entre les widgets, et propose alors des méthodes
lourdes de ramasse-miettes.
Je ne comprends pas l'argument. Pour ce qui est des éléments graphiques, |
Qt gère tout, donc aucune question à avoir, ça marche.
Pour ce qui est des autres éléments, le développeur fait ce qu'il veut.
Il y a des pointeurs intelligent (QGuardedPointer) et aussi des outils
pour faire des ImplicitlySharedPointer.
Après pour le "vrai" C++, je pense qu'on passe dans le côté religieux et
non plus technique  . Tout ce que je vois c'est que c'est efficace
(dans tous les sens du terme). |
|
| Back to top |
|
|
Casillux
Guest
|
| Posted: Thu Feb 02, 2006 10:00 am Post subject: Re: Toolkit graphique « vraiment » C++ |
|
|
Tiens c'est bizarre, j'avais répondu à "loufoque" et le message apparaît
ici. Désolé. |
|
| Back to top |
|
|
Powered by phpBB © 2001, 2006 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
