Discussion :

[Bouteille]

Bonjour,

Je suis en charge d'adapter plusieurs algorithmes developpés dans un langage haut niveau (R pour ceux qui connaissent) vers du C++ et de pouvoir y associer une interface graphique qui sera générée grâce à QT.

Du point de vue du C/C++ pur je pense pouvoir m'en sortir, les algos sont maison donc la comprehension est ok. Je travaille sous linux mais il serait preferable que le programme final conserve une portabilité vers windows/mac.

Cependant je vais avoir besoin de structures telles que des tables de hachage ou d'algos de tri, et surtout un gestionnaire de threads.

Je me suis un petit peu renseigné et il existe des librairies qui proposent ce genre de choses, au debut je ne connaissais que Boost (de nom) mais apres quelques recherches j'ai vu que Glib ou encore STL pouvaient etre des candidats de choix.

J'aurais aimé avoir votre avis sur la question quant a la facilité d'utilisation des differentes librairies, leur portabilité et le nombre d'outils disponibles...

Merci de votre aide, je peux bien sur apporter des details quant au programme mais je suis encore en phase d'etude de faisabilité alors tout n'est pas encore clair.

Cdlt, Romain.

[JolyLoic]

STL, il n'y a pas plus portable, puisque c'est la bibliothèque standard du langage. Par défaut, elle ne contient pas de table de hash, mais des map (à base d'arbre red-black, parfois plus rapide qu'une table de hash, parfois pas), et les versions futures (déjà disponibles sur pas mal de compilateur, parfois dans le namespace std::tr1) en contiennent une sous le nom de unordered_map.

Pour le tri, elle défini aussi std::sort.

Pour les threads, si tu veux les gérer manuellement, boost::thread est effectivement très bien. Maintenant, si tu veux faire de la programmation parallèle, des alternatives intéressantes existent, comme par exemple TBB.

[Steph_ng8]

Salut.

Qt possède également ses propres implémentations pour les éléments qui t'intéressent.
Après, il n'y a pas que du bon dans Qt…
Mais au moins, vu que c'est la bibliothèque qui sera utilisée pour l'interface graphique, ça permettra d'éviter de multiplier les bibliothèques externes, et donc les dépendances, si vous ne voulez/pouvez pas utiliser la STL.

[jblecanard]

Salut

Sans rentrer dans les détails :
- Glib est portable mais c'est GNU, j'aime GNU mais je me méfierai quant à une vraie portabilité. En particulier en ce qui concerne l'efficacité de la gestion des threads.
- La STL ? C'est bien mais...
- Boost est là pour étendre la STL et pas pour la remplacer, en offrant des fonctionnalités supplémentaires.

Donc je dirais : STL + Boost pour ce que STL n'a pas. Mais c'est un avis formulé rapidement "comme ça".

[3DArchi]

STL+Boost serait mon premier à priori aussi.
Cependant, selon le design et pour ne pas lutter contre le framework, je chercherais aussi à tirer parti de ce que propose Qt. Par exemple, entre Boost.Thread et QThread, cela devrait dépendre de l'adhérence de l'architecture du logiciel avec Qt.

[guillaume07]

au passage y a RCPP qui est nice