Discussion :

[mat.M]

C++ builder, VC++ 2005 express (gratuit), Visual Studio 2005.

Le C++ est le langage qui doit offrir le plus grand choix d'IDE je pense

Je me suis mal fait comprendre et mal exprimé ;

quand je parle de "tout intégré" c'est d'outils Atelier Genie Logiciel, P.G.I., etc...
Par exemple des outils comme Websphere à base de Java il me semble , les PGI de PeopleSoft, pas d'outils de programmation de base comme VC++ ou autres.
Par tout intégré il faut comprendre gestion totale du cycle d'un progiciel , modules intégrés de gestion , de comptabilité etc ...( par exemple pour la SNCF ).

[neo.51]

Tant qu'une partie du langage C++ restera attaché au wagon .NET il y aura la solution "tout intégré" avec Visual Studio.

Dans VS 2005, arrivée du designer (pseudo) UML, tests unitaires, ...

Il ne manque plus que la gestion du projet au sens large (gestion du code et des process entrant dans le cycle de développement) on peut y arriver en allant récupérer des outils open-sources à droite à gauche, mais le tout unifié arrivera en C++ avec Visual Studio 2005 + Team foundation (d'ici quelques mois).

Coté borland j'ai jamais testé tout ça mais C++ Builder + together semblait être une solution pour ce genre de besoins.

Tu as tout à fait raison, une techno proposant 1 environnement pour gérer un projet de A à Z c'est déjà un argument en sois en faveur de la techno quand on s'attaque à des gros projets .

[epsilon68]

Bonjour,

Moi personnellement je pense que le C++ se joue sur Qt, du moins en entreprise, et que la force du C++ se situe dans sa portabilité, dans sa rapidité et surtout dans le nombre de librairies et programmes deja ecrits.

Cependant, dans mon entreprise je n'ai pas pu une seule fois utiliser C++.
Le C++ a beaucoup d'avantage mais necessite un peu plus de temps de developement. C'est quand on discute avec un client, qu'il veut l'outil pour hier pour un prix ridicule. Je dois avouer que ce n'est pas C++ qui nous vient a l'esprit. Aussi pourquoi lui fournir la Rolls alors qu'il veut payer un velo ?

J'ai recemment pris du temps pour encore essayer Qt 4 et faire plusieurs forms, imitant un produit que j'ai deja fait en C#. Et bien je dois dire que j'etais tres content du resultat. J'ai aussi remarque qu'on factorise plus le code avec C++/Qt.

Mais C++ est tres difficile a justifier de nos jours dans les projets courant:
(GUI + Database) et la rapidité de C# en execution et surtout en developement est vraiment impressionante. Aussi en entreprise, on se moque carrement de la vitesse d'execution, du moins jusqu'a une certaine limite, mais Java par exemple convient parfaitement.

Aussi c'est marrant mais a la maison pour mes projets perso, je ne me pose pas du tout de question, c'est C++/Qt sous linux, en testant frequement sur Windows et bientot sur Mac j'espere ... Oui je suis vraiment tenté d'acheter un nouveau Mac Intel...

- Epsilon

[epsilon68]

Pour tester la rapidité d'execution de C++/Java/C#
J'ai realisé un vrai programme calculant la trajectoire d'un outil sur une surface 3d (triangles). Je l'ai programmé pour Java et utilisé le convertisseur Java -> C#.
Cela veut dire que C# est utilisé comme Java, avec des objects et pas de structure, qui auraient pu ameliorer la quantité memoire et un tant soit peu la rapidité.

sur un centrino 1.6MHz 1Go de memoire
C++ 12s (VS 2005)
C# .NET 1.1 23s (VS 2003)
C# .NET 2.0 20s (VS 2005)
Java 1.5 28s (NetBeans 5)

la difference n'est pas enorme entre C++ et C# (facteur de 1.6)
Le code de Java et C# apparaisse aussi plus lisible que C++ quand on maintient le code....

A votre avis, le code natif a-t-il encore beaucoup d'avantage par rapport au code managé ? en entreprise ?

[Matthieu Brucher]

Personnellement, je me vois mal dire à mon boss ceci :

Hey ***, j'ai décidé de passer à Java ou C#, bon, ça sera plus lent - 2 ou 3 fois plus lent au moins - et ça concommera 2 fois plus de mémoire

Il me tue sur place - on a des temps de calcul de plusieurs heures voire jours dans certains cas et une occupation mémoire de plus de 2Go si on se débrouille mal, 1Go si on se débrouille bien -

[epsilon68]

C'est quoi comme appli ?
En tous les cas c'est sur que C++ est incontournable dans certain cas...

Cependant dans mon entreprise, on fait des appli de gestion,
et moi je ne peux pas justifier le C++/Qt meme si j'aimerais bien.

Un exemple concret, j'ai recemment developpé un outil de config pour modifier deux fichiers xml, utilisés par une appli flash (genre de questionnaire en plus evolué). J'ai beaucoup utilisé DOM/XPath. J'ai ouvert VS.NET et j'ai programmé.

J'ai prototypé la meme appli en Qt pour voir ....
Dejà DOM/Xpath ? alors libxml .... heu... c'est quand meme pas si simple non ?
Le reste avec Qt Designer, c'est pas mal.

et c'est quand meme plus long avec Qt/C++, si en plus maintenant on me demande de manipuler un objet com, la c'est carrement moins facile non ?
il faut aussi payer les licences ....
Comment justifier le cout ?

Aussi je m'etais toujours dit que le code managé avait un facteur de plus de 3 mais ce n'est pas ou plus vrai, C# m'a beaucoup surpris. Le code est aussi plus claire, la notation pointer alourdit quand meme pas mal le C++...

Aussi dans la maintenance d'un programme, le garbage collector est vraiment utile, on peut modifier un objet en le re-encapsulant ...

Je parle beaucoup de C#, mais en fait mon coeur balance entre Qt et Java,
pour le multiplateforme, et pour l'instant Qt me passionne...
L'opengl est bien mieux integré et geré dans Qt, ca sera l'interface pour mon programme.

Mais je me pose regulierement la question, il y aura bien un moment ou Java aura plus d'avantages, ne serait-ce que pour la clarté du code sans perdre de trop en performance.

Votre avis ?

- Epsilon

[outs]

A votre avis, le code natif a-t-il encore beaucoup d'avantage par rapport au code managé ? en entreprise ?

Ce que je trouve étrange dans toutes cette histoire c'est qu'on peut avoir sans aucun problème du code natif avec un garbage collector. Et même avec beaucoup plus d'expressivité et de puissance que les langage dit "managé" tout en restant compilé et rapide. Je citerai pas de langage ca apporte rien au discours a par un troll.

Mais seulement il ne fait pas avoir peur de sortir un tout petit peu des sentiers battu.

[Matthieu Brucher]

C'est quoi comme appli ?
En tous les cas c'est sur que C++ est incontournable dans certain cas...

En fait, c'est une appli de traitement d'images médicales, donc de très grosses images, et beaucoup d'images. Pour l'instant, 90% sont encore en C avec GTK1.2 comme GUI - beurk -, mais on essaie de faire tous les nouveaux traitements en C++ - enfin, ceux qui arrivent à s'en sortir -, et là, c'est C++/Boost en général - Qt non parce que cher ou GPL, même si je fais mes tests avec Qt -

[epsilon68]

Je n'ai pas bien compris, vous utiliser GTK ? pourquoi pas Qt ?
Vous etes multiplateforme ou uniquement sur Linux / window ?

Vous utilisez quoi dans Boost ? moi je l'ai toujours trouvé un peu complique et difficile a utiliser sur plusieurs compilateurs, genre VS 2005 qui ne marche plus avec ....

[Matthieu Brucher]

C'était sous Windows avec wxWidgets, c'est passé plus tard à Linux avec GtK1.2, le tout sur 10 ans
Pourquoi pas Qt ? Cher ou GPL, et GPL, c'est pas ce qu'on veut, à priori, même si avec le prochain gros changement, je préfèrerai que Qt gagne sur wxWidgets ! - ce ne sera sans doute pas GTK2 -
Pour Boost, il marche très bien avec VS2005 - je sais, j'ai testé mes algos dessus -
Ce que j'utilise ? Random, SmartPtr, MPL, Bind, ...

[epsilon68]

Ok je comprends mieux ...
Qt c'est quand meme beaucoup plus de facilité et surtout bien multiplateforme.

Personnellement je n'utilise pas trop Boost meme si je l'ai de temps en temps teste, je prefere rester centré sur Qt, le multiplateforme est pour moi super important.

Mais bon je dois aussi dire qu'il me tente de plus en plus quand meme
Cette librairies est tout le temps tres en avance sur les compilo et j'ai assez peur des bugs cachés ... Mais bon pour toi ca a l'air de rouler

[Matthieu Brucher]

Boost est multiplateforme, bien plus que Qt.
Ensuite, pour être acceptée dans Boost, une bibliothèque doit subir une revue par des membres du comité directeur et ils ne sont pas le genre à laisser passer un bug, aussi petit soit-il ! Il y a toujours une série impressionante de tests de régression qui est effectuée, et le résultat pour chaque plateforme et compilateur est disponible sur le web.

[epsilon68]

Je ne suis pas tout a fait d'accord mais bon je veux bien admettre que Boost soit tres portable, mais Qt a l'obligation d'etre 100% portable et elle l'est.

je trouve aussi boost assez compliqué a utiliser et la syntaxe est assez lourde du aux templates. J'aime la syntaxe de Qt, simple a lire et a utiliser.

Ce n'est finalement qu'une question de gout, tu as surement plus l'habitude que moi vu que tu l'utilises tout le temps dans un cadre professionnel...

A+

[Matthieu Brucher]

Boost est plus portable que Qt, Qt n'est à destination que de 3 plateformes, Boost est dispo pour bien plus de plateformes et aussi maintenu que Qt.

[Luc Hermitte]

Je ne suis pas persuadé que QT ne soit limité qu'à trois plateformes. Ou alors ils ont de très bons vendeurs et je me suis fait avoir -- vu que j'aime moyennement leurs choix de design, je m'y intéresse moyennement.
Ce qui est sûr, c'est qu'ils cherchent à supporter les compilos en retard sur la norme (qui a déjà 8 ans mine de rien). De là à ce que ces compilos ne soient plus supportés par leur fournisseurs... (je pense à VC6).
Boost, c'est tout le contraire: c'est un peu le labo qui sert de base à la prochaine norme (pour le côté bibliothèque).

Côté syntaxe, boost simplifie tout de même pas mal les choses avec ces bibliothèques comme bind ou lambda. C'est imparfait, mais un gros progrès par rapport au C++ standard. Après rien ne nous empêche de sortir des artilleries perl pour encore plus simplifier les choses ; le préprocessing, c'est autre chose. Le C++09 devrait encore rajouter une couche de simplifications.

Un truc que j'aime bien avec boost: c'est que l'on peu trouver les choix de design et quantités de discussions intéressantes à leur sujet. Pour QT, va compendre pourquoi ils ont estimé que le COW (globalement rejeté aujourd'hui) serait au centre de QT 4... Ce ne sont pas les mêmes démarches.

