Petit sondage pour les cplusplusiens

Version imprimable

26/03/2006, 09h06
Float*

Petit sondage pour les cplusplusiens

Bonjour, je suis dans le c++ depuis un an maintenant, il est temps pour moi de choisir des librairies, un compilateur et outils divers a adopter.
J'aimerais connaitre ce que vous preferez et pour quel raison.
Ce questionnaire permettrais d'avoir un apercu des tendances generale.
Payant, gratuit, portable ou pas...ce que vous preferez.

I/Quel Compilateur? pourquoi?

II/Quel librairies et pourquoi?:

1/Le GUI (IHM)
2/Gestion claviers/souris/joystick
3/audio
4/Rendu 2D
5/Rendu 3D (direct3d, opengl ou...?)
6/Video
7/Compression de donnee
8/Cryptage/decriptage
9/Gestion Fichiers (API Win32?)
10/Images (traitement ou decodage)
11/Reseaux/transfert de donnee sur internet
12/Autres librairies sympa?

III/Quels outils utile pour le develloppement?

Voila, je crois avoir tout mis ;-)
Vous etes pas oblige de repondre partout, merci bien!

La selection des Librairies et Outils du forum

[Librairies Generaliste]
boost
Loki
apr
STLsoft
SDL
Qt

[IHM]
Gtkmm
wxWidgets

[Audio]
fmod
OpenAL
ASIO

[Rendu Graphique]
OpenGL

[Compression de donnee]
zlib

[Criptage/Decriptage]
Openssl

[Image]
libpng
libjpeg
Devil

[NetWork]
ACE

[Calculs Haute Precision]
Blitz++

[IDE]
vim
codeblocks
SciTE

[Outils utils]
gdb/ddd/insight (Debuger)
strace (voir appels systeme)
pmap (voir la consommation mémoire de chaque lib )
cxxtest
STLFilt (STL Error Message Decryptor for C++)
Doxygen (gérer une doc à partir des sources )
26/03/2006, 10h04
Invité

Re: Petit sondage pour les cplusplusiens

Citation:

I/Quel Compilateur? pourquoi?

GCC, parce que c'est un des compilateur C++ les plus respectueux du standard que je connaisse. Parce qu'il est libre, open source et gratuit.

Citation:

II/Quel librairies et pourquoi?:

1/Le GUI (IHM)

wxWidgets, a la fois clean et portable. Cette librairie respecte le theme par defaut des differents environnement dans lequel elle est utilisee (les controles windows ressemblent a tout les autre de windows, sous linux ca utilise le theme courant gtk, etc)

Citation:

3/audio

fmod - http://www.fmod.org/
openal - http://www.openal.org/

Citation:

5/Rendu 3D (direct3d, opengl ou...?)

opengl, encore une fois pour la portabilite, et parce que directX existe pas sur l'os que j'utilise (linux)

Citation:

6/Video

7/Compression de donnee
zlib

Citation:

8/Cryptage/decriptage

openssl - http://www.openssl.org/

Citation:

9/Gestion Fichiers (API Win32?)

Les fstream, ca fait des merveilles ;)

Citation:

12/Autres librairies sympa?

boost - http://www.boost.org/
apr - http://apr.apache.org/

Citation:

III/Quels outils utile pour le develloppement?

Personnellement, j'utilise vim, gdb, gcc et valgrind. Vim est un excellent editeur pour les programmeurs, gdb (ou un de ses front-end, comme ddd ou insight) permettent de debugger, gcc a compiler, et valgrind pour decouvrir des problemes dans mes programmes comme les memory leak ou les lectures invalides en memoire.

Citation:

Voila, je crois avoir tout mis ;-)
Vous etes pas oblige de repondre partout, merci bien!

No problemo!
26/03/2006, 10h11
MatRem
Personnelement j'essaye d'opter pour les solutions libres, et multiplateforme le plus possible et en tout cas toujours gratuite...

