Bonjour à tous
 
je fais du dev depuis plus de 10 ans sous Visual c++ et donc windows. Or je risque de devoir passer à Linux toujours pour du c++...  
 
existe t'il l'equivalent d'un visual c++ sous linux ? qd je dis équivalent, c'est dans le sens un environnement de dev intégré qui est majoritairement utilisé par les developpeurs sous linux (un peu comme visual studio l'est pour le dev c++ sous windows)...
 
autre petite question : qd une appli plante sous windows, il y a le Drwatson pour trouver l'erreur... y'a la meme chose sous linux ?
 
 
merci de votre aide
 

Eclipse est assez complet, mais prévu pour java à l'origine, il faut lui adjoindre un plugin C++. Il est assez lent (écrit en java) et plante de temps en temps. De plus, il n'est pas super intuitif pour certaines choses. Malgré tout cela, c'est un très bon environnement de développement, avec un mode debug très puissant.
 
Il y a aussi kdevelop, mais je ne le connais pas du tout.
 
Pour debugguer les applications, tu peux utiliser kdbg, j'ai découvert ça récemment, et c'est plutot bien fait.
 
Sinon, vi + gdb.
 
 
Quand une application plante sous linux, celle-ci peut générer un fichier coredump qui est un état de la mémoire au moment du plantage. Avec ce fichier et gdb, tu peux retrouver l'endroit où ça a planté. Par contre, tous les systèmes ne génèrent pas de coredump (ca prend de la place sur disque), je ne sais pas comment on active/désactive l'option.

 
Il y a mieux que DrWatson (selon moi) : les coredump.
En gros, sous Unix, lorsqu'une application plante, une image mémoire est écrite dans un fichier "core", sur lequel on peut passer pour voir où la fonction a planté. Et si le programme est compilé en mode debug, tu as également accès au contenu de toutes les variables au moment du plantage.

merci à vous, ca me fournit des pistes pour orienter mes recherches  

euh wof triple wof. Les core ça pue: t'as une image une fois que le truc à planté ... quand tu débug, c'est pas super pratique plutôt que de faire un run dans ton debugger (nemiver !).
Et en prod, à part remplir les disques, ça ne sert pas vraiment.
 
ulimit -c 0

code::blocks existe sous linux aussi, sinon xemacs ...

un IDE sous linux ?
 
=> Xemacs

xemas c'est hasbeen

 
Yup, c'est moins pratique qu'un run dans un debugger quand t'es au courant d'un bug, mais c'est pas toujours le cas. Quand tu lances des batteries de tests la nuit et que tu reviens le matin avec un coredump tout chaud qui t'attend, t'es plutôt content de ne pas avoir à éplucher les logs et de tenter de reproduire le bug, c'est pas mal de temps de gagné.
 
Pour l'environnement de prod évidemment, pas de coredump, pour les raisons que tu évoques.

+1 c'est vrai que xemacs c'est hasbeen
 
par contre code::blocks est excellent
il y a aussi SharpDevelop qui ressemble le plus à visual studio
j'ai jamais testé sous linux mais il y a peut être moyen de le compiler (projet open source)
 

J'ai vu qu'il y avait un netbeans C++ aussi ( http://www.netbeans.org/features/cpp/index.html ).  
Je ne sais pas ce qu'il vaut. Si c'est comme la version Java c'est très bien, mais lent à mourir par contre.

http://linuxfr.org/~linuxfan/14787.html
 
tu vas souffrir

je me suis trompé
SharpDevelop est fait pour c# ou vb pas pour c++

c'est de la foutaise ce truc. Tu peux pas juger quelque chose apres 15 minutes d'utilisation. C'est juste un gars qui a pas aimé se faire placarder à faire du dev sur autre chose que son visual C++

C'est net, la première qualité d'un informaticien doit être la capacité d'adaptation. C'est raté pour lui.

A lire:
http://www.ibm.com/developerworks/ [...] y/l-debug/
Et  bien sûr: http://valgrind.org/

Emacs + terminal rulez

 
-1
 
Pas du tout d'accord là. Les core sont utiles pour l'imputabilité, et en prod, c'est la seule solution pour obtenir des infos sur un plantage sans faire tourner dans un debugger en permanence.
 
Sans compter que quand on commence à jouer avec un debugger, on peut faire disparaitre significativement des bugs, genre race conditions, ou barrières pas mises au bon endroit.

ouais ça c'est la théorie. en pratique l'équipe qui fait l'exploitation applicative elle en fait rien des core, elle relance le bouzin et roule !

Peut être chez toi. C'est pas le cas chez moi/nous.

bah quand t'as une poignée de serveurs, ça va, quand t'en as des cantines, à part de faire péter des alertes de seuil d'occupation disque, tu vois rien.

Et ca commence à ou ta limite pour les cantines?

A peu près 300 machines, qui passent leur temps à faire tourner des modèles de simu (OSMA, OCASIME, ... d'airbus). Quand y'en a une qui core, il est dans l'intéret de beaucoup de monde de le justifier.

Evidemment c'est pas du windows (les outils d'imputabilité sous cet OS m'ont toujours fait sourire); chaque plantage est catalogué, parce que ca serait très bête d'avoir ensuite à rehoster le code en question sur un avion lors d'un retrofit, pour ensuite expliquer en vol à la radio: "ah mais non, c'est normal, redémarrez le calculateur, ca arrive de temps en temps".

Merci de croire que tout le monde n'administre pas un parc facon microsoft certified engineer/branques avec le MS AD+exchange qu'on peut se permettre de rebooter quand il thrash/crash