Ce que j'utilise de boost ? Diverses choses assez hétéroclites (les smart_ptrs, bind, range.begin/end, file_system, noncopyable, static_assert, any, iostreams, program_options, regex, string_algo, lexical_cast). Je suis loin de tout utiliser. Je prends selon les besoins.

[epsilon68]

Tient c'est marrant moi j'adore le design de Qt.
C'est quoi le COW ?

J'ai encore regarde Boost, je m'excuse mais j'ai du mal a me persuader d'utiliser une de leur librairie.

Perso, je prefere les signal/slot de Qt (valable a travers plusieurs thread),
les threads de Qt, les conteneurs de Qt, les shared object, les acces fichiers, la philosophie de Qt.

J'aime aussi bien les bind et les pointer function en Boost, mais c'est vraiment rare de les utiliser, ou alors je ne dois pas avoir la bonne appli ou je dois mal programmer .... heu ... j'espere que non

Concernant les algo, je dois dire que je n'en suis pas au stade de tout parametrer et d'utiliser les templates partout, non je suis rester au stade des boucles ... peut-etre trop basic ? j'en sais rien

Sinon c'est vrai que Boost c'est le domaine de prototypage du C++, ou les compilos n'ont qu'a bien se tenir

[Matthieu Brucher]

Qt est sur 3 plateformes, Qtopia est sur plus, mais c'est un peu différent tout de même.
COW, c'est Copy On Write, en fait, au lieu de copier un objet compltement lors de sa copie, on partage ses données, et si on décide de modifier, alors seulement on copie en profondeur. Par exemple, les string étaient implémentées ainsi pendant longtemps - voir Stutter ici : http://c.developpez.com/livres/#L020170434X -. Le gros inconvénient, c'est le multithread...
J'utilise le COW pour des objets très coûteux à copier, c'est tout.

[epsilon68]

Je pense qu'il y a assez de plateformes supportées par Qt:

Supported Platforms
Platforms 32bit
Microsoft Windows gcc (MinGW) MS Visual Studio/Visual C++ Intel icc
Linux gcc - -
Apple Mac OS X gcc - -
IBM AIX gcc IBM xlC -
HP HP-UX gcc HP aCC -
SGI IRIX gcc SGI MipsPRO -
Sun Solaris gcc Sun CC -
FreeBSD gcc - Intel icc

Tu veux lesquelles en plus ? Pour moi il supporte les os / compilateurs du marché... je pensais que c'etait suffisant ...

Merci pour la definition ....
Sinon le COW, ils expliquent qu'ils ont trouvé le moyen sur toutes les plateformes d'utiliser un lock qui ne consomme pas de temps.
Alors c'est parfaitement multi-thread, d'ailleurs Qt se compile en Multi-Thread
et ce n'est plus une option.

Moi je trouve leur implementation du COW tres astucieuse, et je me suis demandé pourquoi moi je n'y ai pas pensé avant !!! mince

Sinon moi je comprends parfaitement pourquoi ils l'ont mis au centre de Qt,
Ca allege beaucoup la notation (evite le pointer) et evite la recopie incessante... ce qui au final est bien plus agreable a utiliser sans perte de performances, avec meme un speed up dans la plupart des cas.

Voila...

[epsilon68]

Threads and Implicit Sharing

Qt uses an optimization called implicit data sharing for many of its value class, notably QImage and QString. In many people's minds, implicit sharing and multithreading are incompatible concepts, because of the way the reference counting is typically done. One solution is to protect the internal reference counter with a mutex, but this is prohibitively slow. Earlier versions of Qt didn't provide a satisfactory solution to this problem.

Beginning with Qt 4, implicit shared classes can safely be copied across threads, like any other value classes. They are fully reentrant. The implicit sharing is really implicit. This is implemented using atomic reference counting operations, which are implemented in assembly language for the different platforms supported by Qt. Atomic reference counting is very fast, much faster than using a mutex.

This having been said, if you access the same object in multiple threads simultaneously (as opposed to copies of the same object), you still need a mutex to serialize the accesses, just like with any reentrant class.

To sum it up, implicitly shared classes in Qt 4 are really implicitly shared. Even in multithreaded applications, you can safely use them as if they were plain, non-shared, reentrant classes.

[Luc Hermitte]

a- Perso, je prefere les [...] conteneurs de Qt

b- J'aime aussi bien les bind et les pointer function en Boost, mais c'est vraiment rare de les utiliser, ou alors je ne dois pas avoir la bonne appli ou je dois mal programmer .... heu ... j'espere que non

a- Typiquement le genre de trucs où je ne vois pas vraiment d'intérêt de réinventer la roue.

b- Soit tu ne fonctionnes pas itérateurs (façon itérateurs standard), soit tes itérations sont trop complexes pour être réduites à l'application d'une fonction non triviale, mais relativement simple, sur tous tes élements. Ou tu utilises les algos de QT ce qui après préprocessing doit revenir au même. La dernière fois que je me suis servi de boost.bind c'était pour récupérer les noms de fichiers depuis d'une liste de chemins absolus -- et encore, ce n'était pas nécessaire ici, l'exemple est simple.

Code :

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

1
2
std::transform(pl.begin(), pl.end(), std::back_inserter(fl), 
    boost::bind(&boost::filesystem::path::leaf, _1));

Sinon, les rares cas où je vois un intérêt au COW, c'est pour pallier à l'absence d'une sémantique de déplacement native qui coute dans les retours de fonction par valeur où le compilo est incapable d'appliquer la RVO [1] -- faut attendre le C++09 pour une sémantique de déplacement native à condition que les rvalue references soient acceptées dans le standard.

Mais même avec les incréments atomiques, cela a un coût (car adieu pipeline et cache). Certes moindre que si on utilisait un mutex (ceci dit je ne crois pas que toutes les plateformes supportent ces opérations atomiques).
Aujourd'hui, la seule solution que je connaisse pour absorber ce coût (de recopie sur return), c'est de multipler les types (=> const_string, mutable_string, auto_string, ...). Ce qui n'est pas très pratique pour le développeur des bibliothèques -- ou de passer les paramètres en [in,out].

Bref, le COW de QT reste du COW somme toute classique. D'autres bibliothèques en sont revenues. Pourquoi QT y va ? C'est ce genre de question à laquelle ils ne répondent pas (sponatannément).

[1] Return Value Optimizaton : les compilos construisent directement le résultat dans la variable qui le récupère à la sortie de la fonction => pas de copie.