au sujet du choix des outils et des versions de bibliothèques

Version imprimable

17/04/2010, 02h34
koala01

au sujet du choix des outils et des versions de bibliothèques
Salut,

La plus grosse difficulté, lorsqu'il s'agit d'envisager un travail collaboratif, consiste à assurer l'homogénéité des outils et des versions de bibliothèques utilisés.

Le problème est d'autant plus criant que, C++11 n'étant pas encore finalisé, le support de cette norme risque de s'avérer des plus irréguliers en fonction du compilateur et surtout de la version du compilateur utilisé.

A cela s'ajoute le problème de... la version de boost que nous voudrons utiliser car il faut au minimum assurer un aspect "thread safe" et la présence de certaines bibliothèques comme signals2.

Le problème est décidément fort complexe, car il s'agit de:
- S'assurer que tout le monde puisse travailler
- S'assurer d'une compatibilité maximale du code fourni vis à vis des compilateurs émanant des différents fournisseurs
- choisir une version suffisamment stable des bibliothèques de boost que nous utiliserons mais suffisamment récente pour qu'elle fonctionne de manière "thread safe"
- Assurer la possibilité de compilation aussi bien en version 32bits qu'en version 64bits
Personnellement, j'utilise une version compilée par moi-même de Gcc 4.5.0 en version 64bits capable de générer également des binaires 32bits, et je disposer de la version 1.42.0 (la dernière sortie au moment d'écrire ces lignes) de boost.

Je dispose également sous ubuntu d'une version 64 bits de Gcc 4.4 avec également le support multilib (et une version perso de boost pour ce système).

Cependant, même si je peux transmettre ma version de Gcc à qui la souhaite, je ne peux malgré tout me résoudre à imposer son utilisation à tous.

Je souhaiterais donc que nous fassions ici la liste des compilateurs et des versions de compilateurs qui proposent, même à titre expérimental ou partiel, le support des nouvelles possibilités offertes par C++11, ainsi que les problèmes auxquels on risque d'être confrontés en termes de compatibilité.

A titre d'exemple, voici quelques questions qui nécessitent une réponse:
- Quel(les versions de)s compilateurs proposer un support, même partiel, des possibilités propres à C++11 :question:
- les versions potentiellement utilisables de visual studio travaillent-elles toujours avec un stdafx.h ou similaire :question:
- Quelles possibilités offertes par C++11 sont elles présentes chez un des compilateurs "candidat" et absentes chez l'autre :question:
- Quelles sont les différentes manières d'activer le support de C++11 pour les différents compilateur :question:
- Quelle est la version minimale de boost qui pourra être utilisée pour ce projet :question:
- A quoi devrons nous être attentifs, que devrons nous adapter afin de permettre aux différents compilateurs de travailler avec notre bibliothèque :question:
- il y aura surement d'autres questions
Merci d'avance pour votre avis.
17/04/2010, 05h15
metagoto

VS2010 C++11 features list:
http://blogs.msdn.com/vcblog/archive...the-table.aspx

GCC:
http://gcc.gnu.org/projects/cxx0x.html

Divers compilo:
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

Il ne faut pas rêver, un support "correct" et mainstream du prochain c++ ne se fera pas avant 5 ou 6 ans :mrgreen:

Les variadic templates sont absentes de VS2010...

Sur OSX, j'utilise (entre autre) GCC trunk ainsi que boost trunk. Ca fait quelques semaines que je n'ai pas recompilé tout ça. Toujours est-il que boost ne fait que commencer à migrer vers c++11. Certaines libs (je n'ai plus les noms en tête, mais il me semble qu'il y a au moins proto, variant...) ne compilent pas avec -std=c++0x sur les touts derniers gcc.

Vouloir cibler c++11 est l'idéal (sinon ce n'est plus trop interessant?), mais dans ce cas, la version minimal de boost n'est pas encore sortie, ni même le compilo!

GCC avance à grands pas. Je n'étais pas spécialiste du c++ en 1998 (je ne le suis toujours pas d'ailleurs :mrgreen:), mais j'ai quand même l'impression que les implémenteurs avancent beaucoup plus vite aujourd'hui qu'à cette époque en terme d'alignement et respect du standard.

Je ne sais pas ce qu'il faut penser de tout ça :ccool:
17/04/2010, 10h00
Invité