La question n'y est pas mais j'y répondrais quand même :P, je développe (en tout cas pour commencer mes projets) sous linux. Je trouve que c'est une plateforme vraiment trés pratique pour le développement (console, outils divers, ...).

I) ------ Compilateur ------
g++, depuis assez longtemps déjà:
- - il est libre (projet GNU)
  - fourni avec les sytème linux
  - plutôt performant.
Pour les projets de plus d'un fichier source :lol:, j'utilise des makefile (et l'utilitaire make).

II) ------ Bibliothèques ------

1) --- IHM ---
qt me semble trés puissant et assez facile d'utilisation, cependant il n'est pas totalement libre. Par contre il fonctionne sous linux/windows. Il est un tout petit peu lourd par contre (au niveau de la taille et de l'utilsation).
wxWIdget est bien, mais j'aime un peu moins son API à base de macro.
Pour travailler plus bas niveau est exclusivement sur un système possèdant un serveur X, la programmation XWindows est intéressante. La c'est beaucoup moins agréable mais tu comprends mieux comment fonctionne ton système.

2) --- Gestion du clavier souris ---
Ça, en général, ça va avec le gestionnaire d'IHM.

3) -- Audio ---
J'ai utilisé fmod, qui me paraissait excellent à l'époque, mais ça fait un bail que j'ai pas touché à l'audio.

4)5) ---Rendu 2D et 3D ---
A ce niveau là j'utilise OpenGL, qui me semble trés puissant (utilisation du hardware si tu possède des pilotes adéquates). Il est aussit multiplateforme: nombreuses implémentations, dont certaines libres (MESA par esemple).

7) --- Compression ---
Zlib est trés utilisé, multiplateforme et son algo de compression est bon.

10) -- Images ---
libpng, libjpeg, pour lire les png et les jpg :).

III) ------ outils ------
Un bon éditeur de texte qui te fait la colaration syntaxique et la complétion automatique.
J'en ai pas trouvé de léger et simple. J'utilise kwrite pour le moment.
26/03/2006, 12h07
loufoque

gtkmm pour les GUIs
SDL pour audio, clavier/etc. et accès à OpenGL (utilisé en 2D comme en 3D)

Pour le réseau je préfère utiliser les sockets posix mais j'ai aussi fait quelques trucs avec asio.
26/03/2006, 12h24
swirtel

ne pas oublier gdb et ddd ou insight pour le debug
strace pour voir les appels systèmes
pmap pour voir la consommation mémoire de chaque lib

y en a encore des tonnes
26/03/2006, 13h19
KangOl

SciTE et Code::Blocks pour les éditeurs
26/03/2006, 15h23
Luc Hermitte

I- Compilo
Celui de la plateforme sur laquelle je tourne, de préférence le plus récent, ce qui n'est pas toujours possible sur des projets qui ont plusieurs années.
Quand je le peux, j'essaie de pouvoir compiler avec les compilos les plus pertinents de la plateforme. Genre sous windows, VC (2005) et GCC 4.x.
Le premier car il commence à avoir un bon respect du standard et que le résultat produit est tout de même plus efficace que le résultat produit par GCC. Sans parler des temps de compilation.

II- bilbiothèques
1- IHM.
Je n'en fais pas, et c'est un des domaines qui ne m'intéresse vraiment pas.
Ceci dit, je suis d'un oeil distant Adam et Eve (de chez Adobe) qui me semblent véhiculer des idées intéressantes. Et je ne doute pas qu'un jour je doive me résigner à tester QT -- je n'aime pas trop certains de leurs choix de design, bien qu'ils restent moins pires que d'autres.

9- Fichiers
La lib standard me suffit pour beaucoup de choses.

11- Réseau
Au taf' j'utilise ACE dont j'aime assez le design. C'est lourd certes.
Par contre réseaux et multi-tâche sont gérés main dans la main ce qui est fort appréciable.
NB: C'est portable (en prenant compte de pas mal d'archis "exotiques") et impose des contraintes statiques qui limitent les risques d'erreurs stupides que le café du matin ne suffit pas à éviter.

