Symbian fait son entrée aux côtés des principales plate-formes supportées officiellement que sontLinux, Mac OS X, Windows et Windows CE. Symbian est un système d'exploitation pour smartphones détenu par Nokia (qui est également le propriétaire de Qt depuis janvier 2008). La prise en charge de Symbian se fait au travers du framework S60. Qt, c'est quoi?
Si un seul adjectif devait désigner Qt, c'est bien celui de vaste. Cette bibliothèque permet bien plus que de simplement développer des applications graphiques portables et permet également de faire (liste non exhaustive) :
- du réseau (QtNetwork)
- de la manipulation de documents XML (QtXml, QtXmlPatterns et QtSvg) ; un moteur de rendu HTML basé sur WebKit est également intégré (QtWebKit)
- de la base de données relationnelle (QtSql) (avec un support natif des principales bases de données comme DB2, MySQL, Oracle, ODBC, PostgreSQL ou SQLite
- du multimédia via Phonon (Phonon module) développé au sein de KDE
- du script via QtScript (QtScript)
- de la 3D via OpenGL (QtOpenGL)
- de l'internationalisation via un outil pour les traducteurs : Qt Linguist (internationalization)
- de la programmation concurrente via des processus légers (threads) ou un framework généraliste QtConcurrent (threads QtConcurrent)
- des tests unitaires (QtTest)
- de créer des interfaces graphiques pour les non-programmeurs via l'excellent Qt Designer (Designer manual)
- ...
Qt ne se limite pas au C++ (bien que cela soit le langage de prédilection et le seul officiellement pris en charge depuis l'arrêt de QtJambi pour Java) car plusieurs bindings existent : Python, Java, C# et quelques autres moins avancés.
Cette version, elle apporte quoi de nouveau ?
Passons maintenant aux nouveautés de cette version :
Deux frameworks développés en interne depuis plusieurs mois et dont nous avons eu des aperçus via les blogs des développeurs de Qt apparaissent :
- Animation, issu du projet Kinetic, il permet de créer des animations d'éléments graphiques et de jouer sur leurs propriétés
- State Machine, qui utilise la sémantique des machines à état State Chart XML promue par le W3C. Ce framework simplifie la gestion des changements d'état (comme un bouton qui passe de non cliqué à cliqué) et l'action à réaliser qui suit.
L'embarqué étant le secteur principal d'activité de Nokia, Qt se devait de fournir des outils pour gérer les évènements multi-points (comme sur l'iPhone pour donner une idée) et la gestuelle, c'est chose faite avec l'apparition des classes QTouchEvent et QGestureEvent.
La gestion d'XML est encore développée et après la gestion de XPath, XQuery et XSLT, vient s'ajouter dans cette version celui des Schema XML du W3C, permettant de valider un document XML. La manipulation d'éléments d'une page HTML est également facilitée via l'ajout de la classe QWebElement qui permet, entre autre, de sélectionner des éléments via les sélecteurs de CSS2.
Le développement du multimédia continue comme annoncé. Avec Qt 4.6, un nouveau module est ajouté, QtMultimedia, qui fournit un accès bas niveau au système audio, mais également vidéo via l'arrivée de plusieurs classes représentant des images d'un flux vidéo.
Concernant WebKit, la version est mise à jour depuis le tronc et un remplacement en règle est réalisé dans QtScript pour utiliser JavaScriptCore, l'interpréteur JavaScript de Webkit qui fait de la compilation juste à temps. Ce remplacement permet dans la majorité des cas une amélioration faramineuse (QtScript in 4.6). Toujours en ce qui concerne WebKit, une classe QWebInspector représentant l'outil d'analyse d'une page Web (l'équivalent de l'inspecteur DOM de Firefox) fait son apparition est permet d'intégrer cet outil dans une application Qt (mais son adaptation visuelle selon la plate-forme n'est pas encore au menu de cette version...).
Pour finir dans les nouveautés, une nouvelle classe de positionnement des widgets fait son apparition : QGraphicsAnchorLayout. Dédié aux éléments QGraphics, elle permet de les positionner relativement les un par rapport aux autres. Une présentation technique de cette classe est réalisée sur un Qt Blogs.
Comme j'ai bien évidemment dû oublier quelques nouveautés, une consultation de la page dédiée dans la documentation ne serait pas de trop pour les plus curieux d'entre vous.
Autour de Qt
Qt Creator, l'environnement de développement dédié à Qt, dont la première version est sortie en même temps que la version 4.5, est également mis à jour dans sa version 1.3. À côté de diverses améliorations, comme celle de la complétion et l'ajout d'un début de refactorisation, du support de Symbian, et de bien d'autres, s'en cache une qui pourrait intéresser nombre de lecteurs de LinuxFr : la traduction en français des outils Qt. Cette traduction, ainsi que celles en allemand, espagnol, italien, japonais, polonais, russe et slovène sont rendues possibles grâce à l'aide de la communauté qui a abattu un gros travail (Qt Créateur - Qt Creator is also in French). Ces contributions sont rendues possibles grâce à l'ouverture de plus en plus grande du développement de Qt, qui avant était fermé (même si l'on avait accès au source) et n'acceptait pas de contribution.
Concernant KDE dont le développement est intimement lié à celui de Qt, la prochaine version majeure, la 4.4, dont la sortie prévue est pour février 2010, utilisera cette version de Qt.
Le futur
Il est prévu en 2010 la livraison de plusieurs choses :
La plus importante est peut-être l'arrivée de Declarative UI et du langage de description QML. Ce sont la dernière partie du projet de recherche Kinetic (qui pour rappel contient les frameworks Animation et State Machine). L'utilisation de QML (dont un début de support est présent dans Qt Creator 1.3) se veut comme une nouvelle manière de décrire les interfaces graphiques (ce que fait actuellement les fichiers .ui de QtDesigner) et comment elles doivent se comporter (et c'est là la nouveauté). L'utilisation de QML a pour objectif de rendre la conception d'interfaces graphiques attrayantes (comprendre ici : contenant des effets de transitions entre les actions comme on en rencontres souvent dans de nombreuses interfaces utilisateurs de smartphones) plus facile. Un petit tour sur un des Qt Blogs explique plus en détail à quoi ressemble QML et ce que l'on peut en faire. Le projet KDE a rapidement vu l'intérêt de QML et a décidé de commencer à travailler sur son utilisation dans Plasma (le logiciel qui gère le bureau de KDE) et ses Plasmoids (des applications à "coller" où on veut sur le bureau).
A cela s'ajoute plusieurs cas d'utilisations spécifiques aux smartphones (mais qui dans certains cas sont pertinents pour le bureau) qui vont être pris en charge par Qt et connu sous le nom de Mobility Project. Ce sera notamment le cas de la géolocalisation, de la gestion de contacts, de l'envoi de messages (SMS, MMS, Jabber via XMPP et bien sûr courriel), etc. Un aperçu de l'API est disponible sous forme de Technology Preview et attend des commentaires.
Et, pour finir dans les grands projets dont la sortie est prévue en 2010 : la prise en charge de Maemo (la plate-forme de développement utilisée par certains appareils de Nokia) est prévue. Pour l'instant Maemo utilise GTK+, le portage de Qt sur cette plate-forme ne semble pas de bonne augure pour GTK+…
À plus long terme est prévu (en vrac et de manière non exhaustive) : une refonte du système de compilation, le support de SOAP (très utile pour les Web Services), une nouvelle génération de widgets (qui devrait prendre tout son sens avec l'utilisation de tous ce qui est issu du projet Kinetic), une nouvelle architecture pour la version Linux dédiée à l'embarqué (portant le doux nom de projet Lighthouse), une API 3D portable pour le bureau et l'embarqué (avec peut-être la fin de l'utilisation d'OpenGL directement...), etc.
Pour plus de détail sur les projets en cours, vous pouvez consulter une petite feuille de route.
Au final, je ne sais pas pour vous, mais je trouve le développement de Qt de plus en plus excitant !
Aller plus loin
- La documentation officielle (14 clics)
- Les nouveautés de cette version (5 clics)
- Le journal des modifications (1 clic)
- Qt Creator (15 clics)
- Qt sur Wikipédia (16 clics)
- Qt (3 clics)
# Une si bonne API
Posté par alice . Évalué à -10.
[^] # Re: Une si bonne API
Posté par yellowiscool . Évalué à 8.
Si tu penses aux makefiles, Qt propose QMake par exemple.
Certes, il reste les erreurs à rallonge de gcc (mais ce n'est pas spécifique au C++), et la syntaxe qui n'est pas la plus fun en ce moment mais qui a l'immense avantage d'être compatible avec celle du C.
Envoyé depuis mon lapin.
[^] # Re: Une si bonne API
Posté par Larry Cow . Évalué à 2.
Le C++ a pourtant sa "marque de fabrique" avec les problèmes liés aux templates. Ceci étant, il faut bien admettre que ce n'est pas avec Qt que ça pèse le plus.
qui a l'immense avantage d'être compatible avec celle du C.
Avantage, avantage, c'est vite dit. Pour ceux qui sont à l'aise en C et ne veulent pas se mettre à autre chose, pourquoi pas, mais ça devient rare.
[^] # Re: Une si bonne API
Posté par Zenitram (site web personnel) . Évalué à 6.
C'est un avantage, non pas pour ceux qui sont à l'aise avec le C, mais pour ceux qui ont un existant, des bibliothèques déjà construites.
Car bon, le langage qui est le plus compatible avec les autres, ça reste le C quand même, il y a une tonne de binding d'autres langages pour des libs C, et pas l'inverse. (c'est quand même bizarre de voire que tous les langages "modernes" ont une interface pour accéder à des fonctions C...)
[^] # Re: Une si bonne API
Posté par Larry Cow . Évalué à 5.
Sans compter qu'en l'occurrence, un code C valide n'est pas forcément un code C++ valide (à la différence de l'Objective-C, si j'ai bonne mémoire). Donc la compatibilité niveau source, bon...
Reste que je ne suis pas certain que le fait de pouvoir copier/coller un snippet en C dans un code en C++ suffise à justifier une syntaxe aussi lourde.
[^] # Re: Une si bonne API
Posté par Gof (site web personnel) . Évalué à 3.
(Je ne dis pas que ça justifie, je donne juste un avantage.)
[^] # Re: Une si bonne API
Posté par Victor STINNER (site web personnel) . Évalué à 5.
C++0x vise à simplifier les messages d'erreur des compilateurs.
http://linuxfr.org/2009/07/24/25763.html
la syntaxe qui n'est pas la plus fun en ce moment mais qui a l'immense avantage d'être compatible avec celle du C
Contrairement à une idée reçue, C et C++ sont deux langages différents. Écrire des bouts de C en C++, c'est possible, mais c'est très crade (ex: mélanger printf(...) et cout<<...). D'ailleurs, quand on débute en C++, on a tendance à coder C plutôt qu'en C++ (genre préférer les structures aux objets).
[^] # Re: Une si bonne API
Posté par Étienne . Évalué à 3.
Depuis qu'il a été décidé de supprimer les concepts de la prochaine version du C++, ce n'est plus le cas.
Étienne
[^] # Re: Une si bonne API
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Une si bonne API
Posté par lasher . Évalué à 4.
Qui est ce « on » ? J'ai appris C et C++ la même année (6 mois de C globalement, 2-3 mois de C++, mais juste la partie « C avec classes », donc pas de templates, pas d'utilisation de namespaces, etc). Dès le départ, on nous avait fait utiliser cout. Alors oui, il s'agissait de cours d'IUT, et oui, le fait de choisir C++ plutôt que Java n'était sans doute pas anodin, mais dès le départ, pas mal de choses étaient claires.
Les gens qui font « du C » en C++ ce sont des gens qui font du procédural dans un langage orienté objet, selon moi (donc utilisation de méthodes de classes ou de fonctions, utilisation de codes de retour plutôt qu'utiliser les exception quand clairement ça se justifierait, etc). Et ça par contre, je l'ai déjà vu faire, même (surtout ?) avec des gens qui avaient 20 ans d'expérience.
[^] # Re: Une si bonne API
Posté par reno . Évalué à 3.
Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf, ce qui est très rependu..
[^] # Re: Une si bonne API
Posté par GeneralZod . Évalué à 5.
ça montre surtout que ton niveau en C++ n'est pas très bon. Les flux C++ offrent par rapport aux entrées/sorties C la sûreté de typage, moins d'erreurs possibles (avec les % notamment), facilement extensibles avec les types utilisateurs (suffit de redéfinir les opérateurs, en C rien de comparable, bien que la GNU libc offre quelques crochets).
Encore printf ça peut passer, mais des horreurs comme scanf non.
[^] # Re: Une si bonne API
Posté par rewind (Mastodon) . Évalué à 4.
std::cout << "j'ai " << nbChiens << " chiens et " << nbCats << " chats." << std::end
vs
printf("J'ai %d chiens et %d chats\n", nbChients, nbChats);
En revanche, il y a plein de cas où c'est super pratique, genre les fichiers de log.
[^] # Re: Une si bonne API
Posté par GeneralZod . Évalué à 3.
Tu as d'autres alternatives pour les chaines formatées comme la classe autosprintf fournie avec gettext, ou bien Boost.Format qui gérent en interne leur propre flux. Best of both worlds comme on dit.
Pour revenir à Qt, la solution recommandée c'est d'utiliser la méthode arg de QString qui offre la souplesse et une sûreté de typage comparable à celle de Boost.Format.
Par ailleurs, l'utilisation de std::endl au lieu de '\n', n'est pas forcément recommandé, std::endl force le flush du buffer d'écriture, à utiliser avec modération.
[^] # Re: Une si bonne API
Posté par kowalsky . Évalué à 2.
[^] # Re: Une si bonne API
Posté par reno . Évalué à 4.
Je ne suis pas le seul a le penser: le concepteur de D (un langage 'réinventant' le C++) qui est un expert C++ (il a codé un compilateur C++) a fait pour D 'writef' qui est une version améliorée de printf, PAS 'cout <<'..
[^] # Re: Une si bonne API
Posté par GeneralZod . Évalué à 3.
Elle est surtout "defective by design".
Les chaines C, printf, etc ... tout ça c'était l'état de l'art dans les années 70/80, depuis, les std::string et les flux C++ sont arrivés. Certes, std::string et les flux C++ ont montrés leurs limites, mais Boost (qui porte bien son nom) permet de pallier à bon nombre de ces défauts.
Pour des entrées/sorties console, tu as de moins en moins de raisons d'utiliser les antiquités hérités du C.
Quant aux toolkits modernes, ils offrent des type string adaptés (support d'unicode, capacité de formatage robuste, i18n, etc ...), souvent interopérables avec la SL (je pense à QString, mais également glib::ustring ou bien wxString).
> le concepteur de D (un langage 'réinventant' le C++) qui est un expert C++ (il a codé un compilateur C++) a fait pour D 'writef' qui est une version améliorée de printf, PAS 'cout <<'..
writef n'a récupéré de printf que la syntaxe de formatage et un nom vaguement similaire. writef est type safe, comme tu le dis Walter Bright a une grande expérience dans l'implémentation de langage de programmation. Ça reste néanmoins plus proche de ce qui se fait en C++ qu'en C (même si personnellement, je trouve que ça s'inspire plus de l'équivalent Java en beaucoup moins bordélique).
Enfin, les entrées/sorties fournies par Tango la bibliothèque standard alternative sont nettement supérieures (ironiquement, l'équivalent de writef dans Tango s'appelle Cout ...) avec des capacités de formatage proches de ce qui fait actuellement (Boost.Format, QString, python, C#, etc ...). Et la bibliothèque standard la plus utilisée est Tango et non pas Phobos, celle qui offre des entrées/sorties le plus proche du C++.
[^] # Re: Une si bonne API
Posté par Larry Cow . Évalué à 2.
Ça tombe bien, depuis le début du thread on parle de la syntaxe de printf, et non de son implémentation/conception.
[^] # Re: Une si bonne API
Posté par GeneralZod . Évalué à 2.
Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf
> Ça tombe bien, depuis le début du thread on parle de la syntaxe de printf, et non de son implémentation/conception.
Et juste en dessous, je précise que la bibliothèque D standard la plus utilisé (Tango) offre des entrées/sorties inspirées du C++ avec des capacités de formatage modernes comme ce qui se fait aujourd'hui.
La syntaxe printf est certes pratique mais dépassée, les syntaxes modernes permettent de réutiliser plusieurs fois le même argument, de modifier l'ordre des arguments etc ...
Si ça te chante, tu peux très bien faire ta propre fonction improved_printf qui gère son propre flux en interne. Les entrées/sorties C++ sont un poil plus bas-niveau que leur homologue C mais en contrepartie, elles sont plus sûres et extensibles. L'absence de fonctionnalités plus haut niveau dans le standard est regrettable mais ce n'est pas une raison valable pour préférer printf. Le problème des bibliothèques standards, c'est que tu ne peux pas tout inclure dedans et il vaut mieux réfléchir plusieurs fois avant d'inclure quelque chose dedans.
Et c'est oublier des extensions de la bibliothèque standard comme Boost (ou même POCO), ou bien ce que propose n'importe quel toolkit moderne comme Qt.
[^] # Re: Une si bonne API
Posté par fearan . Évalué à 2.
certaines implémentation de printf le permettent maintenant:
printf("%1$d %1$d", 3);
et tu peux mettre l'ordre que tu veux
printf("%3$d %1$d %2%d", 4, 8, 9);
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Une si bonne API
Posté par Étienne . Évalué à 4.
int num=12, width=8;
char fillChar='#';
std::cout << std::setfill(fillChar) << std::setw(width) << num;
Alors certes c'est parfois un peu verbeux lorsqu'il n'y a aucun formatage à faire mais dès qu'on veut faire la moindre petite chose c'est à la fois puissant, expressif et beaucoup plus souple qu'une chaîne de format.
[^] # Re: Une si bonne API
Posté par Moonz . Évalué à 2.
[^] # Re: Une si bonne API
Posté par Étienne . Évalué à 3.
Étienne
[^] # Re: Une si bonne API
Posté par Moonz . Évalué à 3.
Bon, quitte à entrer dans le troll, allons-y franchement.
Comment fais-tu :
* pour utiliser gettext avec ce magnifique système ? Les défenseurs de C++ ont toujours tendance à considérer ce point comme négligeable et à l’occulter ; en pratique, il ne l’est absolument pas (négligeable)
* un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
[^] # Re: Une si bonne API
Posté par Étienne . Évalué à 2.
* pour utiliser gettext avec ce magnifique système ? Les défenseurs de C++ ont toujours tendance à considérer ce point comme négligeable et à l’occulter ; en pratique, il ne l’est absolument pas (négligeable)
On peut utiliser boost format (ou d'autres, loki safeformat, fastformat, ...) qui s'intègrent très bien avec gettext tout en étant typesafe.
* un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
Sur ce point on a une bien plus grande souplesse avec les flux de la STL qui sépare bien la partie formatage de la partie lecture/ecriture à travers les streambuf. Ce qui permet de faire des choses comme :
* écrire dans plusieurs fichiers simultanément
* fournir un pourcentage de progression au fur et à mesure de la lecture d'un fichier
* lire depuis/vers un buffer,
* lire depuis/vers une socket
* ...
Il suffit pour cela de fournir son propre streambuf. On peut pour cela s'aider de boost::iostreams qui simplifie bien les choses.
Pour simplement faire un tee, on peut aussi faire comme en C
On peut trouver, et à raison, que la STL est un peu complexe à ce niveau, mais on a une souplesse indéniable.
Étienne
[^] # Re: Une si bonne API
Posté par Moonz . Évalué à 3.
On parle des librairies standard, là. À ce niveau, je peux te dire que l’implémentation de GCC est capable de vérifier les types (certes, il n’émet que des warnings)
> Il suffit pour cela de fournir son propre streambuf
Si je t’ai fourni un problème concret, c’est bien parce que le niveau stratosphérique ne m’intéresse pas. Je sais pertinemment que tu peux fournir tes propres classes pour les IO. La question implicite était : sur un problème simple, peux-tu me faire là, maintenant, en 5 minutes, une solution simple ? Ce que je voulais savoir, c’était la faisabilité pratique de la chose.
[^] # Re: Une si bonne API
Posté par GeneralZod . Évalué à 2.
Comme je l'ai précisé plus haut, les flux C++ sont des briques bas-niveau, rien ne t'interdit de construire un système de formattage par dessus. C'est ce que fait Boost.Format (avec des capacités supérieures à ce que propose C89/99), ou bien la classe autosprintf fourni par gettext qui en interne gère un flux C++. Tu bénéficies de la sûreté de typage tout en gardant les avantages du formatage.
> un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
À ce niveau là, la bibliothèque standard C et les flux C++ sont à égalité.
Certes le système des flux C++ est plus complexe à assimiler, mais une fois qu'on a compris, ça roule (Stroustrup a même fait un joli schéma). Pour ton exemple de tee, ça n'a rien de compliqué, il suffit de réécrire une classe héritant de std::streambuf qui redirige l'entrée vers plusieurs objets std::streambuf, et pour faire la redirection, tu utilises la méthode rdbuf pour faire la substitution. Tu peux écrire une classe héritant d'ostream pour avoir une interface plus agréable.
Boost.Iostreams facilite l'écriture de buffers, flux et filtres et fournit une collection d'objets prêt à l'emploi dont un tee.
ofstream ofs("mon_fichier.log");tee_device<ostream, ofstream> teeDevice(cout, ofs);
stream teeStream(teeDevice);
teeStream << "comment faire un tee avec Boost, ne pas oublier de flusher le buffer !"<<std::endl;
teeStream.close();
Vachement compliqué à utiliser, non ?
Cette discussion confirme qu'une bonne partie des développeurs C++ ont une connaissance très partielle du langage y compris des bases (on parle quand même des entrées/sorties !).
Ça ne m'étonne guère, C++ en soi est ardu d'apprentissage, la plupart des formations enseigne un dialecte déprécié (le fameux C avec classes), les implémentations conformes à la norme se sont fait attendre longtemps etc...
Mais avant d'accuser C++ de tout les maux, faudrait peut-être l'apprendre correctement avant et choisir les bons outils. Aujourd'hui, un développeur C++ digne de ce nom doit être familier avec Boost ou du moins une bonne partie de Boost
[^] # Re: Une si bonne API
Posté par Moonz . Évalué à 2.
Clairement, non, et je m’en doutais.
Ce qui me laisse plus dubitatif au niveau simplicité, c’est l’implémentation de tee_device.
(malheureusement, mon proxy http étant tombé (probablement pour le week-end), je n’ai plus accès qu’à https, un exemple ici serait le bienvenu, même simplifié ; je n’ai pas boost installé sur ma machine)
> Comme je l'ai précisé plus haut, les flux C++ sont des briques bas-niveau, rien ne t'interdit de construire un système de formattage par dessus.
Et comme dit également plus haut, ce sont les méthodes standard de la librairie standard qui nous intéressent. Si la librairie standard n’est même pas fichue de faire des IO adaptables simplement, autant ne pas s’embêter à en fournir une.
> Cette discussion confirme qu'une bonne partie des développeurs C++ ont une connaissance très partielle du langage y compris des bases (on parle quand même des entrées/sorties !)
1. Je ne suis pas un développeur C++, juste un curieux, curieux de comprendre comment on peut appeler « supérieur » un système d’IO qui nécessite de connaître en profondeur les subtilités d’un langage réputé très complexe (héritage de classes templatées, il ne me semble pas que ce soit le chapitre 1 d’un bouquin de C++…) pour faire quelque chose d’aussi simple qu’une fonction tee() ou gettext() (utiliser une librairie externe comme boost n’est pas une réponse, on discutait des librairies standard)
2. Est-ce la faute du langage (j’inclus dans langage la librairie standard, mais pas les librairies externes : le dénominateur commun de ce que je peux faire avec un gcc, icc et visual studio fraichement installés) ou du développeur si la base (les IO) de la base (la librairie standard) n’est pas simplement assimilable ?
[^] # Re: Une si bonne API
Posté par GeneralZod . Évalué à 2.
Voici comment faire sans bibliothèque extérieure.
#include
#include
#include
class TeeBuf: public std::streambuf
{
public:
TeeBuf(std::streambuf * buf1, std::streambuf * buf2): buf1(buf1), buf2(buf2) {}
private:
int overflow(int c)
{
if (c == EOF) {
return !EOF;
} else {
return (EOF == buf1->sputc(c)) || (EOF == buf2->sputc(c)) ? EOF : c;
}
}
int sync()
{
return (0 == buf1->pubsync()) && (0 == buf2->pubsync()) ? 0 : -1;
}
private:
std::streambuf * buf1;
std::streambuf * buf2;
};
class TeeStream : public std::ostream
{
public:
TeeStream(std::ostream &o1, std::ostream &o2) : std::ostream(&buf), buf(o1.rdbuf(), o2.rdbuf()) {}
private:
TeeBuf buf;
};
int main()
{
using std::cout;
std::ofstream ofs("mon_fichier.txt");
/* avec TeeBuf */
std::streambuf *sortieLog = ofs.rdbuf();
std::streambuf *sortieStandard = cout.rdbuf();
TeeBuf *teeBuf = new TeeBuf(sortieStandard, sortieLog);
std::streambuf *oldBuf = cout.rdbuf(teeBuf);
cout<<"hello ";
cout.rdbuf(oldBuf);
/* avec TeeStream c'est un poil plus agréable */
TeeStream tee(cout, ofs);
tee<<"world!"<<std::endl;
ofs.close();
return 0;
}
> Et comme dit également plus haut, ce sont les méthodes standard de la librairie standard qui nous intéressent. Si la librairie standard n’est même pas fichue de faire des IO adaptables simplement, autant ne pas s’embêter à en fournir une.
Tu soulèves un dilemme qui touche tout les concepteurs de langages de programmation, quel doit être le contenu de la bibliothèque standard ?
C++ a fait le choix de fournir un système d'entrée/sortie souple et puissant (pas super compliqué) mais très rugueux, c'est un choix parmi d'autre.
> Je ne suis pas un développeur C++, juste un curieux, curieux de comprendre comment on peut appeler « supérieur » un système d’IO qui nécessite de connaître en profondeur les subtilités d’un langage réputé très complexe
Il est pas si complexe que ça, les IO Java sont bien plus tordues que ça à mon avis.
Si tu te limites à de l'affichage console, l'écriture dans des fichiers, c'est pas plus compliqué qu'avec les entrées/sorties C. Là, on s'attaque à un problème bien spécifique: i18n.
On peut s'attaquer aux entrées/sorties sans forcément devoir s'occuper des détails, std::string est également une spécialisation d'une classe templaté et ça ne pose pas de problèmes.
Enfin, si c'est pour faire du C en C++ sans utiliser les fonctionnalités avancés (stdio, pas de RAII, pas d'exception, pas de templates etc ..), autant faire du C.
> Est-ce la faute du langage ou du développeur si la base (les IO) de la base (la librairie standard) n’est pas simplement assimilable ?
Je dirais les deux, d'une part, C++ est un langage assez rugueux, de l'autre, C++ est très mal enseigné ce qui n'aide pas. Les concepteurs du langage en sont conscients (C++0x va dans ce sens) et cherchent à simplifier le langage.
C++ n'est clairement pas un langage adapté à des débutants en programmation, même si le dernier bouquin de Stroustrup (adaptation de son cours à des 1ères années de fac) démontre que c'est possible (une traduction est en cours aux éditions Pearson fr).
Dans le bouquin, il enseigne un style de programmation C++ moderne et n'aborde le sous-ensemble C du C++ que dans le dernier chapitre tout en restant accessible à tous.
Que ce soit en C ou en C++, si tu te limites à la bibliothèque standard, tu risques pas d'aller bien loin. Boost est aussi essentiel à un développeur C++, que Posix l'est à un développeur C.
[^] # Re: Une si bonne API
Posté par lasher . Évalué à 2.
Suivant que tu veux faire une « surcharge » de printf ou pas (genre écrire un fillprintf(const char *format, ...)), faire ce que tu veux en C est soit loin d'être trivial (pour rajouter une option à analyser dans la chaîne, il faut se retaper toute la chaîne globalement, et tout analyser), ou bien tu fais une fonction du genre fill_string(const char *format, const size_t pos, const char filler, ...);
Tout dépend.
Je suis d'accord pour dire que les streams C++ ne sont pas si pourris que ça. Par contre, leur apprentissage n'est pas évident selon moi.
# Dépêche de qualité
Posté par Hojo . Évalué à 10.
[^] # Re: Dépêche de qualité
Posté par sanao . Évalué à 10.
[^] # Re: Dépêche de qualité
Posté par dinomasque . Évalué à 10.
Les dépêches de cette qualité sont rares.
BeOS le faisait il y a 20 ans !
# Multitouch
Posté par reeth . Évalué à 5.
Au niveau du multitouch il semblerait que les développeurs ne l'utilisent que sur les ports windows et mac (à travers les ports de KDE4) à cause du manque de solution sous linux...
Qu'en est-il du support de cette technologie au sein de X? Quelles sont les échéances? Un an? Six mois? Y a-t-il des problèmes particuliers qui empêchent l'émergence d'une solution (brevets...) ou bien « seulement » un manque de moyen en développement?
Je trouve dommage que Qt qui se veut multiplateforme soit tronqué d'un de ses plus grands apports en terme d'ergonomie utilisateur pour sa version linux (sachant que KDE sous linux pourrait tirer parti de cette technologie assez rapidement par exemple).
[^] # Re: Multitouch
Posté par sanao . Évalué à 3.
Maintenant, je n'ai pas tester cette fonctionnalité...
[^] # Re: Multitouch
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Multitouch
Posté par eMerzh (site web personnel) . Évalué à 1.
Malheureusement, cette partie multitouch ne repose pas sur MPX, ils utilisaient un événement avec des positions différentes plutôt que plusieurs évènements.
La personne semblait dire qu'un support de MPX n'allait pas tarder...
[^] # Re: Multitouch
Posté par Anonyme . Évalué à 2.
il y a cela qui indique tout de même que linux n'est pas en reste
http://www.notmart.org/index.php/Software/Multitouch_screenc(...)
(enfin pas la première qui visiblement tourne sous seven)
# La naissance du port Symbian
Posté par GeneralZod . Évalué à 6.
http://labs.trolltech.com/blogs/2009/12/01/a-brief-history-o(...)
# Oo !
Posté par Dorian . Évalué à 4.
Après avoir lu les pages des liens, je suis bluffé ! Je passe dès ce soir à Archlinux KDE !
Et le coup final qui ferait baver n'importe quel developpeur : http://qt.nokia.com/developer/qt-roadmap
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Oo !
Posté par GeneralZod . Évalué à 9.
[^] # Re: Oo !
Posté par Dorian . Évalué à 1.
Tout est relatif, déjà ca te fait une tonne de libs en plus, il y a quelques bugs (la zone d'entrée de texte qui devient noire quand on écrit, les notifications, ...), graphiquement c'est pas super bien adapté.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Oo !
Posté par GeneralZod . Évalué à 8.
C'est relatif, en embarqué, on se limitera souvent à un seul toolkit graphique (et encore, c'est de moins en moins le cas), sur un desktop, c'est nettement rare.
Qt n'est pas plus lourd que Gtk+, wxWidgets & cie, et en terme de dépendances, rien d'extravaguant par rapport à un GNOME vanilla.
> il y a quelques bugs (la zone d'entrée de texte qui devient noire quand on écrit, les notifications, ...)
Jamais rencontré et pas recensé chez Fedora.
https://admin.fedoraproject.org/pkgdb/packages/bugs/qt
Le seul bogue graphique était un affichage bogué dans qtdemo-qt4 lié au pilote Intel, et il a été corrigé dans Qt 4.6.
> graphiquement c'est pas super bien adapté.
Avec QGtkStyle, tu remarques à peine la différence graphiquement.
Personnellement, je trouve que les applications s'intègrent mieux dans un environnement GNOME que les applications wxWidgets qui pourtant s'appuie sur Gtk+ sous GNU/Linux.
[^] # Re: Oo !
Posté par Gof (site web personnel) . Évalué à 10.
une tonne de libs en plus ?
Non, juste une: Qt (ok, elle est subdivisée en quelque modules, mais c'est loin de la diversité de libs qu'il te faut si tu fait du gtk, du gnome, ou du kde)
Quelques bugs ?
Peut être, mais c'est comme partout, et puis si il y a des bug, il faut les rapporter et ils seront sans doute corrigé.
graphiquement c'est pas super bien adapté ?
S'il y a peut être quelque petite détails qui diffèrent avec les appli gtk+, dans l'ensemble, je ne pense pas qu'on puisse dire que c'est pas adapté.
Là encore, pas confondre applications KDE et applications Qt.
# Qt Creator
Posté par Sphax . Évalué à 4.
Il y a environ deux semaines j'ai commencé à développer un petit truc pour mes parents, j'avais choisi Qt mais je développais avec Vim + Konsole.
Finalement j'ai décidé de tester Qt Creator, et je n'utilise que ça maintenant. C'est vraiment un très bon IDE, super simple, la complétion est bien foutue, les erreurs de compilation (la fenêtre nous permet de cliquer sur l'erreur, ce qui ouvre directement le fichier concerné à la bonne ligne), la coloration syntaxique bien faite.
J'ai retrouvé le même feeling de simplicité qu'à l'époque où je bossais sur du Java avec Eclipse, chose que je n'avais pas retrouvé avec Kdevelop quand je l'avais testé.
Bon, le support de CMake c'est pas encore ça, je suis obligé de relancer moi même cmake dans le répertoire "build", sinon QtCreator ne voit pas les nouveaux fichiers ajoutés.
Autre chose qui serait bien, ça serait d'avoir la doc d'une méthode quand on utilise la complétion (j'ai pas l'impression que c'est disponible).
Bref, c'est vraiment du bon.
[^] # Re: Qt Creator
Posté par GeneralZod . Évalué à 2.
Tu as accès à l'aide contextuelle via le raccourci F1 et l'aide s'affiche dans un panneau à droite.
QtCreator est un excellent IDE pour travailler avec Qt, simple et sans fioritures, perso, je travaille avec une version Git régulièrement actualisée (ça me permet d'avoir le support de mercurial entre autre).
FakeVim permet d'avoir un éditeur décent presque entièrement pilotable au clavier, mais un FakeEmacs me ferait bien plaisir.
[^] # Re: Qt Creator
Posté par petit_bibi . Évalué à 9.
Rassures-toi, avec le multitouch ça ne devrait plus trop tarder...
# c++ ??
Posté par lesavigner . Évalué à -10.
Qt46Ada, sinon rien.
# Petite correction
Posté par Albert_ . Évalué à 6.
Nokia a lance pyside pour faire un binding python. Je pense que l'on peut donc dire que Nokia (et donc Qt) prend en charge officiellement python.
http://www.pyside.org/
Il existe aussi le tres bon bindings de riverbank qui rend le developpement d'applis Qt bien pratique.
http://www.riverbankcomputing.co.uk/news
[^] # Re: Petite correction
Posté par Gof (site web personnel) . Évalué à 7.
Rien de supporté officiellement encore donc.
PyQt par contre est supporté par son créateur (mais pas par Nokia) et est parfaitement fonctionnel.
[^] # Re: Petite correction
Posté par Victor STINNER (site web personnel) . Évalué à 4.
PyQt utilise un outil de binding spécifique à Qt, « SIP ». C'est un genre d'extension au C++ qui sert à générer un binding pour l'API C de Python. C'est assez spécial et ça n'est utilisé par aucun autre projet. Ça ne facilite pas les contributions, ni le debug :-/
Je ne sais pas ce que PySide utilise pour écrire le binding.
[^] # Re: Petite correction
Posté par GeneralZod . Évalué à 3.
Un fork de QtScriptGenerator basé sur Boost.Python (d'où l'absence de support de Python 3 contrairement à PyQt), un plugin permet également de générer directement du code utilisant l'API CPython.
http://www.pyside.org/home-binding/binding-generator/
Sur la mailing-list, il avait été évoqué de remplacer Boost.Python par smoke le générateur de bindings de KDE.
[^] # Re: Petite correction
Posté par Albert_ . Évalué à 4.
Je pense que cela serait une bonne idee. Boost.Python c'est vraiment pas la joie a utiliser et comme 90% des trucs boost que j'ai tente d'utilisre "Oh mon dieu la doc"... Non franchement c'est une horreur la doc de boost. Il y a un enorme effort a faire de ce cote la.
# Bravo aux développeurs Qt
Posté par pushmepullme . Évalué à 2.
Je me trompe, ou bien seront elles complémentaires ? Mon sentiment est que TR1 est une extension mort née..
[^] # Re: Bravo aux développeurs Qt
Posté par alice . Évalué à 3.
[^] # Re: Bravo aux développeurs Qt
Posté par GeneralZod . Évalué à 4.
Qt duplique bon nombre de fonctionnalités de la bibliothèque standard C++ (QString/std::string, Tulip/STL, etc ...) pour diverses raisons notamment historiques. Qt précéde la norme C++98 et il a fallu attendre longtemps avant que la plupart des compilateurs aient un support décent de celle-ci. Sur certaines plateformes embarqués, pas d'exceptions, pas de RTTI, pas de STL !
Je ne comprends pas pourquoi tu dis *future* TR1 ? TR1 est un ensemble de propositions d'extensions de la SL en prévision de C++0x (la plupart étant basées sur Boost) qui dans l'ensemble a été assez rapidement adopté par les vendeurs et Boost fournit même une implémentation multiplateforme.
TR1 n'est pas mort-né, ça a plutôt bien marché (on peut pas en dire autant de TR2) et c'est inclus dans C++0x.
[^] # Re: Bravo aux développeurs Qt
Posté par pushmepullme . Évalué à 2.
je ne peux pas dire, je ne les connais pas. Enfin, cette librairie ira de paire avec la nouvelle norme C++ qui n'est toujours pas là..
Ce sont ces 2 points qui me font employer le mot future.
[^] # Re: Bravo aux développeurs Qt
Posté par GeneralZod . Évalué à 4.
La plupart des développeurs C++ ont bien accueilli TR1 et certains s'en servent quotidiennement.
> Enfin, cette librairie ira de paire avec la nouvelle norme C++ qui n'est toujours pas là..
TR1 est avant tout une extension de C++03 qui pour la plupart ne nécessite aucun changement au niveau du compilateur. L'espace de nom std::tr1 ne disparaitra pas avec l'arrivée de C++0x (même si le contenu sera également disponible dans std)
[^] # Re: Bravo aux développeurs Qt
Posté par pushmepullme . Évalué à 1.
[^] # Re: Bravo aux développeurs Qt
Posté par fearan . Évalué à 4.
il manque 2/3 trucs dans std::string (heureusement boost est la)
( sprintf, split, number, trimmed, simplified, section...)
Y a aussi la QStringList avec ses filtre en expression rationnelles, permettant de retourner la liste des QString correspondant :D.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Catégorie.
Posté par Gof (site web personnel) . Évalué à 10.
KDE et Qt sont deux projets différents. Même si l'un utilise l'autre, Qt ne se limite pas du tout à KDE
Je m'explique :
Qt se veux multiplatforme. Une application écrite avec Qt fonctionne et s'intègre dans n'importe quel environement ; KDE, Gnome, Windows, Mac, Maemo, WindowsCE, Symbian, ....
Par contre, KDE est un environement homogène d'applications qui défini ses propre règles d'interface. Une application KDE, même si elle fonctionnera sous windows, mac, ou gnome, ne s'y intégrera pas vraiment, car ce n'est pas l'objectif de KDE (même si cela change un peu). Une application KDE utilisera des bibliothèques qui chargeront des démons KDE et aura un look&feel KDE.
KDE utilise Qt pour ses autres qualités (Bonne API, facilité de programmation, documentation, ...). Mais les projets sont complétement différents et ne doivent pas être confondus.
À lire certain commentaires, j'ai l'impression que certains confondent, je devais préciser.
[^] # Re: Catégorie.
Posté par Alexis Ménard (site web personnel) . Évalué à 1.
# Fichtre !
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
A quand un QtKernel pour booter directement en Qt ? :-)
Blague à part, il me parait intéressant d'avoir un ensemble cohérent de bibliothèques qui adresses des problématiques aussi variées que le réseau, XML, les IHM... Mais ces différentes bibliothèques sont-elles réellement utilisables indépendamment les unes des autres ?
Par exemple, mon travail quasi quotidien consiste à développer des systèmes distribués avec des serveurs et des IHM. Donc, dans les serveurs, point d'IHM :-)
[^] # Re: Fichtre !
Posté par Melkor73 . Évalué à 7.
Le seul module obligatoire (et automatiquement "activé") pour coder une appli Qt est QtCore. Pour utiliser d'autres modules, il faut les déclarer dans le fichier de configuration du projet (*.pro).
C'est propre et bien géré de ce côté. ;-)
[^] # Re: Fichtre !
Posté par nomorepost . Évalué à 6.
A quand un QtKernel pour booter directement en Qt ? :-)
Et pourquoi pas un gestionnaire de paquets tant que tu y es ?
....
http://linuxfr.org/~steckdenis/29087.html
# Maemo
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Maemo
Posté par GeneralZod . Évalué à 2.
http://qt.nokia.com/developer/qt-for-maemo-developers
Mais le support de Maemo 5 dans Qt ne sera finalisé que courant 2010, Maemo 6 (prévu en 2011) lui sera basé sur Qt.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.