En ce qui me concerne, je suis sous Win32 (XP Pro), et j'utilise Borland (Builder 2007) pour le travail. J'y ai également accès à des versions récentes de VS, et j'ai un vieux GCC (3.4.5 je crois, boost 1.38) installé sur ma machine, que je n'ai jamais du trop utiliser. Je pensais le mettre à jour, et utiliser cela comme outil de developpement (l'idée d'utiliser eclipse me débecte un peu, mais bon...). Je me mettrai donc dans la version qu'on veut.

Maintenant, je pense qu'il va rapidement falloir distinguer plusieurs choses :

1- le "kit de développement" de la petite équipe qui va commencer sur ce projet.

Là il faut que ce soit très homogène : on n'a juste pas envie de perdre du temps à installer les compilos... Il me semble qu'on aurait intéret à partir sur GCC, une version assez récente, que tout le monde puisse avoir (Metagoto, des contraintes?), et plutôt du standard que du custom (comme ca, un "nouveau" n'a pas trop de difficulté à se mettre au niveau). La STL, chez GCC c'est STL-Port je crois, Boost, on en prend une et on n'en parle plus.

Ensuite, on essaie d'adopter une politique raisonnable vis à vis des nouveautés, on ne se jette pas sur tout ce qui sort, mais on essaye de ne pas trop prendre de retard.

2- les systèmes et fonctionnalités cibles

Au départ, je pense qu'on peut considérer que le 'standard' que nous supportons est celui implémenté par le compilateur du 'kit de dev' évoqué précédemment. Pas plus, pas moins...

Pour les nouveautés les plus nouvelles, on a généralement des solutions de remplacement dans boost (les typelist pour les variadic templates, par exemple).

L'intégration des éléments du standard nouveau se fera donc au rythme des mises à jour du kit de dev, qui correspondront, je pense, à de grands nettoyages du code.

3- les compileurs/systèmes cibles et la portabilité

Là, c'est une autre paire de manches. Tot ou tard, il faudra se lancer dans des tests, voir ce qui marche, ce qui coince, tout ca... Mais c'est un problème pour demain.

Le seul point de portabilité qu'on doit évoquer maintenant, ce sont les OS. Une librairie d'IHM est en prise directe sur l'OS, il faut donc avoir une liste minimale d'OS qu'on va prendre en compte.

On peut dire Win, Linux, et Mac OS?

Francois
17/04/2010, 12h00
Goten

Hum, pour les os, oui win, linux, et (pfiou :( ) mac doivent le faire. Mais mac c'est particulier...
Pour le compilo généralement je suis sous gcc 4.4, mais j'ai aussi 4.3 (pour le kernel) et 4.5. Je pense que visé ces trois versions est important car tout le monde ne compile pas son propre gcc. Et ceux passant par les versions des dépôts sont parfois vieux. (je dirais même la branch 3.3 )....
Pour VS, c'est quand même super important de le gérer (et c'est là que ça peut faire mal xD)... J'ai un VS2008 et un 2010 à dispo si il faut faire des tests ;).
Par contre je n'ai que des systèmes 32 bits.

Pour la version de boost : la dernière me semble être raisonnable. D'autant plus que boost est franchement pas compliquée à installer...

Petite précision pour les variadics template : de nos jours on a mieux que les typelists pour les émulés. (à coup de prepocesseur metaprograming )
17/04/2010, 12h29
Invité

Je pense qu'on va en fait développer sous GCC au début, mais tester assez large. Pour GCC, j'aurais tendance à dire "version récente", mais peut être que ca n'a pas de sens d'avoir tous la même... Si un petit changement de version du même compilateur casse la librairie, alors on est mal partis...

Pour les templates variadiques, tu connais certainement ca mieux que moi. Je pense que, dans la mesure ou c'est probablement une fonctionnalité qui nous sera utile, mais qui risque de n'être pas supportée vite (cf VS), il faut avoir assez vite en tête un remplacement compatible, quitte à l'emballer dans des #define ou des choses du genre. On a quelque chose dans boost qui marcherait "de série"?

Comme ca on ramène le problème au support de boost... (c'est d'ailleurs une bonne façon d'aborder le pb de compatibilité)

Francois

Il semblerait que je me sois très mal exprimé sur ce que j'attends de vous :aie:

Il est effectivement utopique de vouloir profiter de l'ensemble des fonctionnalités de C++11, mais, d'un autre coté, il me semblerait dommage de ne pas en utiliser quelques unes.

Par exemple, il serait intéressant de pouvoir profiter

du support correct SFNIAE
des "deleted functions"
des chaines de caractères unicode
des lambda expressions
du support correct des "angle brackets" pour éviter de voir >> évalué comme... un opérateurde flux
de la sémantique de mouvement
des lvalue references
peut être d'autres trucs sympa qui ne me viennent pas à l'esprit dans l'immédiat :aie:

Ces quelques points risquent déjà de limiter fortement le choix des outils, même si tous ne sont pas absolument nécessaires :aie:

Autrement, je suis effectivement totalement d'accord avec le fait que, au début, il serait pas mal d'avoir un "kit minimum" que chaque dev utilise.

Libre à chacun par la suite, s'il dispose d'outils supplémentaires de voir ce que cela donne en terme de compatibilité (du moins, en attendant que l'on ne s'attache réellement au problème :aie:) ;)

Seriez vous d'accord, afin de nous donner le maximum de chances de profiter d'un maximum de possibilités nouvelles, de baser le développement sur Gcc 4.5 + patches éventuels et sur boost 1.42 :question:

je penses, par exemple, aux fichiers disponibles sur le site de mingw-w64 qui est la branche potentiellement multilib de mingw (ou de toute version postérieure ou compilée personnellement), et dont la dernière version en date compilée par sezero est composée comme suit:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 MinGW-w64 *experimental* personal 'sezero' build from 2010-04-16. Compatibility / Experimental Notice: ** No leading underscore ** ----------------------------------------------------------------- Unlike the other builds from mingw-w64 up to this one, these particular win64 targetting toolchains do *not* prepend an undersocore to the symbols and follows the MSVC x64 convention. Therefore, any of the dlls and object or archive files from previous usual toolchains are incompatible with the ones created by this particular build. Versions: ---------------- binutils 2.20.51 (cvs, 2010-04-16 20:10 GMT) gcc svn revision 158444 (4.5.1 prerelease with patches) mingw-w64-crt svn revision 2228 (2010-04-15) mingw-w64-headers svn revision 2241 (2010-04-16) Files : ---------------- mingw-w64-src_20100416_experimental_sezero.tar.gz Source tarball used for creating the following binary packages: mingw-w64-bin_i686-linux_20100416_experimental_sezero.tar.gz mingw-w64-bin_i686-mingw_20100416_experimental_sezero.zip mingw-w64-bin_x86_64-linux_20100416_experimental_sezero.tar.gz mingw-w64-bin_x86_64-mingw_20100416_experimental_sezero.zip
J'ai oublié de le dire plus tôt, mais c'est sur les sources d'il y a moins d'un mois qu'est basée ma propre version de Gcc, et je peux la mettre à disposition pour les développeurs disposant d'un système 64 bits.

Est-ce que cela conviendrait à tous, sachant qu'il suffit d'extraire l'archive et de modifier la variable PATH pour en profiter :question:

17/04/2010, 18h10
ram-0000

Citation:

Envoyé par koala01

Autrement, je suis effectivement totalement d'accord avec le fait que, au début, il serait pas mal d'avoir un "kit minimum" que chaque dev utilise.

Cela permettrait aussi aux nouveaux venus dans le projet de pouvoir travailler plus vite.
Ce kit initial de démarrage devrait être référencé sur la page du projet.

Citation:

Envoyé par koala01

J'ai oublié de le dire plus tôt, mais c'est sur les sources d'il y a moins d'un mois qu'est basée ma propre version de Gcc, et je peux la mettre à disposition pour les développeurs disposant d'un système 64 bits.

Est-ce que cela conviendrait à tous, sachant qu'il suffit d'extraire l'archive et de modifier la variable PATH pour en profiter :question:

Aucun problème pour moi (au fait, cela marche sous W7 x64 ou bien il va falloir que j'installe un Linux ?)
17/04/2010, 20h46
Goten

Pour les linuxiens, un gcc 4.5 suffit? :p
17/04/2010, 21h07
dourouc05

Citation:

Envoyé par ram-0000

Aucun problème pour moi (au fait, cela marche sous W7 x64 ou bien il va falloir que j'installe un Linux ?)

Ça fonctionne nickel sur W7 x64 (c'est le GCC que j'utilise !). Déjà dispo ici (sauf s'il y a des modifications, il faut alors lui demander) : ftp://ftp-developpez.com/qt/binaires...it-multilib.7z
18/04/2010, 02h40
koala01

Citation:

Envoyé par ram-0000

Aucun problème pour moi (au fait, cela marche sous W7 x64 ou bien il va falloir que j'installe un Linux ?)

Non, il fonctionne "tout seul", ainsi que je l'ai expliqué... tu extrait l'archive, tu rajoute le sous dossier bin à la variable PATH, et ca fonctionne... Magique, hein :question:

Ceci dit, si tu souhaite profiter des possibilités d'utiliser le script de configuration à la "auto tools", un émulateur de linux comme MSYS peut s'avérer intéressant :aie:

Autrement (comprend: si tu décide d'utiliser CodeBlocks, VisualStudio ou tout autre EDI), il faudra juste veiller à ce que les fichiers de configurations propres à ton EDI soient dans un dossier séparé.

Mais tout cela fera l'objet d'une entrée dans le wiki ;)

Citation:

Envoyé par Goten

Pour les linuxiens, un gcc 4.5 suffit? :p

Oui, bien sur...

Je ne suis pas assez au fait des modifications qu'apportent les différents patches appliqués depuis la release de 4.5.0 pour te jurer qu'il n'y aura aucun problème, mais je *crois* que ce sont principalement des bugfixes, et que les différentes possibilités sont déjà implémentées dans 4.5.0 ;)

Il n'y a que si tu envisages (pour une raison ou une autre) d'effectuer la cross-compilation que je te conseille d'utiliser mingw-w64.

La raison est toute bête: je ne suis absolument pas certain qu'il y ait déjà une version 4.5.xx de mingw (original) :aie: et je sais que certains patches concernant la bibliothèque runtime (mingw) ont été appliqués dans mingw-w64 et refusés dans mingw (parce que ce sont des patches que j'ai personnellement proposés ;):P)

Citation:

Envoyé par dourouc05

Ça fonctionne nickel sur W7 x64 (c'est le GCC que j'utilise !). Déjà dispo ici (sauf s'il y a des modifications, il faut alors lui demander) : ftp://ftp-developpez.com/qt/binaires...it-multilib.7z

C'est bien celui que j'utilise...

J'envisage éventuellement de faire une "mise à jour" afin de profiter des différents patches édités, mais cela ne devrait pas vraiment porter à conséquence :aie:

Quoi qu'il en soit, si mise à jour je fais, je placerai une archive dans la partie fichier du projet :D
05/06/2010, 11h09
ram-0000

Toujours dans les outils, je suis en train de regarder/rechercher un outil de conception pour la hiérarchie de classes de Farfelue.

D'abord, UML, je ne connais pas, donc il est possible que je dise de très grosses bêtises.

Mon choix s'est arrêté sur ClassBuilder, c'est gratuit, et j'ai l'impression de comprendre ce qu'il fait :).

Petit bémol, cela ne semble fonctionner que sous Windows. Si quelqu'un a mieux ou si un consensus se dégage, je suis prêt à changer. Quitte à apprendre, autant apprendre sur le même outil. (et en plus, comme cela, j'aurai du support :aie:)
05/06/2010, 11h29
koala01

Citation:

Envoyé par ram-0000

Toujours dans les outils, je suis en train de regarder/rechercher un outil de conception pour la hiérarchie de classes de Farfelue.

D'abord, UML, je ne connais pas, donc il est possible que je dise de très grosses bêtises.

Mon choix s'est arrêté sur ClassBuilder, c'est gratuit, et j'ai l'impression de comprendre ce qu'il fait :).

Petit bémol, cela ne semble fonctionner que sous Windows. Si quelqu'un a mieux ou si un consensus se dégage, je suis prêt à changer. Quitte à apprendre, autant apprendre sur le même outil. (et en plus, comme cela, j'aurai du support :aie:)

Je pencherait de prime abord plutôt vers BoUml, qui est gratuit et disponible sous win et sous linux.

De plus, il permet de créer réellement l'ensemble des diagrammes UML, car les diagrammes de classe ne sont qu'une partie de ce que permet cette méthode.

Cela me fait d'ailleurs penser au fait qu'il serait intéressant de réfléchir aux cas d'utilisation :aie:

Enfin, et ce n'est pas rien, il dispose d'une section dédiée sur le forum :D
05/06/2010, 13h54
ram-0000

Citation:

Envoyé par koala01

Je pencherait de prime abord plutôt vers BoUml, qui est gratuit et disponible sous win et sous linux.

OK pour boUml

Citation:

Envoyé par koala01

Enfin, et ce n'est pas rien, il dispose d'une section dédiée sur le forum :D

Je vais lire de ce pas les différents tutoriel UML.