12- Autres libs
- boost. Définitivement. C'est un collectif de bibliothèques qui comblent certains manques de la SL.
- Loki quelques petits trucs sympas dedans (typelist, factory (que j'ai un peu réaménagé), static_assert, ...)
- STLsoft des trucs qui méritent examinations sont dedans -- je viens d'ailleurs de commencer la lecture de Imperfect C++ de Matthew Wilson, le mainteneur de STLsoft
- Divers trucs que j'avais découvert sur le feu C/C++ Users Journal (aka cuj) comme SMART_ASSERT, ENFORCE, ...
- Blitz++ pour les calculs numériques haute perf (bien que boost.uBLAS semble vouloir prendre le relai en la matière)
- d'autres que j'ai dû oublier.

III- outils utiles
- Vim parce que je suis un geek modal qui le vaut bien. Avec l'ensemble des plugins que j'ai dont plus de la moitié que je maintiens, je me passe sans difficultés d'un IDE. Les seuls manques que j'ai aujourd'hui sont: - une complétion C++ aussi intelligente que celle fournie par VC++, un débuggueur ergonomique, stable et rapide. (Sous solaris, ddd + dbx, c'est vraiment pas top quand on a gouté au débuggueur de VC)
- STLfilt pour rendre les messages d'erreurs liés à la SL plus intelligibles
- aap/bjam/scons/make pour gérer les chaines de compilation
- Quelque chose pour les TUs. J'utilise CxxTest et j'en suis content -- je n'ai pas testé les autres solutions.
- SVN/CVS pour la gestion des sources.
- L'ensemble des outils du monde *nix que sont find, grep, sed, perl, xargs, ... pour des traitements devant être réalisés sur les fichiers source
- Doxygen pour gérer une doc à partir des sources
- Un outil UML peut s'avérer très utile. Je n'ai pas encore trouvé mon bonheur à la matière. J'ai testé une version de rose de 2001 (ou 3?) et c'est vraiment tout pourri (mal programmé, non ergonomique) pour les diagrammes de séquences (les seuls dont j'ai vraiment besoin). Là, j'envisage à demander Visio qui devrait me suffir pour maintenir mes petits dessins.
26/03/2006, 16h56
Matthieu Brucher

Re: Petit sondage pour les cplusplusiens

Citation:

Envoyé par Float*

I/Quel Compilateur? pourquoi?

VS.NET 2003 sous Windows et GCC 4 sous Linux - mais je vais passer bientôt à VS 2005 si les échos sont bons -

Citation:

II/Quel librairies et pourquoi?:
1/Le GUI (IHM)

Qt4, parce que portable et sous licence GPL

Citation:

2/Gestion claviers/souris/joystick

Qt4, sauf qu'il n'y a pas le joystick
Pour les jeux futurs, peut-être SDL

Citation:

3/audio

Le standard ASIO sous Windows quand je programme pour du traitement audio temps réel, mais c'est rare en ce moment.
Une autre librairie libre style SDLpour les jeux, je pense

Citation:

4/Rendu 2D

Le moteur des IHMs

Citation:

5/Rendu 3D (direct3d, opengl ou...?)

OpenGL

Citation:

6/Video

Pas besoin

Citation:

7/Compression de donnee

Si j'ai besoin, zlib

Citation:

8/Cryptage/decriptage

Pas besoin

Citation:

9/Gestion Fichiers (API Win32?)

fstream :) si XML, le parseur de Qt4

Citation:

10/Images (traitement ou decodage)

libpng et Qt4

Citation:

11/Reseaux/transfert de donnee sur internet

Qt4 :D

Citation:

12/Autres librairies sympa?

Comme pour les autres, Boost :D

Citation:

III/Quels outils utile pour le developpement?

SVN/CVS pour le contrôle des sources
Doxygen pour générer la doc
autotools sous Linux
Umbrello s'il y a de l'UML dans le tas
26/03/2006, 19h37
Elendil_BzH

Comme la plupart, j'essaye de privilégier au maximum les outils libres et portables : g++, Qt, boost, OpenGL, etc.

AMHA, la portabilité est un critère de qualité logiciel et c'est ce que certains de nos profs nous apprennent, privilégier les outils portables plutôt que les solutions propriétaires.

Du côté des outils de développement :
- Eclipse CDT mais pas encore au point comparé à JDT (outils pour Java).
- Code::blocks a l'air sympa mais sous linux y'a encore du boulot.

Pour les outils UML, j'utilise surtout Poseidon. Pas libre mais gratuit dans sa version communautaire. Le problème c'est que dans cette version, seul Java est supporté. Pour C++, il faut la version Pro. Eclipse Omondo est pas mal aussi mais je ne l'ai utilisé que pour du Java. Pas convaincu par Umbrello.

Citation:

Ceci dit, je suis d'un oeil distant Adam et Eve (de chez Adobe) qui me semblent véhiculer des idées intéressantes. Et je ne doute pas qu'un jour je doive me résigner à tester QT -- je n'aime pas trop certains de leurs choix de design, bien qu'ils restent moins pires que d'autres.

Tu pourrais être plus précis sur les choix de design de trolltech stp ? Je suis en train de regarder ce qui se fait du côté des gui pour en implémenter une avec OpenGL. Et autant partir sur de bonnes bases plutôt que de faire des erreurs de conception dès le début.
26/03/2006, 21h29
Luc Hermitte

Citation:

Envoyé par Elendil_BzH

Citation:

Ceci dit, je suis d'un oeil distant Adam et Eve (de chez Adobe) qui me semblent véhiculer des idées intéressantes. Et je ne doute pas qu'un jour je doive me résigner à tester QT -- je n'aime pas trop certains de leurs choix de design, bien qu'ils restent moins pires que d'autres.

Tu pourrais être plus précis sur les choix de design de trolltech stp ? Je suis en train de regarder ce qui se fait du côté des gui pour en implémenter une avec OpenGL. Et autant partir sur de bonnes bases plutôt que de faire des erreurs de conception dès le début.

Je ne suis pas convaincu par leur choix du COW pour pallier à l'absence, native, de sémantique de déplacement en C++ -- du moins, c'est ainsi que je le ressens. Je trouve également peu pratique de devoir reposer sur une autre famille d'algorithmes et de containers alternatifs à ceux standard. Je trouve qu'il n'y a rien de tel que de devoir mélanger des styles différents pour commettre des bourdes d'inattention. Je ne compte pas priviliéger celui de QT vu qu'il y a quantités d'autres développements dans lesquels il n'entre pas dans l'équation.

J'aurais bien aimé voir les raisons qui les ont poussés à prendre cette route. Rien de ce que j'ai vu ne m'a convaincu pour l'instant. Bref, je suis sceptique. D'autant que l'on peut faire des trucs très propres avec une approche STL-isante (cf Adam et Eve)
26/03/2006, 22h25
Gnux

Bonjour

Citation:

Envoyé par Luc Hermitte

Le premier car il commence à avoir un bon respect du standard et que le résultat produit est tout de même plus efficace que le résultat produit par GCC. Sans parler des temps de compilation.

Tu peux préciser stp en quoi le resultat de gcc est moins efficace que VC? Je n'ai jamais utilisé le second (je travaille essentiellement sous *nix donc en général j'utilise le gnu compilateur)

