Cette version du compilateur du projet GNU, initié par Richard Stallman, est particulièrement importante et a été testée depuis des mois de façon intensive par les distributions car elle sera le compilateur utilisé par Fedora 9, par OpenSuse 11.0 et par Debian Lenny - ce message détaillé donne une bonne idée du travail ayant lieu actuellement chez Debian pour pouvoir utiliser GCC 4.3 dans la future version stable de la distribution.
Ci-dessous, les nouveautés concernant GCC, gfortran, gcj et les optimisations mises en oeuvre.
![[en]](../images/en.png)
GCC (418 hits)-
Les nouveautés de GCC 4.3 (1551 hits)
-
Portage du code vers GCC 4.3 (507 hits)
-
La bibliothèque arithmétique GMPLib (319 hits)
-
La bibliothèque de calcul de précision MPFR (341 hits)
> Lire la dépêche (137 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #913087.
gcc lave plus blanc ?
Je vois toujours des références à du « code propre » et j'avoue que ça m'agace un peu.
On vante les mérites de gcc qui respecte au poil les standards C et C++ et qui refuse donc de compiler du « code sale ».
J'avoue que la terminologie a le don de m'énerver. Non pas que je sois un fan du code pas propre, mais pour moi, code propre et respect des standards du C++ et de C sont deux choses distinctes.
Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.
Dans cette catégorisation, il est à noter que le code de gcc est sale, tout comme le code de Linux (et la news le rappelle à juste titre).
Pour certains on a l'impression que le respect absolu des standards du C++ est un but en soi, le développement d'un logiciel n'étant qu'accessoire. Et bien non, le but c'est développer un logiciel, et le respect de certains standards, ce n'est qu'un moyen pour assurer dans certains cas une portabilité. Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
Et un développeur peut avoir des trucs plus intéressants à faire (ajouter une fonctionnalité demandée par des utilisateurs, corriger un bug important) que modifier son logiciel pour qu'il compile avec la dernière version de gcc.
Bref, le respect du standard, mais il faut aussi se mettre au niveau des besoins pratiques des gens, et le respect strict à 100% du standard n'est peut-être pas le besoin le plus criant.
phil.freehackers.org
[^]Re: gcc lave plus blanc ?
Je ne sais pas pour le C++ (je n'en fais pas) mais pour le C respecter la norme est quand même source de portabilité et évite d'avoir à modifier son code quand on change de compilo. Donc oui avoir des compilo qui respectent la norme à 100% c'est important. Il me semble plus sain de compter sur du code propre pour perdurer que sur des failles du compilateur qui au fil des versions peuvent disparaître ou ne pas exister si tu changes de compilateur.
[^]Re: gcc lave plus blanc ?
>mais pour le C respecter la norme est quand même source de portabilité
Mouai, le C99 a mis beaucoup de temps à être adopté par les compilateurs..
[^]Re: gcc lave plus blanc ?
Effectivement avec du C ou C++ 100% standard tu ne ferais pas grand chose.
Le fait d'utiliser des extensions ou librairies tierces en connaissance de cause ne
remet pas en cause le 100% C++ standard, son but étant, ama, de garantir que
la construction syntaxique que j'utilise marchera sur tous les compilateurs et
plateformes sur lesquels je souhaites porter mom code. Le C ou le C++ c'est X
sociétés qui l'implémente il est donc bon que tout le monde se base sur une
base commune qu'on appel le standard.
Les critiques des développeurs des divers noyaux (qui au passage ne sont pas des
développeurs 'normaux') sont plutôt sur le fait que le compilateur ne propose
pas d'options permettant des contournements. Activer une option pour avoir un
comportement particulier en connaissance de cause c'est OK.
Personnellement je vois aujourd'hui du code C fait par des développeurs qui
ne connaissaient du langage que le nom : résultat pour du code développé sur les
5 dernières années sur Solaris 2.8 est un gcc 2.x on ne pourra jamais faire
évoluer le compilateur, si on doit passer sous Solaris 10 il faut impérativement
que notre version de gcc fonctionne dessus, sinon on perd tout nos développement.
Pour moi, vu ce que je viens de voir ces deux dernières années il est impératif que par défaut ce soit le standard courant qui compile ça limitera la casse (en tout cas je l'espère).
[^]Re: gcc lave plus blanc ?
En même temps, quand tu vois la taille du bousin, faut pas s'étonner que personne n'implémente...
Vous êtes prêt à avaler la définition du standard du C++ ? Ses 1205 pages ? Le pdf de 8 Mo, quasiment sans images ?
C'est ici : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n246(...)
Aller je suis gentil, il n'y a *que* les 400 premières pages qui servent à définir le langage.
Le C++ est pire que l'administration française, c'est une accumulation de couche les unes sur les autres. A ce stade, ça devient de la sédimentation !
Alors, à la décharge des divers implémenteurs, je les comprends, je compatie à leur douleur, même.
Bon après tout, si de gens aiment des langages pas beau, mal conçu, avec des concepts certes très intéressant, mais qui constitue une véritable usine à gaz qui rend le code impossible à débugguer... Grand bien leur fasse.
Pour ma part, et moinssez moi, faites vous plaisir, je pense qu'il faut que ce langage disparaisse, et vite.
[^]Re: gcc lave plus blanc ?
Ce qui est bizarre c'est que tout le monde crache sur C++ et qu'en même temps tout le monde complimente Qt.
Je ne sais pas ce qui explique cette universalité de la critique dans un cas et de la louange dans l'autre. Pourtant avec un langage horrible et méprisable il semble difficile de faire un toolkit magnifique et élégant non ?
Ou alors c'est juste que les gens répètent ce qu'ils entendent dire sans juger par eux-même ? Mais ça n'expliquerait pas cette unanimité impressionnante. Il faut donc admettre qu'on peut faire un beau toolkit avec un langage tout pourri comme le C++.
Bizarre.
[^]Re: gcc lave plus blanc ?
Je ne suis pas vraiment d'accord avec toi, le C++ n'est pas pourri il est complexe certes mais permet beaucoup pour ceux qui savent le maitriser pour preuve comme tu le sites QT.
Dans le C++ il y a plusieurs niveaux de programmeurs (beaucoup plus de niveau que dans d'autre langage)
Personnellement j'utilise le C++ en tant que langage final (je développe une application final) je suis un développeur de fin de chaine, et j'aime bien pouvoir dans certain cas pouvoir profiter des multiples paradigmes que le C++ propose tout en étant capable de savoir que mon code marchera dans le futur (QT est proprio mais sa licence et la masse de développeurs KDE me rassure).
Le C++ n'est pas simple (le C non plus quand on veut garantir son fonctionnement ailleurs) mais il est expressif et possède de nombreux contributeurs comme TT qui permettent d'aborder des domaines comme le GUI de façon simple est efficace.
Certes si on veut pouvoir faire pas grand chose sans se compliquer la vie et se la jouer rebel il existe un langage visuel basé sur des instructions symboliques à destination des débutants plus connu sous le nom d'un acronyme barbare qui m'échappe, mais qui n'a rien à voir avec de la programmation pérenne et efficace.
[^]Re: gcc lave plus blanc ?
QT est proprio mais sa licence et la masse de développeurs KDE me rassure
Tu parles de la licence pour faire du logiciel propriétaire avec Qt ? Parce que sinon Qt c'est du GPL tout ce qu'il y a de plus classique. Par contre si un jour pour une raison ou une autre Qt n'est plus développé il passera sous licence BSD.
[^]Re: gcc lave plus blanc ?
Par contre si un jour pour une raison ou une autre Qt n'est plus développé il passera sous licence BSD.
On s'en fou presque, aux dernières nouvelles la GPL est libre aussi ;-)
[^]Re: gcc lave plus blanc ?
Ce qui est bizarre c'est que tout le monde crache sur C++ et qu'en même temps tout le monde complimente Qt.
Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.
En effet, Qt n'est pas écrit en C++ mais en C++/MOC, afin d'y rajouter des fonctionnalités qui se font très bien de manière native, de manière plus élégante et surtout de manière type-safe.
De plus, Qt a ses propres conteneurs etc. et donc dédouble une partie importante de choses mieux réalisées par d'autres bibliothèques, en partie la bibliothèque standard.
Et pour finir, utilisation intensive de pointeurs etc., contraire aux idiomes standards de la programmation en C++.
[^]Re: gcc lave plus blanc ?
TROLL DETECTED!
Qt est écrit en pure C++ !
Le MOC est un générateur de code qui génère automatiquement, dans un fichier cpp séparé, du code qu'il aurait été rébarbatif à d'écrire sois même.
:-D !!!NOUVEAU!!!
[^]Re: gcc lave plus blanc ?
Oui, donc Qt est écrit dans un langage qui n'est pas du C++ puisqu'il doit être précompilé par le préprocesseur MOC pour étendre certaines macro ... Sinon, un compilateur C++ n'est pas capable de compiler un fichier source Qt.
Qt a fait ce choix lorsque les différents compilateurs n'offraient pas un support complet du langage et ne l'a pas revu depuis. Les signals/slots peuvent par exemple être implémentés dans le langage (Cf implementation boost http://www.boost.org/doc/html/signals.html ) Il faut cependant bien dire que la syntaxe est peut être moins agréable avec cette implémentation.
[^]Re: gcc lave plus blanc ?
Qt, et le code écrit avec Qt, est écrit en C++ pure. toute les macro sont des macro C++, étendue par le préproceseur de GCC.
le MOC ne modifie pas le code écrit par le développeur il n'étend pas de macro.
Le moc va lire les en-têtes, pour générer un autre fichier c++ qui va permettre l'introspection. En gros, ça consiste à mettre le noms des signaux et des slots sous forme de chaîne de caractères dans une structure statique. Tu pourrais écrire ce code toi même si tu ne veux absolument pas utiliser moc, mais ce serait stupide car le moc fais ce travail pour toi.
Et puis, les générateur de code c'est bien :-)
http://doc.trolltech.com/4.3/templates.html
(ce document explique les raisons pour laquelle Qt utilise moc)
:-D !!!NOUVEAU!!!
[+] [^]Re: gcc lave plus blanc ?
Je peux traduire tout code Python en code C.
Donc, d'après ton raisonnement, si j'écris du Python, j'écris en fait du C ?
Quant a ton document, il ne donne aucun réel argument.
À noter que le système d'introspection et de propriété n'amène rien du tout, si ce n'est un système particulièrement inélégant de typage dynamique.
[^]Re: gcc lave plus blanc ?
> À noter que le système d'introspection et de propriété n'amène rien du tout, si ce n'est un système particulièrement inélégant de typage dynamique.
Voilà toute la différence entre une personne qui développe activement en comprenant parfaitement les fondements nécessaires à ce qu'elle fait et une personne qui recherche "l'élégance" a tout pris, notion au combien subjective et donc quête purement utopiste (personnellement, je trouve Qt et MOC très élégant, comme je trouve ruby très élégant pour d'autres raisons, d'autres diront autre chose).
[^]Re: gcc lave plus blanc ?
Si tu code avec Qt, le code que tu écris, c'est du C++. Il n'est pas modifié. Il est parfaitement compris, tel quel, par le compilateur C++, car il respecte rigoureusement la syntaxe C++, c'est du C++.
Montre moi un exemple de code écrit en utilisent Qt qui n'est pas du C++ pure.
Pour ce qui est du document, il donne des arguments. Notemment le fait que la syntaxe eut été plus lourde et moins agréable sans.
Et l'introspection, c'est utile pour le debug par exemple. Ou encore pour rendre son application scriptable.
:-D !!!NOUVEAU!!!
[^]Re: gcc lave plus blanc ?
On te dit que ton code pour Qt, *avant* d'être passé par le préprocesseur, n'est pas du C++.
class DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent = 0);
signals:
void actionRequested(const QString &name);
};
Je doute qu'un seul compilateur C++ sache te compiler ce code.
[^]Re: gcc lave plus blanc ?
Ben... Gcc, msvc... Ils arrivent le compiler parfaitement.
Parce que quand tu regardes les fichiers include, Q_OBJECT, c'est :
#define Q_OBJECT \
public: \
Q_OBJECT_CHECK \
static const QMetaObject staticMetaObject; \
virtual const QMetaObject *metaObject() const; \
virtual void *qt_metacast(const char *); \
QT_TR_FUNCTIONS \
virtual int qt_metacall(QMetaObject::Call, int, void **); \
private:
[^]Re: gcc lave plus blanc ?
Ca c'est pour "Q_OBJECT". Et pour "signals:", il se passe quoi ?
[^]Re: gcc lave plus blanc ?
pareil: une macro défini dans un fichier include (qobjdefs.h [1])
Et pour info, du code en glib utilise aussi pas mal de macro de ce genre, et ça reste du C. exemple eu hasard: ([2])G_DEFINE_TYPE(GeditPanel, gedit_panel, GTK_TYPE_VBOX) static void gedit_panel_finalize (GObject *obj) { if (G_OBJECT_CLASS (gedit_panel_parent_class)->finalize) (*G_OBJECT_CLASS (gedit_panel_parent_class)->finalize) (obj); }:-D !!!NOUVEAU!!!
[^]Re: gcc lave plus blanc ?
J'ai du mal a voir l'utilite de la macro signals, a part pourrir du code qui n'a pas ete prevu au depart pour Qt et qui aurrait eu l'idee d'utiliser "signals" comme non de variable par exemple.
En ce qui concerne glib, je sais, il y a des macros partout, mais est-ce qu'il y a besoin d'un preprocesseur externe comme moc ?
[^]Re: gcc lave plus blanc ?
La macro signal est interpretée par le moc qui va savoir que la fonction est un signal. le moc va alors la générer le corps de ce signal automatiquement pour toi. si on prends ton exemple, moc va générer ce code dans un fichier annexe:
void DisplayWidget::actionRequested(const QString & _t1) { void *_a[] = { 0, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) }; QMetaObject::activate(this, &staticMetaObject, 0, _a); }Le développeur de gedit a lui du perdre un peu de temps à écrire le code de son signal manuellement. Tu va trouver que la syntaxe de ce code auto-généré est laide mais c'est pas grave vu que c'est du code auto-généré, seul le compilateur est sensé le lire:-D !!!NOUVEAU!!!
[^]Re: gcc lave plus blanc ?
Bon, si j'ai bien compris:
- Le code source avant le passage de moc peut etre compilé directement, parce qu'il n'y a que des macros qui sont definies par des headers Qt (donc, c'est bien du C++).
- Le pre-processeur moc ne sert qu'a generer le corps de certaines fonctions membres, dans un fichier intermediaire (et c'est toujours du C++).
- On pourrait ecrire les fonctions generees a la main (en C++), mais c'est fastidieux, d'ou l'usage de moc.
Si ca ressemble vraiment a ca, je ne voit pas comment on peut affirmer que "Qt/moc c'est pas du C++". Bon, il y a toujours la macro "signal" qui choque un peu, mais franchement, on doit pouvoir trouver pire.
Merci pour les explications.
[^]Re: gcc lave plus blanc ?
Si ca ressemble vraiment a ca, je ne voit pas comment on peut affirmer que "Qt/moc c'est pas du C++". Bon, il y a toujours la macro "signal" qui choque un peu, mais franchement, on doit pouvoir trouver pire.
Et c'est ce que Gof défend depuis plusieurs jours.
Pour ma part, le principal problème que j'ai avec ce système, c'est que ça peut coincer au niveau des outils pour générer des diagrammes UML... (ben oui, ils gèrent pas les macros)
[^]Re: gcc lave plus blanc ?
Cette "pureté" (je n'aime pas le terme non plus), c'est ce qui apporte la portabilité du développeur.
A avoir des macros, même simplificatrices, qui s'utilisent en place des artifices officiellement fournis par le langage, on s'engage dans un sous-dialecte qui n'aide pas à la migration des développeurs.
C'est comme cela que l'on se retrouve à avoir du C++/MOC, du C++/MFC, etc
Résultat, on se retrouve avec des gens qui doivent ouvrir une nouvelle doc (propriétaire! (à un framework)) pour utiliser des structures qui sont pourtant fournies en standard, lorsqu'ils migrent sur des projets qui reposent sur d'autres frameworks (wxWidgets, Qt, MFC, ACE, ...)
Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard (je pense aux itérateurs aliens (dans le contexte C++) de Qt, à leur FOREACH, etc, et de même pour les autres frameworks qui empiètent sur la SL, ou qui poussent à l'utilisation de macros dans le code client)
Après, et cela n'engage que moi, je ne crois pas en la pérennité des sous-dialectes -- même si certains font de la résistance (-> MFC). Si TT/Nokia poussait certains des éléments de Qt dans le prochain standard, ma foi cela pourrait assurer une pérennité. Mais, AFAIK, ce n'est pas le cas. Ils m'ont l'air de rester gentiment dans leur coin avec leurs clients. A côté de ça Adobe, dont ce n'est pourtant pas le métier de fournir un framework de fenétrage, publie des articles "théoriques", et s'investit dans les communautés motrices relativement à l'avenir du C++ (au travers de 3-4 individus).
[^]Re: gcc lave plus blanc ?
Quel est l'équivalent standard du foreach de Qt ? Le fait est qu'il n'y en a pas, et que si Qt l'a introduit c'est bien parce que ce genre de truc est diablement pratique
[^]Re: gcc lave plus blanc ?
hum ... std::for_each() ?
[^]Re: gcc lave plus blanc ?
pose toi la question pourquoi personne ne veut utiliser ce truc: ce que propose Qt est pratique. std::for_each ne sert à rien, et considerer ça comme un equivalent du foreach de qt je trouve que c'est un peu pousser grand-mêre dans les orties.
Le foreach de qt est optimal dans le sens ou il minimise la redondance de ce que tu as a taper.
[^]Re: gcc lave plus blanc ?
Personnellement je trouve la combinaison de std::for_each et boost::lambda autrement plus élégante (et puissante) que le foreach de Qt.
Cela permet par exemple d'écrire
vector v(10);
for_each(v.begin(), v.end(), _1 = 1);
Ou encore
for_each(v.begin(), v.end(), cout << *_1 << '\n');Etienne
[^]Re: gcc lave plus blanc ?
On rentre dans les boosteries, c'est déjà une bibliothèque supplémentaire à utiliser. On peut aussi pinailler sur le fait que nommer l'element courant "_1" soit vraiment elegant. Ou bien que c'est plus joli d'imbriquer des foreach "à la Qt" que d'imbriquer deux std::for_each l'un dans l'autre.
[^]Re: gcc lave plus blanc ?
Tout à fait. C'est de nouveau un sous dialecte ; avec les problèmes de portabilité de développeurs que j'évoquais précédemment.
Au détail que boost a légèrement noyauté le prochain standard et que l'ensemble de ses définitions complètent généralement la SL plutôt que de chercher à s'y substituer.
[^]Re: gcc lave plus blanc ?
Sauf que tu donnes là un exemple simple. Dès que dans le bloc de ton FOREACH, tu as plus de 4-5 instructions, for_each devient franchement imbitable (obligé de créer une fonction annexe, avec impossiblité d'accéder directement aux variables des blocs supérieurs...)
[^]Re: gcc lave plus blanc ?
Et le jour où ton employeur t'affecte à un projet C++/MFC ou C++/gtkmm ?
Mon point n'était pas lié à la simplicité apportée (cf ma seconde phrase deux messages plus hauts) , mais à la non portabilité des développeurs introduites par ces dialectes propriétaires. Soit une vaine (?) tentative de décrypter ce qui est entendu par "pur".
La practicité du foreach de Qt est un fait. Il y a des gens qui se sont amusés à inventer le même genre de trucs avec boost. Leur pérennité est juste faible vu qu'il va y avoir autre chose pour remplacer: http://en.wikipedia.org/wiki/C%2B%2B0x#Range-Based_For_Loop
C'est le problème des extension propriétaires. Si elle les restent, le standard fini par gagner -- quand il y a redondance.
[^]Re: gcc lave plus blanc ?
On est d'accord.
Je n'avais pas entendu parler de ce que tu cites sur le "range-based for loops" mais si c'est vraiment inclu dans c0x c'est super.
Au moins le foreach de Qt aura eu le mérite de mettre en évidence qu'il y avait une vrai demande pour ce genre de construction. Ce qui n'etait pas évident au départ; a chaque fois que j'ai vu ce sujet abordé tous les c++-gurus se braquent sur le mode "la stl est parfaite tu pas besoin d'autre chose"
[^]Re: gcc lave plus blanc ?
Quel est l'équivalent standard du foreach de Qt ? Le fait est qu'il n'y en a pas, et que si Qt l'a introduit c'est bien parce que ce genre de truc est diablement pratique
Si je me rapport à http://doc.trolltech.com/4.1/containers.html#the-foreach-key(...) ça a vraiment l'air de vouloir éviter de faire peur aux allergiques des iterateurs (ce que certains commentaires ici même tendraient à justifier). Parceque
QMap<QString, int> map;
[...]
foreach (QString str, map.keys())
qDebug() << str << ":" << map.value(str);
S'écrit en C++
QMap<QString, int> map;
[...]
for (QMap<QString, int>::iterator it=map.begin(); it != map.end(); ++it)
qDebug() << it->first << ":" << it->second;
Et on a l'avantage d'éviter la copie de QString et l'appel à map.value() qui fait une recherche dans la map (QMap pouvant être remplacé par std::map avec exactement la même utilisation).
[^]Re: gcc lave plus blanc ?
Comme je le dis plus haut, c'est totalement sous optimal, tu es obligé de rappeler le type de ton conteneur pour indiquer le type des iterateurs (et des fois ça peut etre vraiment long, source d'erreur), et d'appeler explicitement begin et end.
[^]Re: gcc lave plus blanc ?
Comme je le dis plus haut, c'est totalement sous optimal, tu es obligé de rappeler le type de ton conteneur pour indiquer le type des iterateurs
Je pense que tu n'utilises pas assez de typedef, je le fait de façon systématique pour rendre le code plus lisible et les évolutions plus aisées. Mon seul regret est que, comme en C, cela ne déclare pas un nouveau type mais ne fait qu'un alias.
(et des fois ça peut etre vraiment long, source d'erreur),
Erreur qui est détectée à la compilation.
et d'appeler explicitement begin et end.
C'est l'idiome qui veut cela et c'est quand même l'idiome le plus standard du C++, c'est quand même la leçon numéro 0 quand on aborde les conteneurs, tu remarquera que les développeurs de Qt ont trouvé le concept suffisamment bien foutu pour l'utiliser dans leurs conteneurs.
[^]Re: gcc lave plus blanc ?
C'est l'idiome qui veut cela et c'est quand même l'idiome le plus standard du C++
Oui et 99% du temps on travaille sur le conteneur entier au lieu de ne travailler que sur une partie. D'ou l'interet d'un foreach qui ne te redemande pas systematique de preciser les bornes. Ou bien d'avoir un concept de "paires d'iterateur", enfin n'importe quoi qui permette de réduire le nombre de caractères tapés et surtout le risque d'erreur ( genre si le begin et le end sont pris sur deux conteneurs differents).
[^]Re: gcc lave plus blanc ?
Les macros font partie officiellement du standard C/C++
Alors oui, quand on utilise un bibliothèque, il faut utiliser la doc de la bibliothèque, ses structures de données, et son style d'API. Mais c'est innévitable.
Que suggères tu ? Que l'on utilise plus de bibliothèque autre que la stdlib et la libc ?
On ne devrais utiliser ni Qt, ni Gtk, ni GLib, ni boost, ni ... ? et refaire tout dans chaque applications ?
:-D !!!NOUVEAU!!!
[^]Re: gcc lave plus blanc ?
Que suggères tu ? Que l'on utilise plus de bibliothèque autre que la stdlib et la libc ?
Et je cite le message de Luc auquel tu réponds :
Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard
De mon côté je suggère que tu apprenne à lire les messages auxquels tu réponds.
[^]Re: gcc lave plus blanc ?
Mouai. Le standard du C++ propose à la fois une syntaxe et une bibliothèque. Ok pour se conformer au langage (bien que quand une spec fait 1200 pages, on peut se poser la question de la logique qui préside à ce langage).
La bibliothèque standard du C++ demande un apprentissage au même titre que Qt, Gtkmm, MFC ou autre chose.
La std::lib étant plutôt pourrie et malpratique à utiliser, je ne vois pas pourquoi il faudrait préférer la std::lib par rapport à un truc pratique et rapide à utiliser. Parce que Bjarn Soustroup a réussi à le faire passer dans l'ISO ?
phil.freehackers.org
[^]Re: gcc lave plus blanc ?
Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.
Qu'est ce que le c++ moderne au juste ? un espece de machin "tout templates" hyper lourd avec des messages d'erreurs inintelligibles qui se déplient sur 500 lignes, un langage qui demande 2 go de ram et 10 minutes pour compiler un programme de deux lignes tellement on abuse des templates et on les pousse dans leurs limites ? C'est vraiment devenu un sport de faire les construction les plus tordues et de triturer le langage dans tous les sens, et je ne suis pas sûr qu'à la fin la lisibilité, la maintenabilité, et même la performance soient au rendez-vous.
[^]Re: gcc lave plus blanc ?
Moi je voit Qt comme Java ou .Net, une plateforme, un langage + une librarie très complète et *uniforme* ! Et le langage en question c'est pas le C++, c'est le C++/MOC.
Les deux seuls reproches que je ferai c'est de ne pas implementer les signaux/slots en C++ pur et l'absence totale d'exceptions.
Et qu'est ce qui te permet d'affirmer que les conteneurs Qt sont moins bons que la STL ? Qt utilise massivement le copy on write (http://doc.trolltech.com/4.3/shared.html#implicitly-shared), je ne crois pas que la STL le fasse, pourtant c'est une fonctionnalité non négligeable. De plus pour avoir utilisé les deux, je trouve les conteneurs Qt bien plus utilisables que ceux de la STL, c'est moins générique d'accord, mais c'est plus pratique (sort est une methode, pas une fonction externe, QList).
Je ne compare même pas QString à std::string, ça n'en vaut pas la peine.
[^]Re: gcc lave plus blanc ?
> Qt utilise massivement le copy on write
Le COW n'est pas un gage de qualité pour tout le monde. Le seul intérêt que je lui vois, c'est de palier à l'absence de sémantique de déplacement dans la version courante du C++ (le C++0x introduira les rvalue references qui changeront la donne -- compter 15 ans avant que Qt en profite (volonté de supporter toutes les plateformes, même celles qui ne sont plus supportées par les fournisseurs de compilos)). Et juste pour cela : faire des retours de fonctions par valeur, on sort une usine à gaz, à savoir le COW.
> sort est une methode, pas une fonction externe
Et oui, sort s'applique aussi sur les tableaux, pas que sur les vecteurs ou les files. Pourquoi dupliquer le code ?
Une école tend à considérer que les fonctions ne doivent être membre qu'en dernier recourt -- je simplifie.
Visiblement, Stepanov aurait mis bien moins de choses en membre comme begin()/end() s'il avait pu faire ce qu'il voulait.
Cf ses notes sur la programmation: http://www.stepanovpapers.com/notes.pdf
> std::string
souffre en effet d'un certain nombre de défauts.
[^]Re: gcc lave plus blanc ?
Donc on va avoir 3 moyens de désigner un objet en C++:
Une référence
Un pointeur
Une rvalue reference
Et après on s'étonne que tant de gens trouvent le C++ trop complexe...
Je code en C++/Qt tous les jours, et ça me plait mais il y a quand même des trucs que je trouve inutilement complexe.
Si on prend Java, le langage est très simple, trop diront certains. Mais cette simplicité permet d'avoir des outils de manipulation automatique du code très efficaces (eclipse & co). Et au final on code plus vite en java qu'en c++. Exemple, j'ai jamais vu de completion automatique marcher à 100% sur du C++ pourtant c'est un outil qui permet vraiment de gagner du temps surtout si la doc est intégrée comme dans eclipse.
[^]Re: gcc lave plus blanc ?
4. Ne pas oublier les simples valeurs.
Je n'ai jamais dit que le langage était simple.
Quant à la complétion automatique, les polymorphismes moins dynamiques (macrotage hérité du C, template, ...) n'aident effectivement pas. Dans leurs blogs, des gens de l'équipe de VS parlent qu'ils sont en train de remettre les choses à plat. Il faudra voir ce que cela pourra bien donner. Je serais curieux aussi de tester (dans 2 ans ...) cet autre outil dont on nous a fait de la pub ces dernières semaines (histoire de remplacer ctags qui ne comprend vraiment pas grand chose au C++)
[^]Re: gcc lave plus blanc ?
Je plussoie allègrement.
Les fans du C++ crachent sur Qt parce que ce n'est pas du C++ pur. [je pense au passage que la notion de pureté du langage est tout aussi débile que la propreté du code que gcc aime bien]
Je pense que ce qui fait que Qt a autant de succès malgré le fait que Qt soit écrit en C++, c'est justement que Qt simplifie énormément l'utilisation du C++, et la rend à peu près aussi simple que du python ou du java (plus simple même à mon avis pour le cas de java).
Quelques exemples en vrac :
- trouver de la doc facile à comprendre sur le C++ et ses classes outils, c'est la galère. A l'inverse, la doc de Qt est excellente.
- les conteneurs Qt sont bien foutus et bien documentés, à l'inverse du C++ qui a une approche plus mathématiquement complet mais peu intuitif. Par exemple, pour transformer une chaine de caractère en minuscule et la casser en liste de chaines, en Qt, tu fais un s.toLower().split(' ') alors que le même code en C++ classique demande la compréhension de la notion d'itérateur, de mélange entre fonctions C (tolower) et C++ (les itérateurs). La notion de string en C++ n'existe pas vraiment. Une string n'est qu'un cas particulier d'un tableau de caractère, un tableau n'étant lui-même que le cas particulier d'un conteneur qu'on peut parcourir en avant, en arrière et qu'on peux accéder par index. Tu dois donc faire un parcours de ta chaîne avec un itérateur en lui appliquant un algorithme (tolower) pour obtenir ton résultat. Ca m'a pris 2h de lecture de doc la première fois pour réussir à faire ça.
- pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.
Globalement, quand je programme en C++/Qt, je pense que j'utilise environ 10% du standard C++ et je fais plein de trucs intéressants. A l'inverse, quand je fais du C++ pur, je galère pour faire ce que je veux parce que je dois utiliser plus de C++ (disons 20 à 30%) et je peine à faire des trucs intéressants.
Dans une de mes vieilles interviews, Eirik Eng le PDG de Trolltech disait que un binding python pour Qt a peu de sens pour Trolltech, parce que Qt apporte au C++ beaucoup de services conviviaux pour les programmeurs, qui sont déjà présents à la base en python. Le besoin de Qt pour le python est donc moindre, et se limite uniquement à la partie graphique. [1]
Voilà, je pense que ca répond à la question initiale.
[1] ca n'emêche pas le binding d'être maintenu avec une très bonne qualité, mais à l'écart de Trolltech. Pour java, Trolltech en revanche héberge directement un binding java.
phil.freehackers.org
[^]Re: gcc lave plus blanc ?
- pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.
Je remarque que Qt :
- fournit des containers dont l'interface est plus que largement inspirée de la STL [http://doc.trolltech.com/4.0/qmap.html]
- utilise de plus en plus de templates
- utilise largement les templates en interne pour te fournir l'interface qui te convient (cf par exemple qalgorithms.h)
J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?
Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt", que beaucoup (dont mois) considèrent comme une très bonne bibliothèque. En revanche, je crois que les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.
[^]Re: gcc lave plus blanc ?
> - fournit des containers dont l'interface est plus que largement inspirée de la STL
Depuis Qt 3, tous les conteneurs Qt sont à la fois accessible avec les méthodes Qt (que je trouve mieux nommé pour ma part : first(), last(), append() ) et sont devenus compatibles avec la STL, en fournissant notamment les front(), back(), etc. La version 2 de Qt n'était pas compatible avec les algo STL du tout et était beaucoup critiquée pour cela.
Je ne suis pas d'accord pour dire que les conteneurs sont inspirés par la STL. Ils sont inspirés par les besoins des développeurs, d'où par exemple la présence d'une QString qui est autre chose qu'un vector et la présence d'une QStringList qui est autre chose qu'un vector< vector< tchar > > . Map, Hash, List, Array sont des besoins génériques des programmeurs qui n'ont été inventés ni par Qt ni par la STL.
Je ne suis donc pas d'accord avec ton affirmation même si aujourd'hui ca ne fait plus beaucoup de différence. L'approche de Trolltech a été de comprendre les besoins et de fournir une lib qui y répondait.
Les dernières versions de Qt sont de plus en plus souples, avec par exemple la possiblité de désactiver les macros signal et slots, et autres subtilités qui peuvent poser des problèmes de compabilité avec la STL (notamment avec boost::signal).
Je n'ai pas dit que Qt n'utilisait pas de template. La grosse différence entre Qt et la stdlib, c'est que les template sont très très peu visibles dans Qt. Dans 90% des cas, Qt fournit déjà des services pratiques. par exemple, tu peux itérer sur une QStringList sans template et sans pénalité en passant pourtant par des indexes.
Dans la std::lib, les template sont partout dans tous les sens. Pour faire une opération super simple, il faut se taper des template (j'ai donné un exemple plus haut).
> Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt"
Disons que Qt a été très critiqué pour ne pas avoir de conteneurs compatibles STL (ce n'est plus le cas aujourd'hui), utiliser un générateur de code séparé plutôt que d'être purement C++, pour avoir sa propre notion de typage plutôt que d'utiliser les RTTI, etc.
Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.
Il n'en reste pas moins qu'on lit tous les mois des critiques de Qt parce que ce n'est pas du C++ pur.
Un truc que j'ai apprécié, c'est qu'en connaissant 10% du standard C++ et en ne connaissant rien en template, j'ai pu coder sans problème en Qt.
Pour faire des programmes en std::lib, j'ai du au contraire me plonger dans les notions de template, d'itérateurs, etc tout ca pour découvrir que le service tout simple dont j'avais besoin n'existait pas dans la lib (convertir une chaîne de caractère en minuscule). C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien. Alors que en Qt, je n'ai encore jamais eu besoin de faire du C.
> J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?
Dans Qt 2, tu ne pouvais pas choisir ton algo de tri :
http://doc.trolltech.com/2.3/qarray.html
Mais on avait bien un template, j'imagine que c'est ce que tu voulais prouver.
Par contre, le QVector de Qt 3 et 4 peut être trié avec les algos de la STL.
C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.
Perso, dans ma vie de programmeur, j'ai encore jamais eu besoin de la flexibilité offerte par la stl pour le tri. En revanche, il ya plein de petites choses dont j'ai besion très très souvent, qui ne sont pas dans la STL mais qui sont présentes dans Qt.
Un autre truc marrant d'ailleurs, c'est que en interne, QVector convertit tout en char * (void * pour les puristes) et utilise les fonctions de la libc comme un gros bourrin. Pas si fan des template que ca les développeurs de Qt. Je pense qu'ils ont gratté quelques millisecondes de temps d'exécution avec ce type de ruse.
> les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.
Ca j'en suis persuadé. Ils connaissant toute la richesse du C++, toutes les failles des compilateurs qui soi-disant l'implémentent (rappelons par exemple que MSVC 6, un compilo très répandu ne savait pas gérer les variables déclarées à l'intérieur des for), tous les trucs pour gagner du temps, réduire la taille, etc.
Ils arrivent à transformer un langage hyper compliqué et mal documenté en un truc simple et pratique à utiliser. Plus je connais le C++ et la diversité des compilateurs et de leurs problèmes, plus j'ai de respect pour les développeurs de Trolltech.
phil.freehackers.org
[^]Re: gcc lave plus blanc ?
> Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.
Je me demande s'ils n'ont pas également abandonné certains compilos encore plus vieux et exotiques que certains pas vraiment réputés pour leur niveau de conformité.
Clairement l'approche à l'opposé de celle de boost.
> C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien
Ben ... pourquoi tout réinventer ?
Accessoirement, je n'avais pas relevé précédemment, mais il y a une version C++ de tolower qui prend une locale en paramètre (le C++ a une approche que je trouve assez bizarre vis à vis de l'I18n). De fait, il est est faux de dire qu'il _faut_ repartir sur le C (dans ce cas! Dans d'autres, je ne dis pas).
> C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.
C'est un exemple de la séparation organisation/algorithme sauce STL. Je me sers tout autant des copy_if (OK, c'est un oubli du standard), remove_xxx, equal_range, etc.
De nouveau, le PDF de Stepanov est des plus intéressants.
[^]Re: gcc lave plus blanc ?
> Je me demande s'ils n'ont pas également abandonné certains compilos encore plus vieux et exotiques que certains pas vraiment réputés pour leur niveau de conformité.
> Clairement l'approche à l'opposé de celle de boost.
Oups, j'ai foiré la transition ^^'
Je voulais dire: dans ce cas: ils ont dû enfin abandonné certains vieux compilos ; alors leur volonté me parait d'être de supporter tous les compilos encore utilisés en industrie (donc VC6 p.ex)
A l'opposé boost néglige les anciennes versions des compilos.
[^]Re: gcc lave plus blanc ?
> de mélange entre fonctions C (tolower)
Ou de savoir chercher dans une FAQ ...
Mais même là, la réponse n'est pas simple suite à divers choix relatifs à l'interface de std::string, et aux locales.
Sinon, boost c'est pas mal aussi...
Mais c'est sûr, qu'à faire du C++ sans connaitre la SL (-> itérateurs et autres algorithmes), on passe à côté de pas mal de choses et on se complique bien la vie. L'absence de vrais supports pour enseigner ce C++ (plutôt que du C avec des classes) n'aide pas.
[sinon, j'ai globalement la même perception qu'Etienne -- pour la petite histoire, Stroustrup utilise Qt dans son enseignement du langage]
[+] [^]Re: gcc lave plus blanc ?
> Je ne sais pas ce qui explique cette universalité de la critique
Simple, la majorités des gens ne comprend pas C++ et est trop fainéante pour l'apprendre. Au-lieu de reconnaitre sa paresse, ben elle critique (sans savoir tout le géni qu'il y a dans C++).
[^]Re: gcc lave plus blanc ?
d'autres, c'est la grammaire ou l'orthographe.
Windows has no users. It has hostages.
[^]Re: gcc lave plus blanc ?
Euuh, Le langage D propose quasiment tout ce que propose C++, Templates compris, avec une définition plus courte et une syntaxe beaucoup plus propre.
Eiffel.. euh non, mauvais exemple.
Aller, je vais quand même pas passer outre la défense de ma chapelle : Lisaac, permet de faire bien plus de choses qu'en C++, avec une définition beaucoup plus courtes, et même sans nécessiter de templates, le compilateur fait tout tout seul avec l'analyse de flot*, et ce avec sensiblement les mêmes perfs : http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)
Le génie, c'est de tout mettre tout ces concepts avec quelques primitives de base, et de produire un compilateur capable de tout faire, rapidement, avec celle-ci.
* Bientôt poussé à fond, ie. sur les collections statiques
[^]Je suis paresseux
C'est un peu brutal comme remarque. Et aussi bête que de dire: ceux qui ne connaissent pas ADA, ce fabuleux langage, sont des idots. Ou encore: ceux qui n'utilisent pas Ruby, cette merveille, sont vraiment nuls. Etc.
Je suis probablement paresseux d'apprécier la simplicité du c.
Pour mon compte tout à fait personnel, le c++ (le vrai, pas juste l'utilisation de quelques fonctionnalités) ne m'a pas encore apporté de bénéfices.
Je fais des applications légères (2000 lignes maxi) et pour le moment le c m'a toujours donné de bien meilleurs résultats.
D'autres ont des goûts différents, des besoins différents.
Qui a existé en premier: le compilateur ou son code source ?
[^]Re: Je suis paresseux
> Et aussi bête que de dire: ceux qui ne connaissent pas ADA, ce fabuleux langage, sont des idots. Ou encore: ceux qui n'utilisent pas Ruby, cette merveille, sont vraiment nuls. Etc.
Je ne connais pas ADA ni Ruby, je ne les critique pas. Tu vois la nuance ?
[^]Re: Je suis paresseux
On écrit Ada pas ADA.
La Roue du Temps
[^]Re: gcc lave plus blanc ?
>Ce qui est bizarre c'est que tout le monde crache sur C++
Pas tout le monde: juste ceux qui l'ont utilisé ;-)
Mon avis personnel: beurk! Vive Scala ou D si on veut vraiment un langage proche du C++.
>Pourtant avec un langage horrible et méprisable il semble difficile de faire un toolkit magnifique et élégant non ?
Certes, mais difficile != impossible, donc rien de contradictoire ou de bizarre là dedans..
[^]Question d'esprit
A mon très humble avis, la bataille entre C et C++ a les mêmes racines que celle entre emacs et consort. C'est juste une question relative à l'esprit de chacun. Certaines personnes sont mieux avec tel langage car cela correspond mieux à la manière dont leur esprit fonctionne.
Le C++ étant nettement plus abstrait, cela requière des esprits adaptés. Je n'utilise que peu le C++ car il ne me correspond pas, et il ne correspond pas à mes besoins. Par contre je comprend qu'un autre puisse trouver avantage en ce langage et qu'il soit plus à l'aise avec.
D'un côté strictement pratique, les *bons* programmes en C++ sont souvent bien difficiles à pénétrer (je ne parle pas de ceux qui sont mals écrits). Je prend l'exemple de la famille des serveurs vnc: ce n'est qu'un avis personnel mais le code est incompréhensible. Alors que celui de Qt est clair (comparativement à sa taille). Et bien j'ai rencontré plus de programmes comme vnc que comme Qt.
Qui a existé en premier: le compilateur ou son code source ?
[^]Re: gcc lave plus blanc ?
Parce que même si le C++ est mal fichu, mal standardisé et inutilement compliqué, il permet de créer des API qualité?
[^]Re: gcc lave plus blanc ?
Certaines choses sont exprimées à la fois dans le standard C et dans le standard C++.
Et bien C est bien plus court, mais est totalement incompréhensible...
Le fait que le standard C++ soit plus long lui permet d'être clair et précis.
[^]Re: gcc lave plus blanc ?
Je vois pas en quoi le C est incompréhensible. C'est justement le fait qu'il soit court qui lui a apporté le succès. Pour citer le K&R, « Un programmeur peut s'attendre avec raison à connaître, à comprendre et à utiliser effectivement la totalité de ce langage ».
La preuve : le K&R fait 200 pages, définition de la grammaire comprise.
The megafreeze development model is broken. (tuomov, le 03/03/2007)
[^]Re: gcc lave plus blanc ?
Le K&R (dans sa dernière version) est un livre d'exercices pour apprendre le C89.
Ce n'est nullement la norme. La grammaire n'est qu'une toute petite partie de la définition d'un langage, le plus important c'est la sémantique.
La norme C99+TC1+TC2, elle est là (c'est un working draft, bien sûr, parce que la version finale faut l'acheter) : http://open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
Elle ne fait que la moitié de la taille du standard C++0x, mais comme je l'ai dit, si tu compares certains passages tu constateras que là où le standard C est flou et pas clair le standard C++ est explicite.
De plus, bon, il parait évident que C++0x est un peu plus compliqué que C99, car ayant plus de fonctionnalités, donc c'est plus long à définir.
Je rappelle que le lien donné précédemment n'est pas C++98, ni C++03, ni C++03+TR1 mais un working draft qui date un peu de C++0x.
D'ailleurs, pour référence, je fournis ces liens :
Draft de C++98 datant de 97 : http://www.open-std.org/jtc1/sc22/open/n2356/
Corrections effectuées en 2003 : http://www.acceleratedcpp.com/authors/koenig/c++std/revision(...)
Dernier working draft de C++0x : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n252(...)
[^]Re: gcc lave plus blanc ?
Ok, tu parlais de la norme et pas du langage. Comme d'habitude les gens m'ont plussoyé pour rien. Je suis désolé, en plus je te connais de developpez.com et je t'aime bien, personne ne peut lutter contre toi sur la connaissance du C++.
The megafreeze development model is broken. (tuomov, le 03/03/2007)
[^]Re: gcc lave plus blanc ?
Vous êtes prêt à avaler la définition du standard du C++ ? Ses 1205 pages ? Le pdf de 8 Mo, quasiment sans images ?
Tiens c'est marrant, ça me rappelle le langage eiffel. Avant la normalisation par l'ECMA (qu'aucun compilo n 'implémente pour le moment), la définition du standard était le bouquin de B. Meyer. Et ben pour un langage avec moins de fonctionnalités que le C++ et surtout une lib standard bien plus restreinte (ainsi que des concepts que personne n'a jamais su implémenter, genre SCOOP) , on dépassait allègrement les 1200 pages. Le langage n'est pourtant pas mauvais. Comme quoi ...
[^]Re: gcc lave plus blanc ?
C'est du grand n'importe quoi ces commentaires.
C++ est un langage. Tu peux utiliser un langage au niveau maternelle (c'est à dire C), ou au niveau Bac L(C++ / STL) ou au niveau doctorant en linguistique (C++/Boost).
C'est pas parce que tu ne comprends pas un mot du langage que le langage est nul.
C'est un peu comme l'analogie avec le français et l'anglais.
Tous comme le français est d'une richesse importante, l'anglais est encore plus riche.
C'est sûr que pour le français de base (pléonasme ?), "l'anglais c'est nul, on comprend rien", et la majorité le parle à la texane japonaise, il n'empêche que tu peux exprimer des concepts impossible à décrire en français sans faire de périphrase (comme "pas cher").
Seulement, tu peux rester à ton niveau, et comprendre les textes (codes) à ton niveau, ou tu peux décider de continuer à évoluer, et apprendre ce que le quidam de base ignore.
Alors seulement tu comprends que c'est carrément plus pratique de dire "cheap" (5 lettres) au lieu de "pas cher" (8 lettres).
Je suis d'accord avec le fait que le compilateur qui crache un message d'erreur de 500 caractères, c'est comme un anglais qui te réponds en vieux patois irlandais: c'est chiant à comprendre.
C'est là où il y a du boulot à faire au niveau du compilateur (ICC, est pas trop mal pour ses messages d'erreur, et clang est prometteur), mais c'est pas la faute au langage.
Si on compare au Java, par exemple, le langage est basique - simple-, du coup les outils de développement compensent en offrant les fonctionnalités du langage manquante (les templates du C++ <=> refactoring d'Eclipse, etc...).
C'est sûr c'est plus simple à apprendre, mais t'es vite obligé de réécrire du code existant parce que tu veux changer un paramètre d'une classe, etc...
Regarde un peu le projet Juce ( www.rawmaterialsoftware.com/juce ) pour un exemple de codage d'application cross-platform en c++ vraiment clean.
[^]Re: gcc lave plus blanc ?
Avoues quand même que le niveau de compétence exigé pour écrire du bon C++ est bien plus élevé que pour du bon C.
Les templates de C++ lui ont permit de rajouter des fonctionnalités supplémentaires, mais bon le template programming n'est pas un exemple de clarté...
Il y a plein de choses complexes (héritage multiple correct, gestion des recopies, etc...)
[^]C++ : RAII et programmation générique
L'avantage du C++ c'est avant tout le RAII.
Pouvoir redéfinir les sémantiques de copie, d'affection, de construction et de destruction de nouveaux types qu'on définit permet de ne pas avoir à faire de gestion manuelle des ressources (comme la mémoire) en garantissant que tout est libéré même face à des erreurs qui surviennent durant l'exécution (exceptions).
À lui seul, cet idiome empêche 90% des défauts de C d'apparaître (gestion de mémoire manuelle, fuites mémoires, dangling pointers...).
Le deuxième avantage, c'est la programmation générique. On peut programmer des composants réutilisables sans avoir à utiliser du typage ou du dispatch dynamique.
Les langages de la famille ML se vantent de leur polymorphisme paramétrique et de leurs modules, mais les fonctionnalités pour la programmation générique de C++ (les templates) permettent bien plus de choses, et sont plus faciles à comprendre pour un programmeur proche du système (mais peut-être pas pour un fan de lambda-calcul).
Celle-ci peut toutefois parfois être compliquée si on veut réaliser certaines choses car nécessitant d'exploiter un peu de méta-programmation pour vérifier certaines propriétés sur les types. De bons outils, comme ceux de boost, peuvent toutefois fortement aider.
La programmation générique sera grandement simplifiée par l'introduction en C++0x des concepts. Ceux-ci permettent de vérifier simplement certaines propriétés sur des types, d'une façon similaire à l'héritage, mais de manière non-intrusive (sans que le type soit explicitement défini comme sous-typant un certain autre type -- le sous-typage est implicite).
Certains aspects de la programmation générique resteront toujours complexes et pour les gurus, comme la réalisation d'un DSEL, même si boost.proto aide beaucoup.
L'héritage permet d'avoir du polymorphisme dynamique à la Java, ce qui est souvent synonyme de programmer plus ou moins à la Java, avec des pointeurs dans tous les sens, de la sémantique d'entité et de la gestion de mémoire "globale" (refcounting ou GC).
Bien évidemment, programmer avec l'héritage, une sémantique de valeur et une gestion de mémoire "non globale" peut se faire, mais en pratique ce n'est pas fait.
Les gens adeptes de cette approche, quand ils codent proprement, utilisent alors plutôt shared_ptr.
La mode actuelle vers laquelle se dirige le C++ moderne est cependant de ne pas utiliser l'héritage, mais de préférer le sous-typage implicite non-intrusif, comme les concepts donc, et avec des objets valeurs (qui restent implémentés par des fonctions virtuelles et des templates sous le capôt) .
Un exemple populaire étant function<R (T1... TN)>, qui permet de contenir un objet de n'importe quel type à partir du moment où on peut l'appeler avec la signature choisie. D'autres exemples plus génériques sont boost.any et choses similaires.
Le futur étant quelque chose dans le genre de adobe::poly -- qui a eu quelques publications scientifiques ces derniers temps [1] --, qui permet vraiment d'avoir de la programmation générique comme avec les templates avec du polymorphisme dynamique au lieu du polymorphisme statique qui les caractérise.
L'héritage multiple etc. est vraiment très peu utilisé. Principalement par la programmation par contrats ou par les frameworks fortement orientés objet (comme le sont bien souvent les GUI toolkits).
Donc réellement, les aspects intéressants du C++ sont le RAII et les templates.
Dire que ce sont des fonctionnalités complexes uniquement pour utilisateurs avancés me semble donc une aberration.
Si ces aspects ne sont pas bien connus par la personne, ou pas utilisés, je pense donc que celle-ci passe vraiment à côté de ce qu'est C++.
[1] http://www.emarcus.org/papers/MPOOL2007-marcus.pdf
http://www.emarcus.org/papers/MPOOL2007-slides-marcus.pdf (même chose sous forme de slides)
[^]Re: C++ : RAII et programmation générique
C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?
Quand je lis ça j'ai l'impression de lire la présentation de bidouille énorme possible avec de la magie noire en perl qui au final permettent des choses très puissante mais ça reste de l'exploitation de truc tordu.
Enfin la vraie question derrrière tout ça, c'est : est-ce que c'est utile pour 90% des personnes qui developpent des logiciels ? ou est-ce que l'investissement de temps a apréhender tout ces concepts est récupéré derrière et apporte vraiment quelque chose ?
Je critique pas particulièrement, mais je suis pas fan des arguments qui t'explique que ça poutre mais que tu peux pas comprendre sans te dire vraiment l'intérêt derrière tout ça (à part la beauté du concept)
Sylvain "Skarsnik" Colinet
Victory was near but the power of the ring couldn' t be undone
[^]Re: C++ : RAII et programmation générique
C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?
Dans le cas des concepts, l'interet c'est de faire verifier par le compilateur que l'argument d'un template presente bien les proprietes (fonctions/types) necessaires pour le bon fonctionnement du template en question. Ca va permettre d'eviter les messages d'erreurs types 500 lignes, avec a la place un vrai message intelligible. C'est un vrai progrès par rapport au duck-typing de la situation actuelle.
est-ce que c'est utile pour 90% des personnes qui developpent des logiciels ? ou est-ce que l'investissement de temps a apréhender tout ces concepts est récupéré derrière et apporte vraiment quelque chose ?
Si on limitait la cible a 90% du public, on utiliserait windows, non ? Plus serieusement, c'est clair que C++ est un langage complexe, mais on n'est pas obligé non plus de mettre en oeuvre toute cette complexité. Pour réaliser des choses simples, on peut rester simple (cf Qt), mais devant des problemes complexes, on est bien content de trouver tout le support necessaire dans le langage (cf Boost.Graph pour des graphes de grande taille).
Sinon, je plussoie fortement loufoque: si on ne devait retenir qu'une seule chose de C++, c'est le RAII pour la gestion des ressources.
[+] [^]Re: C++ : RAII et programmation générique
C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?
Imagine, tu est dans l'objet Collection<E>
Tu veux faire une méthode d'intersection qui te permet de prendre une collection<F> en argument
et de rendre une autre Collection<E> qui soit l'intersection de E et F selon une fonction de comparaison
f(E,F) -> boolean |-> E == F; que tu vas lui donner en paramètre.
Par exemple, je sais pas, un exemple débile : F est un type date, E est un type String dont le contenu contient toujours un numéro d'année.
Tu veux la liste des string qui contiennent le numéro d'année (par exemple "2008") qui soit le même que la collection de date que tu lui donne en argument.
ça te permet de faire
Collection<E> list1,result;
Collection<F> list2;
result = list1.intersection(& F autreliste, * pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix);
Evidemment, sans type Block comme en Smalltalk/Ruby/IO/Lisaac, t'es obligé de passer par un pointeur de fonction, mais voilà la puissance est là :
Quand tu écris la fonction d'intersection, tu connais pas E, tu connais pas F, et ça marche dans tout les cas (pas en C++ parce que si ta fonction fait n'importe quoi... ça plante, et le compilateur vérifie pas)
loufoque nous donnera surement une bidouille pour contourner ça proprement !
[^]Re: C++ : RAII et programmation générique
Evidemment, sans type Block comme en Smalltalk/Ruby/IO/Lisaac, t'es obligé de passer par un pointeur de fonction
Pourquoi un pointeur de fonction ? En C, je veux bien, mais en C++ on utilisera plutot un objet pour ca.
Quand tu écris la fonction d'intersection, tu connais pas E, tu connais pas F, et ça marche dans tout les cas
Moui. J'ai bien l'impression que j'ecrirais ceci pour le predicate d'intersection:
template < typename E, typename F >
bool compare( E e, F f ) { return e == f ; }
Je ne connais ni E, ni F, et ca marche dans tous les cas ou l'operateur de comparaison == est defini. Dans les autres, le compilateur va couiner, et c'est tres bien ainsi.
pas en C++ parce que si ta fonction fait n'importe quoi... ça plante, et le compilateur vérifie pas
Ah. Et dans les langage que tu cites, une fonction qui fait n'importe quoi, ca ne plante pas, et le compilateur verifie ? Pour toutes les valeurs de n'importe quoi, meme les grandes ?
[^]Re: C++ : RAII et programmation générique
Ah. Et dans les langage que tu cites, une fonction qui fait n'importe quoi, ca ne plante pas, et le compilateur verifie ? Pour toutes les valeurs de n'importe quoi, meme les grandes ?
En Smalltalk/Ruby/IO ça devrait planter à l'exécution.
En Lisaac, le compilateur te gueulera dessus à la compilation, et refusera de compiler.
[^]Re: C++ : RAII et programmation générique
En C++, on généralise les fonctions aux foncteurs, c'est à dire tout type qui peut s'appeler tel une fonction (donc éventuellement une classe avec un operator() surchargé).
C'est comme ça qu'on fait des closures etc.
boost::lambda (et autres du même genre) génère automatiquement un foncteur à partir d'une expression lambda.
Et en C++0x y'a une syntaxe spéciale pour exprimer les fonctions lambda.
Donc franchement, je ne vois pas pourquoi tu parles de pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix. D'autant plus que la fonction utilisera par défaut operator==, donc il s'agira d'un argument optionnel.
Et je vois pas non plus pourquoi tu mets des & et * ? C'est n'importe quoi. Et cette définition de result vide alors que tu le redéfinis après, c'est tout simplement sous-optimal et stupide.
Je pense qu'intersection devrait être une fonction libre : il ne s'agit nullement d'une propriété propre à ta liste.
Accessoirement elle devrait écrire sa sortie sur un itérateur pour pouvoir mieux être exploitée.
Bref, un design à la std::set_intersection, mais sans tri. (ça va faire un bel algo en O(n*m) tout pourri)
Quand on voit que les gens qui critiquent le C++ ne savent même pas des trucs basiques comme ça, ça fait peur.
[^]Re: C++ : RAII et programmation générique
Quand j'ai "subi" VC++ 6, mes collègues m'ont expliqué que le seul moyen de faire des fonctions en C++, c'était le pointeur.
De même, quand j'ai voulu passer un paramètre sans le &, le compilateur m'a gueulé dessus, et on m'a expliqué pourquoi c'était pas possible.
Bon après, il parait que VC++ 6, c'est pas le meilleur.
Je ne connais pas C++ car pour moi, et c'est, je suis d'accord, un avis très très tranché, un langage dont la spec fait 500 pages c'est ------> poubelle.
Je pense pour ma part qu'une spec de langage, ça doit pas dépasser 80 pages, exemples compris. Un bon langage est minimaliste, pas bloated. Sinon on met des années à le maîtriser, on se complique inutilement, et à part faire plaisir aux quelqu'un comme toi, qui maîtrisent (très bien) la chose, on ennuie tout le monde.
Faut pas s'étonner que Java se soit imposé.
Cela dit, j'avoue que j'ai un peu regardé les templates pour piquer les rares fonctionnalités de c++ qui n'existent pas dans Lisaac, afin qu'on les y mettent. C'est en debug, ça va arriver bientôt.
Je me suis documenté sur les foncteurs en C++ (http://h-deb.clg.qc.ca/Sujets/Divers--cplusplus/CPP--Foncteu(...) : je ne sais pas si cette doc te parait valable )
Désolé, mais c'est un workaround tordu pour implémenter le type block bien connu des langages comme smalltalk/ruby/lisaac/io/...
Le type bloc est une fonction à évaluation retardé, elle peut recevoir un ou plusieurs paramètre et en renvoyer plusieurs (bien que ça dépende du langage)
Parce que franchement, utiliser les opérateurs pour redéfinir () et utiliser le constructeur comme foncteur, c'est tordu de chez tordu.
N'avaient qu'à implémenter le type block et ça aurait été réglé.
Le problème, c'est que c'est dur à compiler du block, et c'est très très dur d'avoir des perfs avec. Ils ont alors préféré faire un truc hyper compliqué, mais qui refile le sale boulot au programmeur.
Parce que tu sais ce que sont les templates en définitive ?
De l'analyse de flot codé à la main par le programmeur !
Comme le compilateur est beaucoup trop gros pour faire de l'analyse de flot lui-même et détecter les chemins de code à optimiser (évidemment, il y a 500 pages de specs à implémenter), en effectuant de l'évaluation partielle de code sur le code statique, on demande au programmeur de baliser l'analyse de flot parce que le compilateur ne sait pas le faire !
Je revient au type block : l'itérateur devient inutile, puisque tu fait ton foreach naturellement, et que le coût est exactement le même.
Ton idée de généraliser l'intersection est très intéressante : je la mettrai bien dans object.
[^]Re: C++ : RAII et programmation générique
VC++ 6 est un tres mauvais compilateur, c'est un fait reconnu. M'enfin, il faut dire que le C++ est un langage standardisé ISO, et le vendeur de VC++ a quelques petits problemes a respecter les standards qui ont été fait par d'autres (même si dans le cas de C++, ca a fini par s'améliorer).
Mais bon, si tu ne connais C++ qu'a travers ce compilateur, et que tu refuse d'aller plus loin parce que la norme fait plus de 500 pages, tu ne crois pas que c'est un peu limité comme point de depart pour critiquer comme tu le fais ?
un langage dont la spec fait 500 pages c'est ------> poubelle.
Je pense pour ma part qu'une spec de langage, ça doit pas dépasser 80 pages
Est-ce que les 80 pages en question sont seulement destinée au programmeur qui va utiliser le langage, ou bien elles sont suffisantes pour un fournisseur extérieur qui voudrait implémenter un compilateur sur une architecture à priori inconnue des concepteurs du langage ?
Un bon langage est minimaliste, pas bloated.
Non. Un bon langage, c'est d'abord un langage adapté au problème à traiter. Ensuite, on regardera d'autres critères : portabilité, performance, sécurité, pérennité du founisseur, facilité pour trouver des programmeurs, disponibilité d'outils d'instrumentation et debogage, etc. Si on considère ces critères, le seul bon langage parmi ceux que tu cites serait smalltalk... et encore, il faudra peut être gratter pour trouver des programmeurs.
Evidemment, après, pour se faire plaisir dans le monde universitaire, on peut faire des langages minimalistes, jolis et académiques. Du point de vue recherche, c'est tres bien, je ne critique pas cet aspect, mais du point de vue industriel, ca n'est vraiment pas un critère majeur.
Parce que franchement, utiliser les opérateurs pour redéfinir () et utiliser le constructeur comme foncteur, c'est tordu de chez tordu.
N'avaient qu'à implémenter le type block et ça aurait été réglé.
Ca depend de la definition de "tordu". La redéfinition d'operateur, en particulier operator(), existait avant l'apparition des templates et du besoin de foncteur. A partir de la, il a semblé plus "tordu" de modifier le langage et faire évoluer tous les compilateurs existant, plutot que d'utiliser une fonctionnalite qui existait déjà.
Ton idée de généraliser l'intersection est très intéressante : je la mettrai bien dans object.
J'espere que tu ne va pas mettre toutes les "fonctionnalites interessantes" dans object...
[^]Re: C++ : RAII et programmation générique
VC6 qui date accessoirement de 97, pour une norme qui date, elle, de 98. Pour un compilo qui pré date la norme, il s'en sort pas trop mal.
Si seulement il ne s'était pas imposé comme un standard persistant en industrie... :(
[^]Re: C++ : RAII et programmation générique
Faut pas s'étonner que Java se soit imposé.
Java c'est pas forcément imposé parce qu'il est "trop top méga cool", mais entre autre parce qu'il y a une vrai API très large, avec une vrai doc.
Essayez de trouver comment ouvrir "simplement" sans rechercher pendant 2 jours une librairie, un socket SSL (exemple au hasard) , voila quoi ...
my 2 cents
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: C++ : RAII et programmation générique
Ah oui et bien sûr, si tu ne peux pas comparer tes éléments, tu auras une erreur à la compilation et non à l'exécution, bien évidemment.
Je ne sais réellement pas d'où tu sors tout ce tas de choses fausses sur C++.
[^]Re: C++ : RAII et programmation générique
De la souffrance que j'ai subi à devoir l'utiliser.
[^]Re: C++ : RAII et programmation générique
"le sous-typage implicite non-intrusif" Je ne vois pas trop ce que cela donne. Tu as plus d'infos ?
[^]Re: C++ : RAII et programmation générique
J'ai compris le sous-typage, qui est ce que je considérais comme l'utilisation propre de l'héritage. (utiliser une class image, et des class pour des images jpg, png, tiff,... qui sont toujours des images.)
Pour contre le rapport avec implicite et non-intrusif, je ne vois pas trop.
[^]Re: C++ : RAII et programmation générique
http://en.wikipedia.org/wiki/Structural_type_system
[^]Re: gcc lave plus blanc ?
C'est la philosophie du C++ qui me dérange. Et là, d'accord, ce n'est que mon avis.
Je suis pour des langages minimalistes. des langages définis avec une ou maximum deux dizaines de primitives, une dizaine de mots clé, admettons une vingtaine.
Si le langage est bien conçu et les primitives bien choisies, tu peux aller très loin.
Les langages à la smalltalk/ruby/io/lisaac ont ma préférence car ils sont minimalistes en étant bien plus puissant. Toutes les structures de contrôles sont définies en lib, et énormément de choses le sont avec des primitives de base.
En c++, tu pleures avec ton pauvre for et ton while.
Quand au template, c'est un problème de compilation : les templates servent à précompiler toutes les données statiques disponible à la compil. Un bon compilateur à analyse de flot sait le faire, sans imposer au programmeur de concevoir les templates.
En mettant en dur ta regexp dans une chaine, et la chaine à matcher, le compilateur est capable, par analyse de flot, de calculer la réponse.
Si la chaine cible n'est pas là, il compilera l'automate.
Pas besoin de template qui palie aux faiblesse d'un compilateur, sur lequel tous les énormes efforts sont portés à implémenter une norme pléthorique, plutot que de faire un compilateur puissant, mais simple.
[^]Re: gcc lave plus blanc ?
Ça me rappelle les débats sur le respect des standard du web...
Pour moi, un code qui compile sur un compilo mais qui n'est pas standard, c'est du même ordre que de dire "mon HTML marche sur IE" --> /dev/null
Pour moi, un code propre respecte les standards (condition nécessaire) et le support des bugs de compilateurs ne doit être que temporaire.
[^]Re: gcc lave plus blanc ?
D'un autre coté quand on voit ce qui ce passe chez un certain microsoft c'est gère mieux :
- Ils sont pas foutu d'avoir un compilo qui s'approcherait des standards C.
- ils ont des includes pas standard qui font que des compilos comme gcc (mingw) ne peuvent pas forcement bien les parser et à cause de leur licence on ne peut pas les patcher.
- leur libc est à l'image de leur compilo.
Bref c'est que du bonheur de faire du code portable en prenant en compte windows (ca me rappel le code html pour ie).
Pour le couple gcc/glibc, ce que je regrette c'est que les gens ne se rende pas forcement compte de ce qui est standard et ce qui ne l'est pas.
Et malheureusement, je crois pas qu'il existe de moulinette qui donnerait la conformité du code (ISOC, POSIX, BSD, extension gcc, extension glibc, extension linux, ...).
[^]Re: gcc lave plus blanc ?
Pour le couple gcc/glibc, ce que je regrette c'est que les gens ne se rende pas forcement compte de ce qui est standard et ce qui ne l'est pas.
Et malheureusement, je crois pas qu'il existe de moulinette qui donnerait la conformité du code (ISOC, POSIX, BSD, extension gcc, extension glibc, extension linux, ...).
Il y a quand même l'option -std= de gcc, et également dans la glibc, il y a un certain nombre de define qui définissent ou non certaines fonctions (cf /usr/include/features.h).
Cela dit, je te rejoins sur le fait que nombre de développeurs ne se soucient pas de la portabilité et activent tout par défaut sans séparer les parties spécifiques au système utilisé, ce qui oblige à aller taper dans tous les coins pour faire le portage. On se retrouve vite avec une soupe de #ifdef dans tous les fichiers.
[^]Re: gcc lave plus blanc ?
Il y a quand même l'option -std= de gcc
Sauf que ca ne verifie pas tout si je me souviens bien.
et également dans la glibc, il y a un certain nombre de define qui définissent ou non certaines fonctions (cf /usr/include/features.h).
Idem c'est tres vite limité.
Par exemple certaines fonctions POSIX ont des extensions linux sans garde fou (ie define a definir).
Il n'y a pas non plus de séparation ISOC/POSIX.
[^]Re: gcc lave plus blanc ?
Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard