Environnement de développement C++ sour Linux

Version imprimable

12/08/2010, 09h12
moidibe

Environnement de développement C++ sour Linux

Bonjour c'est encore moi...

Voila maintenant je suis sous linux et j'ai beaucoup de mal à faire quoi que ce soit...
Je programme avec visual studio sous windows et j'ai essayé avec éclipse et netbeans. A la première installation d'éclipse et valgrind, ca marché plutot bien à part l'impossibilité de faire du pas à pas... F5, F6, F7, F8... Il n'y a pas de pas à pas...
Je l'ai désinstallé et essayé avec netbeans mais entre autres, il ne me reconnais pas math.h...
Je réinstalle éclipse, cette fois, il refuse d'installer le paquet CDT, qui permet de prendre en charge le c++.:cry:

Il n'y a pas un logiciel sous linux qui permet de compiler aussi facilement que sous windows (sans avoir besoin de passer 10 h à tout configurer, j'exagere un peu mais vous avez compris...) et qui permet d'utiliser valgrind ?
12/08/2010, 09h26
3DArchi

Salut,
Tu n'as pas encore essayer Code::block :aie:
12/08/2010, 09h34
moidibe

Merci pour ta réponse 3DArchi et pour le nouveau sujet.
Je suis en train de l'installer... On verra ce que ca va donner mais la situation ne peut que s'améliorer puisque pour le moment mon projet ne compile même pas.:aie:
12/08/2010, 10h11
moidibe

Y a du progrès ! Ca compile avec codeblock... :ccool:

Maintenant il faut juste que j'apprenne à utiliser valgrind correctement pour résoudre les problèmes.

Si vous avez sous la main quelques explications sur l'utilisation de valgrind je suis preneur.
J'ai déjà trouvé des explications en utilisant google mais il y a sans doute moyen de les compléter avec d'autres sources.:calim2:
12/08/2010, 10h46
yetimothee

Salut,
Sous linux, tu as aussi moyen d'utiliser un programme par fonction ; par exemple, gedit pour editeur, gcc / g++ comme compilateur et gdb pour debugger. Ca n'est pas forcément simple de s'y mettre, mais ça apporte néanmoins une plus grande modularité dans tes choix de programme. A mon avis, tu devrais au moins essayer, après, c'est toi qui voit ^^

Bon courage !
16/08/2010, 15h56
jblecanard

Salut

J'ai l'impression de me répéter, mais si tu codes un projet porté et compilé sur plusieurs plateformes, tu as tout intérêt à utiliser un utilitaire comme CMake. Il y a un coût d'apprentissage assez fort, mais beaucoup de temps gagné par la suite.
16/08/2010, 20h44
Flob90

@yetimothee: Sous n'importe quel plateforme, suffit d'appeler les outils un à un.

Et +1 pour jblecanard, utiliser un outil comme CMake (où autre du même genre), te permettra de générer automatiquement les Makefile (où autre si tu utilises pas make) ce qui est un gain de temps considérable, surtout si le projet est grand.
17/08/2010, 08h27
Aladore

Et j'ajouternais que le site dispose d'une excellente introduction à CMake, alors pourquoi s'en priver ? Surtout que le temps d'apprentissage de CMake n'est pas si énorme que ça quand on voit au final le temps et la "souplesse" qu'on gagne.
17/08/2010, 20h56
epsilon68

QtCreator?
17/08/2010, 22h31
AuraHxC

Pour ma part le combo : Gedit avec des plugins et une configuration des extrait de code avancé + CMake + gdb + Valgrind reste une valeur sûr.
Et en bonus un petit Mercurial (ou SVN) pour gérer mes codes sources.
18/08/2010, 09h50
white_tentacle

kdevelop ou qtcreator.

Bon, après, si c'est pour faire du gtk, c'est moins approprié :).
18/08/2010, 09h50
jblecanard

Citation:

Envoyé par AuraHxC

Et en bonus un petit Mercurial (ou SVN) pour gérer mes codes sources.

A choisir entre les deux, je conseillerai plutôt Mercurial, il est plus moderne et décentralisé. A titre personnel, je leur préfère Bazaar.
18/08/2010, 09h54
Aladore

J'entends souvent parler de Bazaar, mais quels sont ses principaux avantages ? Sinon l'avantage que je trouve à Mercurial c'est que c'est très rapide à prendre en main, et surtout on peut avoir un des dépôts gratuit sur BitBucket