Citation:

Envoyé par Luc Hermitte

Vim parce que je suis un geek modal qui le vaut bien.

+1 :mouarf:
Et aussi parce que je n'ai jamais rien compris à Emacs et que j'ai toujours trouvé que :wq ct plus rapide à taper que C-x C-s
Je n'utilise pas d'IDE (je devrais?)...
26/03/2006, 23h37
Matthieu Brucher

Citation:

Envoyé par Luc Hermitte

Je ne suis pas convaincu par leur choix du COW pour pallier à l'absence, native, de sémantique de déplacement en C++ -- du moins, c'est ainsi que je le ressens. Je trouve également peu pratique de devoir reposer sur une autre famille d'algorithmes et de containers alternatifs à ceux standard. Je trouve qu'il n'y a rien de tel que de devoir mélanger des styles différents pour commettre des bourdes d'inattention. Je ne compte pas priviliéger celui de QT vu qu'il y a quantités d'autres développements dans lesquels il n'entre pas dans l'équation.

J'aurais bien aimé voir les raisons qui les ont poussés à prendre cette route. Rien de ce que j'ai vu ne m'a convaincu pour l'instant. Bref, je suis sceptique. D'autant que l'on peut faire des trucs très propres avec une approche STL-isante (cf Adam et Eve)

C'est sûr que le COW, ils auraient pu éviter, surtout qu'ils ont des strings partout et tout est d'office multi-thread :( donc beaucoup d'appels à des qt_augment_atomic et autres :( -
27/03/2006, 01h13
loufoque

Citation:

Rien de ce que j'ai vu ne m'a convaincu pour l'instant. Bref, je suis sceptique.

T'as regardé gtkmm ?
27/03/2006, 01h34
Luc Hermitte

@gnux. GCC sous windows n'optimise pas aussi bien que VC. On rajoute à cela des temps de compilation plus longs (et c'est perceptible), un non support de wchar_t et de tout l'aspect unicode qui en découle.
Maintenant, il faudrait voir avec la nouvelle version de GCC dont le "moteur" a été repris.

@loufoque. Je faisais en fait allusion à la "littérature" QT. Comme je l'avais dit plus haut, les IHMs ne sont pas un domaine qui me passionne et m'attire. Si mes souvenirs sont bons, GTKmm a un point commun non négligeable avec The Gimp que je n'avas pas trouvé fluide (il y a 5-6 ans sur un P133 sous w95). De fait, ce n'est pas une bibliothèque en haut de ma liste de choix -- pour le jour où un choix devrait se faire. Durant ce temps des choses ont pu changer.
27/03/2006, 09h06
Float*

Merci pour vos reponse!
ya tellment de trucs que je sais pas ou commencer.
je pense me pencher sur Boost
J'ai edite le message d'origine, histoire de tout rassembler pour que ce soit plus visible. (j'ai d'ailleurs passe un moment a rentrouver les liens)
Et le compilo de Borland, personne ne le cite? vous l'aimez pas?
Pour la lib d'image, je m'attendais a voir Devil, mais je l'ai ajoute.

N'hesitez pas a citer d'autres libs/outils qui valent le coup, je les ajoute par la suite la haut ;-)

Et sinon, personne connais une lib portable pour gerer les threads?
27/03/2006, 09h12
Luc Hermitte

Citation:

Envoyé par Float*

a- Et le compilo de Borland, personne ne le cite? vous l'aimez pas?

b- Et sinon, personne connais une lib portable pour gerer les threads?

a- Je ne doute pas qu'il y a quantité de gens qui s'en servent. Leur compilo ne me parait pas tip top, j'aime moyennement la VCL et je fais pas d'IHM (donc j'ai peu d'intérêt pour le côté RAD (qui a une excellente réputation) de l'outil), et Borland veut se séparer de sa branche compilateurs.

b- Des solutions ont déjà été citées. ACE (la rolls), boost (le challenger), Loki (l'expérience), QT, wxWidgets, ... pour les solutions C++. pthreads pour les unixoides.
27/03/2006, 09h22
Matthieu Brucher

Citation:

Envoyé par Luc Hermitte

@gnux. GCC sous windows n'optimise pas aussi bien que VC. On rajoute à cela des temps de compilation plus longs (et c'est perceptible), un non support de wchar_t et de tout l'aspect unicode qui en découle.
Maintenant, il faudrait voir avec la nouvelle version de GCC dont le "moteur" a été repris.

@loufoque. Je faisais en fait allusion à la "littérature" QT. Comme je l'avais dit plus haut, les IHMs ne sont pas un domaine qui me passionne et m'attire. Si mes souvenirs sont bons, GTKmm a un point commun non négligeable avec The Gimp que je n'avas pas trouvé fluide (il y a 5-6 ans sur un P133 sous w95). De fait, ce n'est pas une bibliothèque en haut de ma liste de choix -- pour le jour où un choix devrait se faire. Durant ce temps des choses ont pu changer.

Clairement, GCC4 est largement plus lent pour compiler mes programmes au boulot que mon vieux VS 2003, c'est très sensible - et GCC est presque aussi rapide sur un P4 2.8 qu'un VS sur un Celeron 800... -
GTK est dérivé de the Gimp, non ? J'aime pas trop GTK, c'est pas si beau que ça et c'est pas objet non plus :D
27/03/2006, 09h22
Float*

Donc pour resumer Visual Studio pour Windows, GCC pour linux, ca marche.
ok pour les threads, merci =)

En ce qui concerne la gestion de fichiers, les fstream c'est cool, mais ca permet pas d'effacer un fichier, je cherche un moyen portable de le faire, mais ca doit pas etre possible...
27/03/2006, 09h35
Jean-Marc.Bourguet

Re: Petit sondage pour les cplusplusiens

Je vais repondre dans mon contexte professionnel.

Citation:

Envoyé par Float*

I/Quel Compilateur?

Sun CC, HP aCC, IBM xlC, GNU gcc.

Citation:

pourquoi?

Le choix n'a pas ete fait par moi (et a ete fait avant que j'arrive dans la boite). Le choix de la version et des patchs est fait par un service qui s'amuse a valider les compilateurs.

Citation:

1/Le GUI (IHM)

Une lib a nous cachant le toolkit de base (Motif et QT); il y a une certaine volonte de se passer de cette lib et d'utiliser directement QT mais ca pose des problemes (en particulier nous avons un langage d'extension et l'interoperatibilite avec ce langage d'extension et la possibilite de rejouer des executions est beaucoup plus facile quand on utilise notre couche).

Citation:

2/Gestion claviers/souris/joystick

Via le GUI.

Citation:

3/audio

Pas utilise.

Citation:

4/Rendu 2D

Via le GUI.

Citation:

5/Rendu 3D (direct3d, opengl ou...?)

Pas utilise. On investigue OpenGL mais il y a un probleme de savoir si faire du rendu 3D fournit un service reel ou est simplement un gadget.

Citation:

6/Video

Pas utilise.