Pour ceux qui veulent une introduction à Mercurial, voici un site que j'ai trouvé intéressant: HgInit
18/08/2010, 10h17
jblecanard

Mercurial, Bazaar et Git sont les trois principaux SCM décentralisés et open source (il existe des SCM commerciaux).

Tous ont leur site de prédilection pour les dépôts : Launchpad pour Bazaar, Bitbucket pour Mercurial et Github pour Git.
Tous ont fait leur preuve avec un logiciel important : Bazaar gère Ubuntu, Mercurial gère Firefox, Git gère le noyau linux.

J'aime bien Bazaar pour sa simplicité d'utilisation et surtout pour son support officiel en multiplateforme. Mercurial est aussi multiplateforme mais c'est moins mis en avant, Git ne l'est carrément pas.

Je versionne toujours systématiquement mon code source : avec un outil comme bazaar, pas besoin d'un serveur, on peut versionner localement. Il est toujours temps de verser le code sur un serveur après coup.
18/08/2010, 13h39
AuraHxC

En fait, je sais pas trop pourquoi j'ai parlé de SVN, j'avais plutôt en tête GIT.
Bazaar, je connais mais jamais utilisé sauf pour récupérer les sources de Cairo-dock. Mais tout cela n'est finalement pas trop le sujet donc reparlons plutôt d'environnement de développement (même si cela s'intègre dans un environnement de dev) ;)
18/08/2010, 14h52
Davidbrcz

Si tu débutes, un IDE peut être rassurant pour toi. Il y en a une pléthore sour linux ( CodeBlocks, Ajunta, Geany, QDevelop, Qt Creator, Kdevelopp, ...). Tu peux aussi utiliser un éditeur de texte classique (Geany, Kate, ...) et "compiler à la mano" avec des outils comme Scons,CMake ou les Makefile.

Il reste enfin les "ovnis" que sont emacs et vim.

Ce sont des éditeurs de texte sauf qu'ils sont extrêmement puissant, bien plus puissant qu'un IDE classique ou un simple éditeur de texte. Ils offrent des fonctionnalités et une possibilité de personnalisation bien au dessus de n'importe quel logiciel. Néanmoins, ils sont austères au début et demande un certain temps d'investissement avant d'être maîtrisé. Si tu comptes rester sur linux pour un bon moment, je ne peux que t'encourager à y jeter un oeil.

PS/ emacs c'est bien.
18/08/2010, 15h01
jabbounet

Citation:

Envoyé par Davidbrcz

Il reste enfin les "ovnis" que sont emacs et vim.

ovnis???

Ils sont là depuis bien plus longtemps que les autres, dinausaures/ancetres/... si tu veux mais pas ovnis, non mais :D.
18/08/2010, 15h09
Davidbrcz

Citation:

Envoyé par jabbounet

ovnis???

Ils sont là depuis bien plus longtemps que les autres, dinausaures/ancetres/... si tu veux mais pas ovnis, non mais :D.

Ce sont des ovnis car ils sont les deux seuls logiciels (à ma connaissance) qui sont ... tels qu'ils sont. Je n'arrive pas à les ranger ni dans la catégorie "éditeur de texte" ni dans la catégorie "IDE". Je range vim dans la catégorie vim et emacs dans la catégorie emacs :aie:. Bref, ils sont vieux, ils sont puissants mais ils sont uniques dans leur genre, d'où la notion "d'ovnis" .
18/08/2010, 16h21
jabbounet

Citation:

Envoyé par Davidbrcz

Ce sont des ovnis car ils sont les deux seuls logiciels (à ma connaissance) qui sont ... tels qu'ils sont. Je n'arrive pas à les ranger ni dans la catégorie "éditeur de texte" ni dans la catégorie "IDE". Je range vim dans la catégorie vim et emacs dans la catégorie emacs :aie:. Bref, ils sont vieux, ils sont puissants mais ils sont uniques dans leur genre, d'où la notion "d'ovnis" .

Personellement je considère un ovni comme un truc qui débarque un jour sans que tu sache d'ou cela vienne ni pourquoi c'est là.

Pour emacs et vi on sait exactement d'ou il viennent, et on sait à quoi ils servent, par exemple à lancer des troll :)

Note: la catégorie couteau suisse peut leur convenir aussi.
18/08/2010, 18h22
Goten

A t'arrives pas à les classer?
C'est simple.
emacs c'est la catégorie OS.

:)

me cherchez plus :p
18/08/2010, 19h01
ruste

J'ai utilisé xemacs pendant longtemps, au risque de déplaire au dieu de FSF. Son interface graphique est plus avancée que celle de emacs. Personnellement, je compilais XEmacs en mode Motif, pour avoir un look et un comportement un peu plus standard. Même si je me suis converti aux plates-formes modernes, comme netbeans, eclipse, code::blocks et autres, j'ai encore la nostalgie de ce genre de logiciel compliqué mais très modulaire. Dans le cas de XEmacs (et emacs), ses «plugins» sont programmés en lisp, un vieux langage, basé sur la récursion je crois. Donc, pas évident tout de suite, et rien pour être populaire au dernier congrès des développeurs.

En gros, je fonctionnais avec les Makefile. XEmacs permets d'exécuter les Makefiles sans quitter l'IDE. Lorsque les erreurs ou Warning sont générés lors d'une compilation, on peut cliquer sur l'erreur dans la fenêtre et XEmacs nous ouvre le fichier et la ligne en erreur. Donc, très pratique pour ceux qui ne désirent pas se lier à un standard spécifique, comme Code::Blocks. Ce dernier, que j'apprécie malgré tout beaucoup, utilise son interface propre, qui tiens lieu de Makefiles. Il demande un certains temps d'apprentissage. KDevelop de son côté est mieux standardisé, mais il faut vouloir apprendre à maîtriser les autoconf, automake, libtools & cie. NetBeans utilise son standard propre pour définir ses projets, basés en partie sur ant (donc on s'éloigne du C). Ça ne s'apprend en criant ciseau, et si pour une raison xyz le rachat d'Oracle par Sun fait disparaître NetBeans (ils sont rendus avec NetBeans, JDevelopper et BEA Workshop/Eclipse), ça sera un apprentissage vain.

KDevelop, en particulier, peut impliquer un temps d'apprentissage. Mais une fois cet apprentissage fait, je crois qu'il n'a pas tant que ça à envier à MS Visual C++. Aussi, il existe une version commerciale de KDevelop, mais je ne me souviens plus du nom.

Pour ma part, je crois que tout programmeur C++ devrait avoir été familiarisé avec le concept des Makefile et des compilateurs en ligne de commande, avant de sauter sur des outils IDE comme Code::Blocks ou Eclipse. UNIX est comme ça, il peut décourager ceux qui tentent de passer de Windows (c'est-à-dire ceux qui sont habitués de manger à la cuillère) à UNIX mais avec le temps on se rend compte que UNIX exige de savoir ce que l'on fait. Ça fini toujours par nous être utile, même en revenant à Visual C++ et Windows. Ça a surtout l'avantage de nous découpler d'un fournisseur particulier pour nous coupler d'avantage au standard. Je parle par expérience :D
18/08/2010, 21h10
jabbounet

Citation:

Envoyé par ruste

J'ai utilisé xemacs pendant longtemps, au risque de déplaire au dieu de FSF. Son interface graphique est plus avancée que celle de emacs. Personnellement, je compilais XEmacs en mode Motif, pour avoir un look et un comportement un peu plus standard. Même si je me suis converti aux plates-formes modernes, comme netbeans, eclipse, code::blocks et autres, j'ai encore la nostalgie de ce genre de logiciel compliqué mais très modulaire. Dans le cas de XEmacs (et emacs), ses «plugins» sont programmés en lisp, un vieux langage, basé sur la récursion je crois. Donc, pas évident tout de suite, et rien pour être populaire au dernier congrès des développeurs.

Xemacs est un fork d'emacs qui est apparu dans les années 90 dont le but est d'offrir une interface graphique plus élaborée et avoir une partie du code réécrite en C++. emacs quand a lui est apparu dans les années 70 d'abords comme une extension d'un autre éditeur appelé TECO, puis comme un logiciel complet au milieu des années 80.

L'aspect général de ces deux éditeurs est tres proches on pourrait dire qu'ils sont jumeaux, la plupart des modes d'emacs sont compatible avec xemacs et inversement, certains raccourcis clavier ou certaines façon de faire sont cependant différentes, les quelques fois ou j'ai utilisé xemacs j'ai été surpris par l'effet de certains raccourcis courant sous emacs qui n'etait pas associé à la même fonction.
Ces modes sont effectivement écrit en lisp. C'est un langage fonctionnel apparu en 1958, l'un des tout premier langage informatique (le second officiellement après fortran). D'ou son coté hardu par rapport à un langage récent. pourquoi utiliser le lisp pour ecrire les modes d'emacs? simplement parceque dans les années 70 il n'y avait pas autant de langage disponible que maintenant, C venait de naitre par exemple, et que lisp etait plutôt populaire au MIT à cette époque.

Citation:

En gros, je fonctionnais avec les Makefile. XEmacs permets d'exécuter les Makefiles sans quitter l'IDE. Lorsque les erreurs ou Warning sont générés lors d'une compilation, on peut cliquer sur l'erreur dans la fenêtre et XEmacs nous ouvre le fichier et la ligne en erreur. Donc, très pratique pour ceux qui ne désirent pas se lier à un standard spécifique, comme Code::Blocks. Ce dernier, que j'apprécie malgré tout beaucoup, utilise son interface propre, qui tiens lieu de Makefiles. Il demande un certains temps d'apprentissage. KDevelop de son côté est mieux standardisé, mais il faut vouloir apprendre à maîtriser les autoconf, automake, libtools & cie. NetBeans utilise son standard propre pour définir ses projets, basés en partie sur ant (donc on s'éloigne du C). Ça ne s'apprend en criant ciseau, et si pour une raison xyz le rachat d'Oracle par Sun fait disparaître NetBeans (ils sont rendus avec NetBeans, JDevelopper et BEA Workshop/Eclipse), ça sera un apprentissage vain.
KDevelop, en particulier, peut impliquer un temps d'apprentissage. Mais une fois cet apprentissage fait, je crois qu'il n'a pas tant que ça à envier à MS Visual C++. Aussi, il existe une version commerciale de KDevelop, mais je ne me souviens plus du nom.

D'apres ce que j'ai vu, Tous les éditeurs type eclispe/studio/.... lancent des lignes de commandes a un moment ou un autre pour compiler (que ce soit en appelant des equivalant de make ou directement le compilateur), en connaissant bien les fichiers de configuration de son éditeur préféré il est possible de les modifier, on peut aussi les faire apparaitre dans les logs en montant son niveau de traces, cela m'a souvent été utile pour retrouver ce que lancait l'éditeur lorsque j'avais besoin d'automatiser certains traitements par scripts, ou tout simplement faire la même chose sous emacs :).

Il est a noter aussi qu'emacs s'adapte a n'importe quel compilateur, il suffit de lui préciser par expression reguliere ou trouver les informations sur le fichier et la ligne ou se trouve l'erreur. cela s'avère tres utile quand on te demmande de travailler sur un language esothérique et propriétaire que personne ne connais.

Il encapsule aussi nativement les debugger unix. pour la gestion de configuration, CVS est géré nativement, des modes sont aussi disponible pour clearcase et svn.

Citation:

Pour ma part, je crois que tout programmeur C++ devrait avoir été familiarisé avec le concept des Makefile et des compilateurs en ligne de commande, avant de sauter sur des outils IDE comme Code::Blocks ou Eclipse. UNIX est comme ça, il peut décourager ceux qui tentent de passer de Windows (c'est-à-dire ceux qui sont habitués de manger à la cuillère) à UNIX mais avec le temps on se rend compte que UNIX exige de savoir ce que l'on fait. Ça fini toujours par nous être utile, même en revenant à Visual C++ et Windows. Ça a surtout l'avantage de nous découpler d'un fournisseur particulier pour nous coupler d'avantage au standard. Je parle par expérience :D

Surtout le concept de compilation séparée. c'est impressionnant le nombre de personne que je vois recompiler tout un projet alors qu'ils n'ont modifié qu'un seul fichier.
19/08/2010, 10h29
jblecanard

Citation:

Envoyé par jabbounet

Surtout le concept de compilation séparée. c'est impressionnant le nombre de personne que je vois recompiler tout un projet alors qu'ils n'ont modifié qu'un seul fichier.

Oui mais bon, une bonne chaîne de compilation traite ce genre de cas automatiquement.
19/08/2010, 11h36
jabbounet

Citation:

Envoyé par jblecanard

Oui mais bon, une bonne chaîne de compilation traite ce genre de cas automatiquement.

oui, encore faut-il qu'ils sachent un minimum comment marche une chaine de compilation et en particulier celle qu'ils utilisent.
Dès fois je pense que certains collègues veulent perdre du temps, mais je n'en suis pas certain.
23/08/2010, 18h54
ruste

Citation:

Envoyé par jabbounet

oui, encore faut-il qu'ils sachent un minimum comment marche une chaine de compilation et en particulier celle qu'ils utilisent.

Oui, c'est l'ABC de la compilation. Avec les outils comme Visual C++, c'est l'outil qui s'en charge. Il faut dire que dans le monde de Microsoft, tout est bien intégré à Visual Studio, ça peut suffire. J'avoue que l'ensemble est efficace. Mais, comme pour tout outil spécialisé, il ne faut pas sortir des limites imposées par l'outil, et on est limité à cet outil seulement. C'est l'histoire de Visual Studio, de MS Office et de Windows au complet... Certains savent s'assurer la fidélité de leur clientèle ;)

Mais s'il fallait que Microsoft décline, ce qui n'est pas impossible à l'ère du cloud, j'en connais plusieurs qui vont tomber avec. C'est le prix du logiciel propriétaire, la propriété est mutuelle. Une raison de plus pour apprendre à comprendre les bases d'une chaine de compilation.
24/08/2010, 06h55
3DArchi

Citation:

Envoyé par jabbounet

Dès fois je pense que certains collègues veulent perdre du temps, mais je n'en suis pas certain.

Ces outils ne sont pas non plus la panacée. Exemple typique de cas mal pris en compte : je modifie un fichier, je compile. Je souhaite revenir en arrière : donc je récupère la version antérieure avec mon outil de gestion de conf préféré (svn, clearcase, etc..). Là, la plus part des outils ne recompile pas car la date du fichier source est antérieur à celle du fichier objet ... alors que ce n'est plus le même.
Tout recompiler lorsqu'on modifie un fichier, c'est effectivement assez inefficace. Mais se fier à 100% à la chaine de compilation, ben pas tout le temps.
24/08/2010, 09h13
jabbounet

Citation:

Envoyé par 3DArchi

Ces outils ne sont pas non plus la panacée. Exemple typique de cas mal pris en compte : je modifie un fichier, je compile. Je souhaite revenir en arrière : donc je récupère la version antérieure avec mon outil de gestion de conf préféré (svn, clearcase, etc..). Là, la plus part des outils ne recompile pas car la date du fichier source est antérieur à celle du fichier objet ... alors que ce n'est plus le même.
Tout recompiler lorsqu'on modifie un fichier, c'est effectivement assez inefficace. Mais se fier à 100% à la chaine de compilation, ben pas tout le temps.

Un bon vieux touch entre le deux yeux du/des fichier(s) impliqué(s) et c'est reparti comme en 40;) ....

http://www.linux-kheops.com/doc/man/...1/touch.1.html
24/08/2010, 11h20
3DArchi

Citation:

Envoyé par jabbounet

Un bon vieux touch entre le deux yeux du/des fichier(s) impliqué(s) et c'est reparti comme en 40;) ....

http://www.linux-kheops.com/doc/man/...1/touch.1.html

A deux exceptions près : je suis pas sur *nux et le gestionnaire de conf (par expl clearcase) m'impose la date (je ne suis pas sur qu'une vue dynamique clearcase me laisse le choix dans la date).
24/08/2010, 11h29
Aleph69

Citation:

Envoyé par 3DArchi

je ne suis pas sur qu'une vue dynamique clearcase me laisse le choix dans la date.

Joli, respect! :ccool:
24/08/2010, 11h52
jblecanard

Citation:

Envoyé par Aleph69

Joli, respect! :ccool:

Pareil, complètement validé :ccool:
24/08/2010, 14h23
jabbounet

Citation:

Envoyé par 3DArchi

A deux exceptions près : je suis pas sur *nux et le gestionnaire de conf (par expl clearcase) m'impose la date (je ne suis pas sur qu'une vue dynamique clearcase me laisse le choix dans la date).

Je n'ai jamais dit que je me fiais a 100% aux chaines de compilation, sinon je n'aurais aucune idée de leur fonctionnement. Simplement, je les connais suffisamment bien pour savoir quand un build complet (qui peu prendre plusieurs heures pour certains cas) est nécessaire et quand il ne l'est pas.

Après que certains outils aient des limites, ça arrive et il faut savoir composer et faire avec.

Cependant sous windows il existe aussi des utilitaires te permettant de modifier la date de modification d'un fichier.

Ensuite si tu es sur d'autre os Vax/VMS, VxWorks, .... là je ne connais pas/plus les commandes.