[quote]7/Compression de donnee[/quote[
zlib

Citation:

8/Cryptage/decriptage

Pas utilise a ma connaissance.

Citation:

9/Gestion Fichiers (API Win32?)

A notre niveau, IOStream. Mais on a un DB qui utilise l'API systeme.

Citation:

10/Images (traitement ou decodage)
11/Reseaux/transfert de donnee sur internet

Pas utilise.

Citation:

12/Autres librairies sympa?

Un certain nombre de machins a nous.

Citation:

III/Quels outils utile pour le develloppement?

Une couche a nous au dessus de CVS. Je regrette le projet ou nous utilisions clearcase.

Un systeme de gestion de problemes a nous. Il est planifie de passe a quelque chose de commercial.

emacs (je l'ai utilise la premiere fois sur un PDP-10... cela fait bien trop longtemps pour que je change).

Une tonne de petits scripts (ksh, perl, lisp emacs) a moi.
27/03/2006, 10h18
loufoque

Citation:

Envoyé par Luc Hermitte

@gnux. GCC sous windows n'optimise pas aussi bien que VC.

Possible.

Citation:

Envoyé par Luc Hermitte

On rajoute à cela des temps de compilation plus longs (et c'est perceptible)

Cela n'est pas le but de gcc de compiler rapidement.
Un projet C++ n'a pas besoin d'être recompilé en entier à chaque modification de toutes façons, ce n'est donc pas un problème.

Citation:

Envoyé par Luc Hermitte

un non support de wchar_t

wchar_t est un entier sur 16 ou 32 bits (selon les plate-formes que j'ai testées).
Dans ce sens là, ça fonctionne.

Citation:

Envoyé par Luc Hermitte

et de tout l'aspect unicode qui en découle.

wchar_t n'a rien à voir avec Unicode. Du moins pas d'après la norme.
Il y a de toutes façons des manières plus pertinentes de gérer l'Unicode qu'avec l'approche de l'API Win32.

Citation:

Envoyé par Luc Hermitte

Maintenant, il faudrait voir avec la nouvelle version de GCC dont le "moteur" a été repris.

En effet, gcc 4.1.x introduit de nouvelles optimisations.

Citation:

Envoyé par Luc Hermitte

De fait, ce n'est pas une bibliothèque en haut de ma liste de choix.

C'est pourtant la mieux du point de vue du développeur, si tu veux mon avis.

Citation:

Envoyé par Miles

Clairement, GCC4 est largement plus lent pour compiler mes programmes au boulot que mon vieux VS 2003, c'est très sensible - et GCC est presque aussi rapide sur un P4 2.8 qu'un VS sur un Celeron 800... -

Il doit s'agir de gcc 4.0.x.
Essayer avec gcc 4.1.x pourrait être intéressant.
De plus, quand on utilise gcc, il faut explicitement indiquer tout un tas d'optimisations.
Pour affirmer des différences de performance aussi gros, il faudrait fournir le code incriminé et indiquer comment cela a été compilé.

Citation:

Envoyé par Miles

GTK est dérivé de the Gimp, non ?

À l'origine GTK a été créé pour Gimp, mais ça a sacrément évolué depuis.

Citation:

Envoyé par Miles

J'aime pas trop GTK, c'est pas si beau que ça

Question de goût.
C'est néanmoins très populaire sous linux, autant chez les développeurs que les utilisateurs.

Citation:

Envoyé par Miles

et c'est pas objet non plus :D

C'est une blague ?
GTK a recréé tout un système pour pouvoir faire de la programmation objet en C...
Et de toutes façons en C++ on a GTKmm, un wrapper de GTK en C++ moderne. (voir ses fonctionnalités)

Citation:

Envoyé par Float*

En ce qui concerne la gestion de fichiers, les fstream c'est cool, mais ca permet pas d'effacer un fichier, je cherche un moyen portable de le faire, mais ca doit pas etre possible...

Avec boost par exemple.
27/03/2006, 10h27
Matthieu Brucher

Citation:

Envoyé par loufoque

Citation:

Envoyé par Miles

Clairement, GCC4 est largement plus lent pour compiler mes programmes au boulot que mon vieux VS 2003, c'est très sensible - et GCC est presque aussi rapide sur un P4 2.8 qu'un VS sur un Celeron 800... -

Il doit s'agir de gcc 4.0.x.
Essayer avec gcc 4.1.x pourrait être intéressant.
De plus, quand on utilise gcc, il faut explicitement indiquer tout un tas d'optimisations.
Pour affirmer des différences de performance aussi gros, il faudrait fournir le code incriminé et indiquer comment cela a été compilé.

Oui, c'est 4.0, J'ai pas encore vu de 4.1 sur Debian testing. Je lui indique des optimisations à faire, 03 et mon architecture.

Citation:

Citation:

Envoyé par Miles

GTK est dérivé de the Gimp, non ?

À l'origine GTK a été créé pour Gimp, mais ça a sacrément évolué depuis.

µHeureusement !

Citation:

Citation:

Envoyé par Miles

J'aime pas trop GTK, c'est pas si beau que ça

Question de goût.
C'est néanmoins très populaire sous linux, autant chez les développeurs que les utilisateurs.

Surtout parce qu'avant, KDE utilisait Qt qui n'était pas libre, d'où la création de GNOME et du haro sur KDE !

Citation:

Citation:

Envoyé par Miles

et c'est pas objet non plus :D

C'est une blague ?
GTK a recréé tout un système pour pouvoir faire de la programmation objet en C...
Et de toutes façons en C++ on a GTKmm, un wrapper de GTK en C++ moderne. (voir ses fonctionnalités)

Oui, c'est bien un wrapper sur du C, j'aime pas.
27/03/2006, 10h31
loufoque

Concretement, ça change rien, que ce soit un wrapper ou pas.
27/03/2006, 11h03
Aurelien.Regat-Barrel

Citation:

Envoyé par Float*

En ce qui concerne la gestion de fichiers, les fstream c'est cool, mais ca permet pas d'effacer un fichier, je cherche un moyen portable de le faire, mais ca doit pas etre possible...

y'a remove() de <cstdio>.
27/03/2006, 11h47
Matthieu Brucher

Citation:

Envoyé par loufoque

Concretement, ça change rien, que ce soit un wrapper ou pas.

Si, malheureusement, il y a un appel entre :(
27/03/2006, 23h28
Luc Hermitte

Citation:

Envoyé par loufoque

Citation:

Envoyé par Luc Hermitte

On rajoute à cela des temps de compilation plus longs (et c'est perceptible)

Cela n'est pas le but de gcc de compiler rapidement.
Un projet C++ n'a pas besoin d'être recompilé en entier à chaque modification de toutes façons, ce n'est donc pas un problème.

Certes. Mais il en reste pas moins que c'est très pénible de devoir monopoliser mon pauvre PC personnel plus de 12h pour recompiler boost.

Citation:

Envoyé par loufoque

Citation:

Envoyé par Luc Hermitte

un non support de wchar_t

wchar_t est un entier sur 16 ou 32 bits (selon les plate-formes que j'ai testées).
Dans ce sens là, ça fonctionne.

Pour être plus précis, ce sont tous les wstreams qui sont déficients avec GCC sous windows ce qui impacte sur l'unicode.

Citation:

Envoyé par loufoque

Citation:

Envoyé par Luc Hermitte

et de tout l'aspect unicode qui en découle.

wchar_t n'a rien à voir avec Unicode. Du moins pas d'après la norme.
Il y a de toutes façons des manières plus pertinentes de gérer l'Unicode qu'avec l'approche de l'API Win32.

Je faisais uniquement allusion aux limitations de GCC (cygwin de sûr, minGW aussi il me semble) sous windows.

Citation:

Envoyé par loufoque

Citation:

Envoyé par Luc Hermitte

De fait, ce n'est pas une bibliothèque (GTKmm) en haut de ma liste de choix.

C'est pourtant la mieux du point de vue du développeur, si tu veux mon avis.

OK. Merci pour l'info. J'y jeterai un coup d'oeil à l'occasion.
28/03/2006, 01h19
JolyLoic

Citation:

Envoyé par loufoque

Citation:

Envoyé par Luc Hermitte

On rajoute à cela des temps de compilation plus longs (et c'est perceptible)

Cela n'est pas le but de gcc de compiler rapidement.
Un projet C++ n'a pas besoin d'être recompilé en entier à chaque modification de toutes façons, ce n'est donc pas un problème.

Il m'est arrivé avec du metaprogramming d'avoir besoin d'1/4 d'heure pour compiler un seul .cpp avec VC++. Je n'ose imaginer ce que ça aurait donné avec gcc. Et même si je suis d'accord pour dire que le premier facteur de gain en temps de compilation se joue avec une bonne organisation du code, il y a des moments où l'on est obligé de faire évoluer une interface, et le peu que j'ai essayé gcc (3.x) sous windows, c'était très pénible.

D'un autre côté, j'ai un peu touché à du C#, ou sans rien faire de particulier, un gros code est compilé de manière quasi intantanée, et je peux dire que ça change la façon de programmer.
28/03/2006, 10h24
Aurelien.Regat-Barrel

J'avais eu cette discution avec des programmeurs Delphi qui avaient utilisés C++. J'avais trouvé l'argument du temps de compilation bidon. Mais d'après leurs dires c'est un facteur important de productivité. J'en avait conclu que tant qu'on y avait pas goûté on pouvait s'en passer, du coup j'ai jamais touché à Delphi :lol: