Je ne sais pas vous, mais moi j'attends avec impatience un tel outil ...
Aller plus loin
- InfoWorld (4 clics)
C++ Builder sous Linux : bientôt du neuf !
25
jan.
2002
Il semblerait que Borland dévoile un peu ses plans concernant le portage de C++ Builder sous Linux. Cela se passera lors d'une prochaine conférence à LinuxWorld (NewYork).
Je ne sais pas vous, mais moi j'attends avec impatience un tel outil ...
Je ne sais pas vous, mais moi j'attends avec impatience un tel outil ...
# Pour quelle plate-forme ?
Posté par Jean-Yves B. . Évalué à 10.
Je me demande si ce sera juste l'EDI ou le compilo aussi. Dans ce dernier cas ça va être un beau bordel : la portabilité de compilo à compilo ça n'a jamais été vraiment ça, ils sont tous buggés mais de manière différente ; ce n'est pas demain que l'on compilera le noyau avec BC++.
Bienvenue quand même aux fichiers de projet à la place des Makefile ! Et - joie - aux wizards qui génèrent du code spécifique aux libs Borland® !
Bon, allez, j'arrête de chambrer, ça aidra peut-être une ou deux boîtes à porter leurs softs sous Linux (oui, je sais, ce n'est pas sensé avoir un rapport).
[-1, non constructif]
[^] # Re: Pour quelle plate-forme ?
Posté par Alberto . Évalué à 10.
Si c'est l'EDI et le RAD c'est bien. Si c'est pour utiliser le compilo borland a la place de gcc c'est bien bete ! Gcc optimise le code x86 super bien (maintenant) et il est portable. Borland a meme tout interet a ce que son Edi se compile avec gcc...
[^] # Re: Pour quelle plate-forme ?
Posté par kadreg . Évalué à -2.
Ah il va mieux, parcequ'en cas de calcul lourd, principalement flottant, c'était loin d'être top. Il se faisait pourrir par le compilo d'intel, et par cl version 6.
Il y a un test dans un coin du ternet que je lise un truc ce soir ?
[^] # Re: Pour quelle plate-forme ?
Posté par Stephane JUTIN . Évalué à 10.
Je crois savoir que les concepteurs de GCC implémentent surtout des optimisations multi-plateformes.
Et puis optimisation x86 ca veut pas dire grand chose : le style de codage RISC est bénéfique sur une PIII avec 3 décodeurs (dont 2 capable de décoder que des instructions ultra-simple), alors que sur un K6 avec seulement 2 décodeurs (mais capable de décoder des instruction plus complexe) c'est l'inverse.
flottant, c'était loin d'être top
Oui, c'est ce que je disais, la structure des registres flottants en pile est une spécifité des processeurs Intel je crois, il est donc logique que gcc soit mauvais dans ce domaine
[^] # Re: Pour quelle plate-forme ?
Posté par Troy McClure (site web personnel) . Évalué à 5.
(ça reste un bench, on peut toujours critiquer, celui-ci est clairement orienté calcul intensif et est sans doute un peu biaisé en faveur d'intel...)
Ça vaut quand même le coup de rappeler que le compilo d'intel est disponible gratuitement pour un usage non commercial.
Pour du numérique, il est logiquement plus performant que gcc, il supporte aussi openmp, et sa version c++ devrait être très efficace puisque intel a absorbé KAI... J'ai pas eu l'occasion de vérifier tout ça par moi-même, mais je l'aurai très bientot.
Et dans les commentaires de /., y'a un gars qui prétend qu'intel a l'intention de supporter toutes les extensions gnu de gcc pour permettre la compilation du kernel avec la prochaine version d'icc ..
<appel aux trolls> Quelle sera la première distrib à fournir des binaires compilés avec icc ou bcc ?
[^] # pas le noyau avec BC++
Posté par Jean-Noël Avila . Évalué à 10.
Nan. le code du noyau est optimisé pour une compilation avec gcc. C'est comme le miel et la tisane. En plus, il est truffé de pragmas speciaux gcc.
Si tu essaies de compiler avec BC++, tu risques d'avoir des surprises.
[^] # Et pour quels développeurs ?
Posté par VACHOR (site web personnel) . Évalué à -1.
Le dernier auquel j'ai eu affaire (borland C++ 5.0 sous win bien sur) plantait régulièrement, gérait mal les dépendances, le compilo faisait des exe énormes et mal optimisés, mais quand on essayait d'optimiser les exe plantaient... Cerise sur le gateau, leurs classes de base style listes et arbres étaient buggées ! Obligé de redévelopper ça soit même. Merci borland.
Sous Linux y'a GCC qui est quand même le meilleur compilateur du monde (si quelqu'un connait un meilleur, je suis pas au courant), ce qui permet d'ailleurs à la communauté des LL d'être fier et indépendante d'un fournisseur de logiciel commercial comme borland, et ce surtout pour des softs fondamentaux comme un compilateur.
Bref, borland C++ sur Linux, pourquoi pas, mais pas pour moi.
[^] # Re: Et pour quels développeurs ?
Posté par Pascal Terjan (site web personnel) . Évalué à 9.
Le but de C++ Builder c'est de permettre de faire des interface graphiques (meme principe que glade) et d'avoir aussi l'éditeur/debugueur/... pour le code des callbacks.
J'ai acheté Borland C++ 5 et je l'ai grandement regretté, par contre j'ai eu l'occasion de travailler sur C++ Builder pour un projet et j'ai découvert qu'il est possible de faire très rapidement une interface windows sans se prendre la tete avec l'API win32.
Bref, son but n'est surement pas de concurrencer gcc, plutot QtDesigner+Kdevelop.
[^] # Re: Et pour quels développeurs ?
Posté par Jean-Yves B. . Évalué à 9.
Ça inclut autant C++ Builder® que Borland© C++.
La seule mention de C++ Builder qui est faite est à propos d'une version pour Windows.
J'avoue que je ne saisis pas pourquoi le texte de la news mentionne C++ Builder© alors que la news originale n'est parle pas.
[^] # Re: Et pour quels développeurs ?
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
L'auteur peut-il indiquer d'ou il tire ses sources dans la mesure ou c'est pas de ce lien et que comme toujours il est impossible de trouver quelque chose sur le site de Borland (meme si ca y est...) ?
[^] # Re: Et pour quels développeurs ?
Posté par Vivi (site web personnel) . Évalué à 10.
Mouarf !
Non, STP dit que c'est le meilleur compilateur que tu connaisses mais pas plus, tu es ridicule là.
# startégie
Posté par Denis Bodor (site web personnel) . Évalué à 10.
Un développeur C++ est-il à ce point lié au compilateur qu'il ne pourrait pas passer de du C++ Borland à g++ ?
[^] # Re: interet d'une IDE sous Linux
Posté par Stephane JUTIN . Évalué à 1.
Par exemple, autant des outils comme gdb ou gprof sont techniquement au niveau de VC++, autant sans interface on ne peut pas vraiment les utilise, moi-même à part faire le "backtrace" d'un core-dump, j'ai du rénoncer à débugger sous Linux autrement qu'avec "printf()".
J'ai essayé "vi", mais bon ça date des années 1970 (à une époque ou les claviers n'avaient pas de touches fléchées et la souris, je n'en parle pas), et puis avoir passé 3 mois à coder en C sous vi, ma productivité sous cette environnement est toujours plus faible qu'avec Visual.
Je veux bien admettre qu'au bout de 5 ans, on gagne du temps (disons 3 centièmes de secondes) en utilisant des touches "h", "j", "k", "l" au lieu des touches fléchées mais pendant les 5 premières années pour prendre l'habitude, la
productivité en souffre.
Et puis le classbrowser de Visual C++ est très utile pour les gros projets, sous Linux on a "ctags" mais il faut savoir qu'il existe, s'en servir, et au final il ne reconnait pas le C++(je crois) et n'affiche pas liste des classes comme le fait Visual.
Désolé, d'aller à contre-courant de la pensée dominante de ce forum mais ceci est simplement le recit objectif de mon expérience.
Sinon, pour les gens habitué à TURBO-C, RHIDE est pas mal, mais mal fini (ne marche pas en Telnet/SSH, seulement sur une console).
[^] # Re: interet d'une IDE sous Linux
Posté par Alphonse Oncle . Évalué à 1.
[^] # sorry
Posté par Stephane JUTIN . Évalué à -4.
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . Évalué à 10.
Linux ne manque pas d'IDE, mais il n'y a pas d'IDE à la Visual C++ sous Linux (et encore, KDevelopp à l'air de s'en approcher un peu trop :-) Pour débuter, on a besoin d'avoir des règles de développement, des méthodes de travail, et le Visual C++ force à en avoir certaines, mais avec l'expérience, on est bien content de pouvoir se faire son propre environnement à base de makefiles, gcc, gdb (parfois ddd, mais pas trop quand même), autoconf, dpkg-buildpackage...
Comparer l'environnement Visual C++ à vi, ça c'est un joli troll, presque autant que de comparer XEmacs (notez le X) à vi...
[^] # Re: interet d'une IDE sous Linux
Posté par Tame . Évalué à 6.
anjuta et gIDE (meme si je crois que ce dernier n'est plus maintenu)... j'avais essayé anjuta ya pas longtemps, c'etait sympatoche...
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
Non, c'est plutôt le contraire. Avec l'expérience tu en as un peu marre de perdre du temps avec ces conneries de makefiles et autres autoconf, de ne pas avoir de bon source browser, etc... :-)
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . Évalué à 10.
Avec l'expérience, tu apprends à générer ce genre de fichier en quelques minutes, et de façon durable (ne pas avoir à tout revérifier à chaque fois). Un browser de méthodes/fonctions ne remplacera jamais une méthode de travail claire et rapidement compréhensible par d'autres, j'aurais même tendance à ajouter «au contraire»: quand je vois des projets développés sous Visual C++ avec un grand nombre de classes et juste 3 ou 4 fichiers source dans le projet, je me dis que si le développeur avait eu à rechercher les classes/méthodes à la main, il aurait pris l'habitude de mieux ranger son code...
Les interfaces de navigation dans le code facilitent le travail mais ne le rendent pas plus propre, au contraire (cette fois-ci, je n'hésite pas à le dire).
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Ah bon, alors tu dois être beaucoup plus doué que moi et la totalité (je dis bien la totalité, et ça fait du monde) des gens que je connais développant ou ayant développé sous Unix en général et Linux en particulier. Ça fait 8 ans que je code sous Unix, et les makefiles restent toujours un problème. Je peux aussi te dire qu'ils sont toujours un problème pour les gens de Gnome et de KDE, ainsi que pour tous les développeurs dans toutes les boites où j'ai pu bosser (entre autres IBM, Lucent, Parasoft).
Un browser de méthodes/fonctions ne remplacera jamais une méthode de travail claire et rapidement compréhensible par d'autres
Personne n'a jamais dit le contraire, et d'ailleurs ça n'a pas grand chose à voir. Mais par rapport à 'find | xargs grep' ou ctags, ça fait quand même gagner un temps fou.
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . Évalué à 10.
Ben, ça ne fait que 2 ans que je suis sorti de fac et il est vrai que je donne des cours de Makefile dans quelques sociétés alors qu'il y a un an je ne connaissais que le principe... enfin, quand je parle de cours, j'écris les Makefile puis je leur explique qu'il suffit de taper "make opt" ou "make debug" pour obtenir les sources puis "make install" avant de lancer les tests. Comme bien souvent, cela reste trop difficile, je suis obligé d'intégrer ces commandes dans leur XEmacs (que les developpeurs ont aussi bien du mal à utiliser en général).
Les Makefile, c'est comme Unix et pas mal d'outils comme sed, awk, vi...: quand on ne cherche pas à comprendre, on ne comprend pas, et une fois qu'on comprend, on se rend compte que c'est hyper simple!! C'est juste une façon de réfléchir.
[browser de code/méthode de travail] ça n'a pas grand chose à voir
Ben, quand même un peu. Quand il y a un outil pour naviguer rapidement dans les classes, on a tendance à ne pas s'embêter à organiser les sources... et du coup un simple grep ne suffit pas, je suis bien d'accord. Tout est une question de méthode de travail, et il n'est pas simple de se séparer de la méthode de travail proposée (imposée?) par le Visual C++; personnellement, il m'a fallu un moment, mais je me sens bien mieux... plus libre.
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Et ils sont portables sur combien de plateformes tes makefiles ? Est-ce qu'il faut les éditer à la main ou est-ce qu'il y a un script genre configure pour les générer ? Est-ce qu'ils gèrent bien les dépendences ?
Les Makefile, c'est comme Unix et pas mal d'outils comme sed, awk, vi...: quand on ne cherche pas à comprendre, on ne comprend pas, et une fois qu'on comprend, on se rend compte que c'est hyper simple!!
Tu as surement raison. J'ai pratiqué les makefile "fait maison", les Imakefiles, autoconf, tmake, qmake, automake+autoconf, et à chaque fois j'ai complètement loupé à quel point c'était hyper-simple. Et manifestement ça a échappé aussi aux mecs qui ont écrit tous ces outils pour faciliter la génération de makefiles. Ça s'est vachement amélioré le niveau de la fac maintenant, il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années. Je suis impressioné.
Enfin peut-être pas, quand je suis sorti de fac je croyais aussi être très doué et que tout était simple. :-)
Quand il y a un outil pour naviguer rapidement dans les classes, on a tendance à ne pas s'embêter à organiser les sources
La notion de fichier source n'a rien à voir avec la programmation en soi, il y a des langages qui ignorent ce concept, et la tendance des IDE est précisément de t'en abstraire. Ou même tu as carrément des langages comme Java ou la structure des fichiers est définie par le nommage des classes.
[^] # Re: interet d'une IDE sous Linux
Posté par Johann Deneux . Évalué à 6.
Parce que les outils de dev de Windows permettent de générer des projets portables ? C'est vrai ? Pour SunOS, MacOS, GNU/Linux ?
Est-ce qu'ils gèrent bien les dépendences ?
A priori, c'est fait pour ça. Je suis pas sur que VC++ (par exemple) s'en tire aussi bien dès qu'on sort des sentiers battus. Comment intégrer proprement des outils tels que Lex et Yacc par exemple ? Je dis pas que c'est pas possible, je connais mal VC++. Mais je pense pouvoir me débrouiller sous n'importe quel environnement pour faire ce genre de truc si j'ai le droit d'utiliser le clavier pour taper un Makefile. Le pro de VC++ aura forcément plus de mal.
Ça s'est vachement amélioré le niveau de la fac maintenant, il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années. Je suis impressioné.
Ta tendance à prendre les gens pour des cons est assez irritante. C'est pas parceque t'as jamais été copain avec les Makefiles qu'il faut prendre ton cas pour une généralité. Y'a d'autres gens ici qui bossent ou qui ont bossé dans l'industrie.Tous les projets portables que je connais utilisent des Makefiles.
Les problèmes que tu décris ne sont pas liés aux Makefiles en eux-mêmes. Ils sont plutot dû au fait que chaque environnement a son propre compilo avec ses propres outils, que la portabilité du C++ n'est pas géniale, que les librairies n'ont pas le même nom, que les bugs à contourner ne sont pas les mêmes partout... C'est vrai, c'est embêtant, mais le pauvre make (jeu de mots non voulu;) n'y est pour rien.
Une tentative pour régler ce problème est l'utilisation d'outils comme configure, Imake et consorts. C'est vrai que ça marche pas super bien. Mais il y a au moins un effort de fait dans la bonne direction. Comment VC++ (ou Borland C++) aborde-t-il le problème ?
La notion de fichier source n'a rien à voir avec la programmation en soi, il y a des langages qui ignorent ce concept, et la tendance des IDE est précisément de t'en abstraire. Ou même tu as carrément des langages comme Java ou la structure des fichiers est définie par le nommage des classes.
Ca ne constitue en rien une excuse pour mettre du code n'importe où. Moi j'aimais bien le concept des petits fichiers textes tout bêtes. On pouvait utiliser n'importe quoi pour les éditer. J'arrive pas à voir en quoi la tendance des IDE à éliminer la notion de fichier est positive. A part rendre dépendant de l'outil en question. Mais ça c'est plutot positif pour l'éditeur de l'IDE en question. Pas vraiment pour le développeur.
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
Hélas non, je n'ai pas dit le contraire.
Je suis pas sur que VC++ (par exemple) s'en tire aussi bien dès qu'on sort des sentiers battus
Si, tu peux customiser assez facilement les projets, ajouter des pré et post commandes, etc...
Ta tendance à prendre les gens pour des cons est assez irritante. C'est pas parceque t'as jamais été copain avec les Makefiles qu'il faut prendre ton cas pour une généralité.
Il n'y a que naf que je prends gentiment pour un con, parce qu'un mec qui manifestement n'a jamais vraiment fait de makefiles "sérieux" vienne me dire "c'est tout simple, y a qu'a lire la doc", c'est un brin agaçant.
Et oui, mon cas est une généralité. Je n'ai jamais bossé dans un projet ou le système de build ne soit pas, à un moment où à un autre, une sources de problèmes.
Les problèmes que tu décris ne sont pas liés aux Makefiles en eux-mêmes. Ils sont plutot dû au fait que chaque environnement a son propre compilo avec ses propres outils[...]
C'est exactement ce que je dis, et pour résoudre tout ses problèmes il faut faire des makefiles complexes, ce qui prend du temps, et qu'il faut debugger et maintenir, ce qui prend encore plus de temps. Après tu peux couper les cheveux en 4 et dire "c'est pas la fautes des makefiles", le fait est que c'est là dessus qu'on passe du temps.
Donc dire que les makefiles c'est tout simple et avec l'expérience on trouve ça mieux qu'un IDE, c'est faux.
Après, oui, bien sur, tu as raison, il n'y a que les makefiles pour résoudre certains problèmes, en particulier la portabilité. Pas moyen d'y échapper. Là non plus, je ne dis pas le contraire, je dis simplement que ça n'est pas une chose simple et que si je pouvais m'en passer et avoir un IDE qui me gère tout ça à ma place, ça serait beaucoup mieux.
Ca ne constitue en rien une excuse pour mettre du code n'importe où.
Ben si, puisque ça n'est plus toi qui t'occupe de savoir où se trouve le code.
Moi j'aimais bien le concept des petits fichiers textes tout bêtes.
Moi aussi, mais c'est pas pour ça qu'il n'y a pas de meilleures solutions.
[^] # Re: interet d'une IDE sous Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
en gros, tu dit que pour des trucs bien complexes, ya pas photo il faut utiliser les makefiles (meme si c'est pas très ragoutant); et que dans les cas simples, il vaut mieux utiliser les ide. Bon.
Sauf que dans les cas simples, un makefile n'a jamais tué une mouche, surtout si on prend le soins de lire la doc pour utiliser des trucs style règles de compilation automatiques et autres dépendances données gentiment par gcc ...
Bref, pour un truc simple, c'est pas les cinq minutes que tu vas prendre à taper ton makefile qui pèsent sur le temps de développement d'un soft; et dans un cas complexe (multiplateforme, etc.), impossible de faire sans autoconf/automake.
Alors bien sur, il vaut mieux lire la doc de make.
Mais bon...
L'intérêt d'une IDE m'a toujours paru très limité : oui, ça fait gagner du temps sur certains trucs simples, mais de toute façon gagner 5 minutes sur un développement de plusieurs semaines, c'est pas top... et sur les autres fonctionnalitées, emacs/vim sont plus efficaces pour ceux qui en ont l'habitude.
Dans certains domaines l'IDE peut vraiment apporter un plus (developpment d'un client BD + clickodrome + composants par ex), mais il y a beaucoup de secteurs dans lesquels ça ne sert foutrement pas à grand chose.
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, je dis que dans tous les cas je préfèrerais utiliser un IDE. Hélas en pratique ça n'est pas possible.
L'intérêt d'une IDE m'a toujours paru très limité
Tant pis pour toi, mais ça n'est pas mon cas ni celui de beaucoup d'autres. Ça fait un peu plus de 10 ans que j'utilise Emacs ou XEmacs, je commence à savoir m'en servir. Et pourtant y a plein de trucs que font les IDE que je trouve très bien et qui manquent à emacs.
[^] # Re: interet d'une IDE sous Linux
Posté par pas_moi . Évalué à 1.
Un Makefile bien écrit associé à un "gcc -m" bien placé et le tour est joué. Bien souvent, quand je refais les Makefile d'un projet existant, les développeurs sont contents... (ça me fait un peu mal aux chevilles de dire ça, mais bon c'est la vérité)
il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années
C'est pas de ma faute si je comprends certains outils mieux que des personnes qui ont plus d'années de développement derrière elles. Ce que je constate, c'est que la fainéantise de certains développeurs les pousse à utiliser ce qui existe, sans chercher à faire mieux que ce qu'ils savent utiliser alors que ça leur permettrait d'être encore plus fainéant.
La notion de fichier source n'a rien à voir avec la programmation en soi
Pour l'instant, l'indépendance n'est pas flagrante à mes yeux. Je me base sur l'utilisation du Visual C++ dans différents projets. A mon avis, il n'est pas dans l'intérêt des développeurs d'utiliser un IDE qui utilise son propre format pour rassembler sources et projet dans un même fichier, mais c'est juste mon avis (il y a sûrement des exceptions pour confirmer ce que je dis...).
[^] # Re: interet d'une IDE sous Linux
Posté par Cyril Chevrot . Évalué à 3.
L'avantage de la méthodologie Unix c'est que tu controles __toute__ l'information de tes sources. Il n'y a rien qui soit génréré automatiquement. Je suis en train de porter un programme que j'avais écris en Visual C en gtk+ et je peux vous dire quel bonheur de devoir supprimer toutes cette multitude de fichiers, souvent d'une taille inacceptable, généré par VC et qui sont d'une utilité plus que douteuses. Lorsque l'on développe sous Windows, on écrit 3 lignes de code, on sauve et on se retrouve avec des Mo de fichiers stockant des information aussi inutiles que la position de notre curseur dans chacun des fichiers que l'on a ouvert au moment ou l'on a quitté l'application.
En autre terme Unix, c'est la maitrise, Windows c'est l'assistanat. Et l'assistanat, en France on est bien placé pour le savoir, cré beaucoup de dégats.
[^] # Re: interet d'une IDE sous Linux
Posté par pasBill pasGates . Évalué à 3.
Perso je suis bien content de me retrouver au meme endroit que la derniere fois quand j'ouvres un fichier, c'est peut-etre pas essentiel, mais c'est pratique et agreable, ca ne coute rien si ce n'est quelques Ko sur ton disque de 20Go et ca n'affecte pas le soft final ni tes habitudes de programmation.
L'assistanat c'est au contraire bien pratique, sinon rien ne t'empeche d'ecrire tes lettres avec un crayon plutot qu'un traitement de texte, ca aussi c'est de l'assistanat, en fait selon le point ou tu te places, toute l'informatique c'est de l'assistanat.
Notes qui si tu prenais la peine de voir ce que VC++ contient, tu aurais trouve que tu peux tout a faire creer des makefiles et tout faire en command line, en n'ayant rien d'autre que les fichiers que TU as cree, comme avec XEmacs+gcc++ld+make, en gros t'as le choix entre les 2 approches, mais faut croire que cette partie de VC++ t'as echappe.
[^] # Re: interet d'une IDE sous Linux
Posté par Cyril Chevrot . Évalué à 4.
Disonc que ca serait bien qu'il sépare clairement l'information de configuration de l'information utile. Peut-etre est-ce possible si l'on change les options, en tout cas sur ma version ce n'est pas l'option par défaut.
Et je trouve scandaleux d'avoir à se trimbaler des fichiers de configuration de 3 Mo quand le programme fait 40 Ko. Certes j'ai de la place sur mon disque. Mais je peux avoir le besoin d'envoyer mes programmes aux autres développeurs qui travaillent dessus et la les fichiers de conf de 3 Mo ils vont devenir vraiment casse couille.
Certes si on cherche bien on doit pouvoir organiser tout ca de facon un peu plus propre mais les options par défauts ne nous contraigne pas à avoir une telle attitude. Et c'est pour ca que je parle d'assistanat dans le mauvais sens su terme.
Le coté plus abrupte d'Unix force les gens à etre plus structuré dans leurs méthodes de travail et plus minimaliste. Or la perfection est atteinte lorsqu'il n'y a plus rien à enlever et ca sous VC et sous Windows en général on n'en n'a pas conscience.
Notes qui si tu prenais la peine de voir ce que VC++
Lorsque j'avais utilisé VC++ j'y avais été contraint et forcé, et pour que j'explore toutes les fonctionnalités d'un soft il faut que j'y prenne gout et la ce n'était vraiment pas le cas. Cela dit les options par défauts sont assez significatives de la philosophie de développement.
L'assistanat c'est au contraire bien pratique
Oui mais il faut séparer la partie assistanat (IDE, fichier de configuration de l'IDE, ...) du code source et ne pas tout mélanger comme le fait VC++ (fichier généré dans le code source contenant la configuration de l'IDE !).
[^] # Re: interet d'une IDE sous Linux
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Oui, enfin moi sous vim ça me le fait aussi, mais il me stocke ça dans des fichiers cachés, ça n'interfère pas du tout avec les fichiers sources ! (berk)
Mieux, je dispose du folding des fonctions (à part mettre Vim dans VC++ je vois pas comment faire).
Le folding, c'est ce truc super pratique qui te «replie» tes procédures et n'affiche qu'une seule ligne. Ca existe sous tout éditeur un tant soit peu intelligent (Vim, (X)Emacs, et j'ai vu ça la première fois sous l'éditeur du GFA Basic sur atari)
[^] # Re: interet d'une IDE sous Linux
Posté par pasBill pasGates . Évalué à 0.
J'ai ici un petit outil d'environ 10'000 lignes, separe en une vingtaine de classes differentes:
- les fichiers sources que j'ai ecrit ne contiennent AUCUNE info de l'IDE, c'est les fichiers que j'ai ecrit tels quels, rien d'autre.
Ensuite j'enleve les fichiers sources et je regarde ce qui reste:
- un fichier .dsp 8Ko
- un fichier .dsw 1Ko
- un fichier .ncb 289Ko
- un fichier .opt 59Ko
- un fichier .plg 5Ko
Total: 362Ko.
Je zippe TOUT le soft(sources+config), j'arrive a un fichier zip de 114Ko, si tu trouves que c'est enorme a envoyer par e-mail, c'est que t'as un modem 2400 bauds.
J'ai un autre soft depassant les 100'000 lignes de code reparties en probablement une centaine de classes differentes, le total des fichiers de config est de 877Ko, et le plus amusant, c'est que ce soft la on le compile sur 6 plateformes differentes sans avoir rien a changer, les fichiers sources sont les memes vu que bien evidemment VC++ ne les a pas touches car il stocke tout dans ses fichiers de config.
On est tres loin de 3Mo pour un soft de 40Ko et des sources modifiees par VC++.
En gros, faudrait peut-etre regarder comment marche VC++ avant de dire qu'il fait x ou y, car tu es a cote de la plaque.
[^] # Re: interet d'une IDE sous Linux
Posté par Cyril Chevrot . Évalué à 1.
Quand j'écris :
"fichier généré dans le code source contenant la configuration de l'IDE !"
je ne veux pas dire que la config est dans les fichiers sources mais quelle est située dans le meme répertoire que celui des fichiers sources.
Sinon pour les fichiers générés j'ai les memes que toi avec en cadeau bonus, un fichier aps de ... roulement de tambour ... 3 Mo !
Je sais pas à quoi il sert, on est sous windows, le compilo fait plein de truc et ne t'explique pas le pourquoi du comment. Alors peut-etre que je suis un ignorant, mais la philosophie Windows est justement de rendre les gens ignorant.
Et puis de toute facon comme je compte ne plus jamais programmer sous Windows, je m'en tape pas mal de savoir à quoi peu bien servir ce fichier aps. Enfin si tu le sais tu peux toujours me le dire.
Nibbles.aps 3Mo
Nibbles.ncb 74 Ko
Nibbles.opt 48Ko
Nibbles.dsp 6 Ko
Nibbles.plg 1Ko
Nibbles.dsw 539Ah oui dernière chose, n'hésite pas à m'incendier si tu es pas d'accord avec moi, histoire de m'obliger à répondre et de faire monter mes XP (C'est dur d'etre un nouveau sur linuxfr !)
[^] # Re: interet d'une IDE sous Linux
Posté par pasBill pasGates . Évalué à 0.
Maintenant tu vas me dire que c'est un truc secret etc...
J'ai ouvert l'aide de VC++(MSDN+VC++), onglet Search, j'ai tape ".aps", et j'ai eu l'explication dans le 1er resultat ainsi que dans plusieurs des resultats suivants(1er resultat: "PRB: Wrong resources loaded by Resources editor or AppStudio" dans "Knowledge Base").
Moi personnelement make j'ai pas reussi a comprendre comment il fonctionnait et ce qu'il faisait avant d'avoir lu la doc.
En gros t'accuses VC++ de faire des trucs que tu comprends pas alors que tu n'as meme pas cherche a comprendre, ca prenait 5 secondes de trouver ce que c'etait.
C'est pas a VC++ de te dire tout ce qu'il fait a l'instruction pres, c'est a toi de lire la doc pour comprendre comment il fonctionne, tout comme les outils de dev sous Linux.
Autoconf aussi genere pleins de fichiers genre config.cache, config.guess,etc... et il va pas te dire a quoi ils servent, il faut lire la doc, et c'est tout a fait normal, c'est a ca que sert une doc.
De meme gcc si tu lis pas la doc pour connaitre les parametres, t'iras pas loin avec, meme chose pour VC++.
Dire que Windows rend les gens ignorant c'est l'excuse facile du gars qui a pas fait le moindre effort, et c'est purement de ta faute, la doc est la, elle dit clairement a quoi ca sert, mais si tu la lis pas faut t'en prendre qu'a toi meme.
[^] # Re: interet d'une IDE sous Linux
Posté par Cyril Chevrot . Évalué à 1.
Apparemment sous VC++ tu dois regarder toi-même quels sont les fichiers générés par VC++, regarder à quoi ils servent et les supprimer si nécessaires.
De pluls les makefiles ont l'avantage d'être générique. Comprendre les makefiles, revient à comprendre les principes inhérents à _toute_ compilation. Comprendre VC++ revient à comprendre VC++. Comprendre Borland C++ revient à comprendre Borland C++, ...
Sous windows, on n'a pas cette notion d'outil générique, comme make et les centaines de commandes Unix qui permettent d'apporter des solutions rapides et efficaces aux problèmes que l'on se pose. Ainsi j'ai moins de réticence à apprendre comment fonctionne make par rapport à VC++ car je sais que une fois compris les principes de make je pourrais utilisé cet outil dans de nombreuses situations très différentes les unes des autres.
Je suis peut-être un peu borné quand il s'agit de Windows mais j'ai mes raisons (le seul avantage que je trouve à Windows est une meilleur finalisation des produits, ce qui est d'ailleurs très important et à tendance à manquer dans le libre).
[^] # Re: interet d'une IDE sous Linux
Posté par pasBill pasGates . Évalué à 1.
Quand aux outils "generiques", TU n'as pas cette notion d'outils generiques, le plus con c'est qu'ils sont la par defaut avec VC++, si tu les utilises pas c'est de ta faute soit parce que tu n'as pas lu la doc, soit parce que tu veux pas les utiliser.
Et si tu veux jouer avec des makefiles rien ne t'empeche de le faire avec VC++, si tu avais pris la peine de regarder dans le menu projects, la 5eme entree se nomme "export makefile", et si t'es meme plus temeraire que ca, tu peux TOUT faire en command line, debugger, compiler, linker, tu as le CHOIX, maintenant si tu n'as jamais lu la doc et tu cliques au hasard sur les menus, c'est de ta faute, pas la faute a VC++.
En gros tu critiques VC++ par ignorance du produit car tu n'as jamais daigne lire la doc.
[^] # Re: interet d'une IDE sous Linux
Posté par Cyril Chevrot . Évalué à 1.
Certes tu peux programmer avec un style Unix sous Windows mais la n'était pas mon propos.
Mon argumentation ci-dessus chercher avant tout à comparer le _style_ de programmation Unix au _syle_ de programmation Windows, rien de plus.
Tu dis également que la propreté d'un makefile dépend de celui qui le cré comme si c'était un problème. Effectivement la propreté d'un makefile dépend de celui qui le cré, ce qui signifie que sous Unix on peut avoir de la bonne programmation si le programmeur est bon.
Alors que sous VC++ c'est le compilateur qui créé les fichiers dont nous avons parlé, sans qu'on lui demande rien. Et c'est cela que je critique. C'est ce comportement _par défaut_. Forcément si tu cherches bien tu peux toujours modifier l'environnement pour qu'il te convienne mieux, mais j'insiste, le comportement par défaut est très révélateur de la philosophie de programmation sous un environnement parce-qu'il est le plus largement adopté.
D'une certaine facon je ne pense pas que l'on soit porfondément en désaccord, je pense plutot que l'on est chacun axé sur des problèmatique différente.
[^] # Re: interet d'une IDE sous Linux
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Par contre, BC++ (Builder ou non) produit des assez gros exécutable (>1Mo pour pas grand chose) mais c'est suffisant pour le distribuer... (c'est toujours mieux qu'une ribambelle de disquettes).
Et puis il génère également pas mal de gros fichiers à côté, mais il suffit de recompiler une deuxième fois pour voir que cela est instantané et qu'il a en fait mis tout en cache dans un fichier...
Ces fichiers peuvent bien évidemment être supprimé pour distribuer/copier le projet (on peut même les faire sortir vers un dossier bien précis) !
--
<HS>Au fait, la news n'était pas sur C++Builder ?</HS>
[^] # Re: interet d'une IDE sous Linux
Posté par Stephane JUTIN . Évalué à 1.
Tu peux faire du linkage statique avec Visual aussi si tu en a envie, et puis les lib dynamiques c'est aussi un beau bordel sous Linux (libc5, glib)...MS résout le problème en te fournissant toutes les dépendances dont tu peux avoir besoin avec l'appli.
C'est un peu bourrin comme méthode mais au moins t'as l'assurance de pouvoir installer ton truc : regarde le nombre d'outils propriétaires sous Linux qui sont marqués RedHat 6.2 only parce que ils manquent des bibliothéques (ou c'est pas la bonne version) sur les autres distrib ...
Maintenant contrerairement à la branche intégriste du mouvement Linuxien, je suis objectif sur Visual :
C'est vrai qu'il génére un peu des fichiers de 3 mégas à la con(il parait qu'il faut en supprimer de temps en temps, ça l'accélére), que le "Edit & Continue" (modification du code en "live" dans le débugger) marche quand ça le chante mais au final je trouve ça plus agréable que le couple 'VIM (avec coloration syntaxique) + Make' que j'ai aussi testé.
Au fait, la news n'était pas sur C++Builder ?
Oui, mais le sujet était IDE vs emacs/vi, et les seules IDE que je maitrise sont VC++ et Turbo C (en mode texte). Donc, ça bien un rapport vu que c'est mon expérience de Visual qui me donne envie d'utiliser ce genre d'outil (par ex : C++ Builder) sous Solaris et pourquoi pas sous Linux à la maison ...
En attendant, on peut toujours sur rabbatre sur RHIDE qui s'il marchait dans un terminal SSH serait quasi-parfait
[^] # Re: interet d'une IDE sous Linux
Posté par Jean-Yves B. . Évalué à 8.
Si ta machine le permet => utilise ddd (http://www.gnu.org/software/ddd/(...)) ou gvd (http://libre.act-europe.fr/gvd/(...)). Pour les gens qui n'en veulent : GUD, le Grand Unified Debugger d'[X]Emacs.
En à côté, je tiens à préciser que dans un certain nombre de cas, débugger à coups de printf() peut introduire des bugs. Mais c'est valable aussi pour les débugger in vivo (post mortem c'est moins grave :) ).
Souvenez-vous : « La présence de l'observateur perturbe la mesure ».
Trop gros, passera pas.
De toutes façons : ed is the standard editor. Il y a TECO pour les fans aussi dans le genre. :)
Tu as pas mal de choix. Je cite mes préférences personnelles :
kdevelop (classbrowser correct http://www.kdevelop.org(...) ) et XEmacs (avec ecb http://ecb.sf.net(...) et la speedbar).
Infodock permettait pas mal de chose mais est un peu moribond.
Accepte donc mon avis personnel (qui n'est par définition pas objectif).
[^] # Re: interet d'une IDE sous Linux
Posté par Alphonse Oncle . Évalué à 3.
[^] # Re: interet d'une IDE sous Linux
Posté par Jean-Sébastien Samson . Évalué à 7.
Plus exactement, ça peut faire apparaitre des bugs qui seraient restés invisibles autrement ou l'inverse.
[^] # Aïe !
Posté par Denis Bodor (site web personnel) . Évalué à 5.
Par contre... hmmm... comment dire...
J'ai essayé "vi", mais bon ça date des années 1970
Je ne monte pas au crénaux, mais tu vas déclancher un énorme troll là :)
Allez hop, si... ca fait un bout de temps que les touche de direction sont configurable sous Vi (Vim), et les touches de fonction aussi, les le splitage de l'écran, le mode visuel, les macro, la navigation dans le filesystem... (cf http://www.vim.org(...) )
[^] # Re: Aïe !
Posté par vrm (site web personnel) . Évalué à 8.
L'interet c'est le RAD C++ sinon je vois pas trop l'interet de la démarche de Borland.
C'est un produit de qualité contrairement à VC++ (oups troll dev. windows)..
Par contre le compilateur gere plein de truc proprio Borland (comme le 'finaly' pour les exception)
enfin .. je prefere mon eclipse & mon java :)
[^] # Re: interet d'une IDE sous Linux
Posté par Bernard Hugueney . Évalué à 4.
Franchement, étant habitué à développer en C++ avec g++, le manque de conformité à la norme de Visual est le plus grand obstacle à ma productivité
Essaye Xemacs :-), mais c'est pas un troll, mais qd on vient de Visual, vi n'est peut-être pas le meilleur choix. Sous xemacs, il y a un package object browser qui analyse les déclarations de classes d'un projet : http://www.cs.indiana.edu/elisp/oo-browser/oo-browser_toc.html(...)
DDD est le meilleur debuggeur que j'ai utilisé
http://www.gnu.org/software/ddd/(...)
Désolé, mais que considère que pour le dev C++, la conformité du compilo à la norme passe loin devant le cliquodrome, et donc VC++ suckz g++ 3.0.3 roulaize grave :-)
Oups je me suis laissé dériver HS !
Désolé, j'ai pas pu m'en empêcher..
Xemacs avec oo-browser + ddd c'est qd même du graphique, même si c'est vrai que pour une intégration complète avec le C++, il faudrait une communication plus étroite entre g++ et [x]emacs.
Que fait donc Stallman ?
[^] # Re: interet d'une IDE sous Linux
Posté par daniel . Évalué à 7.
ddd, comme la plupart des débuggeurs cités plus haut, est une interface graphique de gdb, mais bon la je cherche la petite bête. ddd est impressionnant, parce qu'il permet de débugger dans plusieurs langages Ada, C, C++, Chill, Fortran, Java, Modula, Pascal, Perl et Python (rien que ça), et qu'il permet grâce à gdb version 5 et +, de débugger le multi-thread.
comme débuggeur, insight aussi est très bien
d'autre part comme ide il y a aussi anjuta qui est couplé à glade pour faire des applis gtk.
Je tiens à ajouter que maintenant existent des langages de haut niveau comme perl et python qui permettent d'écrire des programmes avec gui de manière simple, ce qui rend l'utilisation de RAD moins importante.
[^] # 100% d'accord
Posté par ufoot (site web personnel) . Évalué à 10.
Effectivement, avec ces outils on peut faire des interfaces graphiques rapidement, dont le code ne ressemble pas a une usine a gaz ignoble. En plus ces langages (surtout Python) s'interfacent nickel avec le C, donc tu peux sans probleme les utiliser dans le cadre d'un projet qui utilise du C par ailleurs.
Utiliser plusieurs langage pour un meme projet, c'est une technique qui marche mais que peu de gens mettent en place en entreprise (du moins parmi les projets que j'ai vus). En general, on a droit a un classique: "on developpe sous xxx-builder v5.6.3.3.2 professionnal-business-enterprise", on cherche des techos qui ont une ligne qui ressemble a ca dans leur CV et hop c'est parti.
Alors que souvent, un petit peu de C, un petit peu de Perl, du tk par-ci du tk par la, quelques scripts bash et ca roule tout seul.
J'ai deja vu des gens faire des batchs en C (pas le droit de faire du perl ou un script bash: "ici on developpe en C mossieur!"). J'en ai vu d'autres parser des fichiers textes en Java - on aurait divise les temps de dev par 10 avec du Perl.
C'est vrai que dans ces exemples les gens raisonnaient tres "logiciel proprietaire" du genre
"- ah oui Perl, et donc ca s'achete ou?
- bah ca s'achete pas...
- ah non alors nous il nous faut des produits certifies"
Paye ton produit certifie et tout bugge quand meme et regrette pendant 3 mois de pas avoir le droit de faire du Perl parce que soit disant c'est pas assez sur comme produit... (desole je suis un peu HS mais comme je suis aussi un peu aigri ca fait du bien de se defouler)
Les produits de Borland sont surement tres bien, mais si c'est pour faire des interfaces graphiques, mon avis c'est que C++ c'est pas _du tout_ adapte. Du Delphi d'accord, du C++ non...
[^] # Re: 100% d'accord
Posté par daniel . Évalué à 6.
Tout à fait !
Pour moi le top c'est :
- utiliser python pour l'interface graphique et les entrées-sorties
- pour le coeur, utiliser un langage plus rapide et bas niveau comme le C/C++, ce qui permet d'avoir accès à toutes les librairies C existantes commes les extensions numériques par exemple
ça permet d'appliquer au maximum le principe de réutilisation de code, de faire des programmes qui soient portables (si on utilise des toolkits multi-plateformes) et maintenables, parce que le C devient très cryptique quand il s'agit de faire des interfaces graphiques.
Enfin je veux juste ajouter un lien vers un projet sur python et les interfaces graphiques, qui me semble ultra-intéressant, et qui mériterait de l'aide : http://anygui.sourceforge.net/(...)
[^] # Re: non conformance de visual c++
Posté par Stephane JUTIN . Évalué à 4.
Tout les compilateurs sont buggés et g++ ne fait pas exceptions que je sache ?
Quand tu prends un programme d'un million de ligne, et que tu le porte de g++ à Visual c++, c'est clair que tu as des problèmes mais c'est vrai aussi quand tu porte de Sun CC à g++ par exemple.
En plus, tu est HS je parlais des IDE pas des compilo...
Tout le monde dit que visual est moins standard compliant que g++ mais pas à part MS = pas beau j'ai pas vu beaucoup d'argumentation derrière ...
Est-ce que tu as des exemples concrets de non-conformance au standard ?
De plus, g++ c'est l'un des compilateurs qui propose le plus d'extension au langage, si MS faisait le dixième de ce que font les concepteurs de GCC j'en connais qui hurleraient au scandale.
Enfin, j'ai développé pendant longtemps avec DJGPP sous Dos, et j'ai pas mal souffert de certains bugs :
- internal compiler error avec g++ 2.95.2 (dernière version à l'époque) sur un pointeur de méthode
- support expérimental (alpha) des exceptions avec G++ 2.7 (sorti en 97) alors que ca fait vraiment longtemps que visual c++ les supportaient (depuis la version 4, sortie en 96)
Une source de comparaison objective :
http://www.boost.org/status/cs-win32.html(...)
Tu va être content, c'est g++ qui est le moins mauvais à ce test-ci...
[^] # Re: non conformance de visual c++
Posté par Alberto . Évalué à 7.
int f(int n)
{
int tab[n];
...
Il ne compile pas !
Pour les templates, le support de visual c++ est mauvais aussi. J'ai pas l'exemple sous la main mais les fonctions membres template etaient inutilisables.
Par contre visual c++ s'integre parfaitement dans l'environement windows ! Essayer de faire des dll activeX (composant windows) avec gcc.. et puis il a une "jolie" ide. (oui c'est le topic !)
Pour le test du groupe boost, cest pas une source fiable ! Je cite (Warning: These tables are not a good indication of a particular compiler's compliance with the C++ Standard....).
Mais sinon
www.boost.org/status/cs-linux.html
avec une version recente de gcc (3.0.1) il passe tous les tests ! (sous windows c'est une vieille version de gcc qui est teste et VC++ est deja a la rammasse deriere).
[^] # Re: non conformance de visual c++
Posté par kadreg . Évalué à 2.
int f(int n)
{
int tab[n];
...
Il ne compile pas !
Au bureau, on s'était déjà posé la question sur ce truc, et justement, il me semble que c'est gcc qui est en tord. Que lorsque l'on déclare un tableau de cette manière, sa taille doit être connue à la compilation. Quelqu'un a la norme sous la main pour trancher ? Moi je n'ai trouvé que ça :
http://www.ifrance.com/jlecomte/c++/c++-faq-lite/freestore-mgmt-fr.(...)[16.18]
et ça me sort une réponse de normand.
[^] # Re: non conformance de visual c++
Posté par Alberto . Évalué à 6.
Google search vla C9X !
[^] # Re: non conformance de visual c++
Posté par kadreg . Évalué à -4.
Ca fait deux fois que je me fait avoir sur C99, il va vraiment falloir que je la lise. La première étant la portée de déclaration de variables dans le for.
[^] # Re: non conformance de visual c++
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
[^] # Re: non conformance de visual c++
Posté par Alberto . Évalué à 3.
Le code est legal, le probleme s'est pose pour un fichier ".c" qui doit etre considere comme tel. D'autre part, je ne mettrais pas ma main au feu que "les VLA ne font pas parties du c++" (a verifier !).
VC++ implémente la norme Ansi c++ !
Tiens, juste un petit lien trouve au hasard sur les defailances de VC++:
http://yotam.freehosting.net/software/msviscxx/msviscxx.html(...)
[^] # Re: non conformance de visual c++
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Oui, et :
- c'est pas son boulot, c'est un compilo C++, et C99 n'est plus du tout aussi "compatible" avec C++ que ne l'était C89.
- je ne connais que gcc qui implémente C99, et encore partiellement :
http://gcc.gnu.org/c99status.html(...)
Mais bon, si ça peut te faire plaisir, oui, VC++ est un vilain méchant compilateur. Là.
D'autre part, je ne mettrais pas ma main au feu que "les VLA ne font pas parties du c++" (a verifier !).
Ils en font partie, simplement on ne le déclare pas comme ça :
int* foo = new int[n];
Ou plutôt std::vector<int> foo(n);
C'est quand même assez basique comme question C++, y a pas à chercher très loin pour trouver la réponse.
Tiens, juste un petit lien trouve au hasard sur les defailances de VC++:
Oh, surprise, y a des bugs dans VC++. Ben ça alors, je m'en serais jamais douté.
(pour info, je bosse sous Linux/g++).
[^] # Re: non conformance de visual c++
Posté par Alberto . Évalué à 1.
C'est different de
- int * t = new .. qui alloue de la memoire (sur le "tas") et donc tu devra etre responsable par la suite.
- et de std::vector qui declare une structure de tableau dynamique resizable.
Je n'ai jamais dit qu'il n'y avait pas d'equivalent. Mais les vla ne font pas partie du C++.
[^] # Re: non conformance de visual c++
Posté par Alberto . Évalué à 1.
[^] # Re: non conformance de visual c++
Posté par Vivi (site web personnel) . Évalué à 1.
Un compilateur C++ est supposé savoir compiler du C ? (moi je vois pas pourquoi)
«Visual C++ est mauvais pour le C Ansi.»
On peut en faire plein des comme ça : « mon compilateur Fortran est mauvais pour le C Ansi.» :-)
(d'ailleurs on parle plutôt de C ISO).
mauvais esprit, -1
[^] # Re: non conformance de visual c++
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Sans blague :
gcc -pedantic -ansi foo.c
foo.c: In function `main':
foo.c:5: warning: ISO C89 forbids variable-size array `foo'
C'est légal en C99, mais toujours pas en C++.
[^] # Re: non conformance de visual c++
Posté par Johann Deneux . Évalué à 2.
[johann@localhost tmp]$ gcc -ansi -pedantic-errors -c tst1.c
tst1.c: In function `f':
tst1.c:3: ANSI C forbids variable-size array `tab'
[^] # Re: interet d'une IDE sous Linux
Posté par kesako . Évalué à 10.
Je parle en connaissance de cause, ayant bcp eu a utiliser aussi bien VC++ que emacs+gcc+gdb.
Ceux qui ont un bon background de programation ( et qui ne sont pas faignants !) en font un bon usage mais les autres ...
J'ai eu a reprendre le travail de debutants (et meme de pas si debutants...), c'etait l'horreur.
Sans VC++ , les MFC auraient depuis lontemps disparues tellement elles sont mal foutues.
VC++ fabrique ou copie un tas de fichiers divers .Tu ne sais pas toujours tout ce qu'il faut sauver dans sourcesafe. resultat quand un quidam reprend le projet, ca merdoit dans tous les sens.
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à -4.
Pour gprof je ne sais pas, je n'ai jamais fait de profiling sous VC++, mais pour gdb désolé, c'est une daube moisie pour le C++. C'est pas seulement une question d'interface au dessus, le support du C++ est pathétique.
Pour le reste, tu as tout à fait raison. Linux est hélas très loin derrière Windows pour les outils de dev.
[^] # Re: interet d'une IDE sous Linux
Posté par Johann Deneux . Évalué à 4.
Par contre, gcc, make et compagnie se trouvent sur un peu toutes les plateformes.
Pour le support c++ de gdb, ca dépend beaucoup des versions de gcc et de gdb utilisées. Mais c'est vrai que j'ai pesté à de moultes occasions contre gdb en déboguant du c++ (les classes utilisant la STL sont illisibles, la STL elle-même est impénétrable).
[^] # Re: interet d'une IDE sous Linux
Posté par #3588 . Évalué à 1.
J'ai juste une question (enfin plusieurs, mais sur le meme point) :
Pour des exécutables sparc, est-ce que VC++ optimise aussi bien que le compilo CC de Sun ? Qu'en est-il pour d'autres processeurs ? Et idem pour le debuggage d'exécutables de ces plate-formes là ?
[^] # Re: interet d'une IDE sous Linux
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 5.
Apres avoir appris moins de 10 commandes, le seul interet qu'il reste a des outils tels que ddd, c'est de savoir afficher des tableaux, et encore...
pour vi, bon faut utiliser un outil en rapport avec ses ambitions, c'est tres pratique pour les petits ficheirs avec 2 modifs a faire, mais pour le reste, y a largement le choix .
Le class browser, ca c'est de la cochonnerie en boite. ca donne aux etudiants l'habitude de tout mettre dans un seul fichier!
1 fichier par classe et c'est bon
Tu gardes sous la main un .H imprimé et c'est bon.
Il faut oublier que programmer (et utiliser un ordi) c'est pas que cliquer a la souris, c'est lire la doc et comprendre ce qui se passe.
Moi j'aime bien c++builder, mais je me voie pas du tout developper un gros projet avec.
[^] # Re: interet d'une IDE sous Linux
Posté par C2RIK . Évalué à -1.
pour vi, bon faut utiliser un outil en rapport avec ses ambitions, c'est tres pratique pour les petits ficheirs avec 2 modifs a faire, mais pour le reste, y a largement le choix .
Je dirais même plus, vi est le meilleur éditeur pour perdre tout son boulot en 2 secondes...
Le class browser, ca c'est de la cochonnerie en boite. ca donne aux etudiants l'habitude de tout mettre dans un seul fichier!
Je trouve le class browser très pratique (voire utile), et je crois que ceux qui ont l'idée d'écrire toutes leurs classes dans un même fichier ont pris l'habitude de programmer avec VC++ et non C++ Builder (logiciel plus dans le sujet de la news que l'autre daube...). En effet avec C++ Builder, tu crées une nouvelle fenêtre, paf il te crée un nouveau fichier, tu dérives une classe d'un contrôle déjà existant, il te crée de nouveaux fichiers. Si avec ça tu prends l'habitude de tout regrouper, mieux vaut arrêter le C++, la modularité n'est pas pour toi !
Le développement d'un gros projet en C++ Builder ne m'a pas posé de problème, il suffit de bien séparer éléments de l'interface et classes de traitements, et de dériver des contrôles pour les adapter à ces classes.
[^] # Re: interet d'une IDE sous Linux
Posté par togno . Évalué à -4.
Ouai, c'est comme rm, c'est vachement dangereux rm. Ca peut effacer tout ton boulot en 2 scd ...
[^] # Re: interet d'une IDE sous Linux
Posté par C2RIK . Évalué à 2.
~$whatis rm
rm (1) - remove files or directories
~$whatis vi
vi (1) - text editors
[^] # Re: interet d'une IDE sous Linux
Posté par pasBill pasGates . Évalué à 4.
En gros t'utilises ca et tu crees une nouvelle classe tres facilement, ca encourage les neuneus a l'utiliser, et ca cree 1 fichier par classe.
[^] # Re: interet d'une IDE sous Linux
Posté par Alberto . Évalué à 0.
[^] # Re: interet d'une IDE sous Linux
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
[^] # Re: interet d'une IDE sous Linux
Posté par Stéphane Salès . Évalué à 2.
ceci était valable sur les toutes premières versions de vi qui,si mes souvenirs sont bons,fesaient environ 2ko.
combien fait vc++ ?
[^] # Re: interet d'une IDE sous Linux
Posté par reno . Évalué à 2.
En regle générale tu ne peux pas vraiment avoir puissance (vi/emacs) et facilité d'utilisation (nedit).
Vim et xemacs sont des bon compromis..
Pour le manque d'IDE, je sais qu'il y a KDevelop mais je ne l'ai jamais utilisé.
C'est surtout une question d'habitude: au boulot j'ai utilisé Sniff sur un gros projet, ça ramait tellement que à la fin, dégouté je suis retourné vers vim, honnetement a part une periode d'adaptation (il est où déja ce header?), j'ai trouvé ça bien plus confortable..
[^] # Re: startégie
Posté par Johann Deneux . Évalué à 0.
Avoir plusieurs compilos, c'est toujours un plus pour apprendre à coder proprement.
[^] # Re: startégie
Posté par Jean-Yves B. . Évalué à 4.
C'est vrai que c'est un plus pour apprendre à coder du multi plate-formes avec duplication des fonctions (implantées de manières différentes selon la cible) et les config fun qui vont avec (autoconf et ses amis (sauf libtool qui est un grand méchant)).
[^] # Re: startégie
Posté par François ROBERT . Évalué à 1.
Delphi/Kylix/Pascal objet est un tres bon produit qui maintenant n'a plus rien à envier (au niveau rapidité) à C++, et en plus le code est 100 fois plus clair que n'importe quel programme fait en c++ desolé... Je connais les deux langage et j'ai une nette preference pour le pascal objet.
Le portage de Borland suit une stategie de s'ouvrir au monde linux et de permettre aux entreprise de s'engouffrer dans cette ouverture (la preuve ma boite va porter ses programme sous linux via Kylix pour permettre à nos client de laisser tomber microsoft)... De plus même si les source de kylix ne sont pas libre, cela ne nous empechera pas de mettre une partie de nos source en l;icence GPL (j'y travaille)...
Alors que Borland s'oriente vers Linux est une action que j'applaudis des 2 mains... Même s'il reste du chemin à parcourrir jusqu'a la libération des sources...
Cordialement...
# c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Annah C. Hue (site web personnel) . Évalué à 0.
Après nous avoir rameuté les neuneus qui faisaient du pascal, on va enfin avoir des types qui font du c++ sans toucher une seule fois au clavier. Cool.
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Jean-Yves B. . Évalué à 4.
-1, ;)
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Annah C. Hue (site web personnel) . Évalué à 3.
Mais il faudra le mettre sous une licence qui nous permette d'aller voir le disque dur des utilisateurs...
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Jean-Yves B. . Évalué à 4.
'Faut demander à Borland® justement. Il parait qu'en laissant 1000 chimp^Wjuristes taper à la machine, ils ont fait une licence comme ça par erreur. ;)
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Stephane JUTIN . Évalué à -7.
Par ailleurs, j'ai déja vu des développeurs "C" sous "vi" qui étaient persuadé qu'en C++ il y'a un garbage collector : je doutes que leur maitrise des templates, du RTTI, et du mot-clé "mutable" soit l'égale de leur maitrise des raccourcis claviers de "vi"
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par kadreg . Évalué à -1.
Question bête, tu l'a essayé dans quelle condition ton vi ?
La dernière fois que j'ai eu à utiliser vi dans cet état, c'est il y a très longtemps, et encore, c'est parceque le telnet supportait pas mes fleches.
Aujourd'hui, tu peux utiliser les fleches en mode édition, il y a la coloration syntaxique aussi.
Mais moi, je garde mon emacs, j'en ai besoin pour piloter ma cafetière
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par pas_moi . Évalué à 8.
et??? Moi j'ai déjà vu des momes qui croyaient au Père Noël...
Tous ceux qui critiquent vi sont ceux qui ne le connaissent pas assez ou qui croient que quand on a un outils il faut toujours s'en servir («quand le seul outils que l'on possède est un marteau, on a tendance à voir les problèmes comme des clous» disait je ne sais qui). Personnellement, je développe sous XEmacs, et j'édite les fichiers de conf (ou les petites modifs dans les sources) à l'aide de vim... J'ai une connaissance assez médiocre des techniques de la mort de chacun de ces outils, mais je sais à peu près quand utiliser l'un ou l'autre.
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
En tant que "neuneu" comme tu le dis si bien, je ne suis pas persuadé que savoir taper "h" au lieu de "touche fléché haut" pour faire avancer le curseur d'un ligne, soit un apprentissage nécessairement utile ...
oui c'est bien, mais je ne sais pas d'où tout sort que j'ai dit qu'il fallait connaitre la touche h (qui va à gauche avec vi).
Par ailleurs, j'ai déja vu des développeurs "C" sous "vi" qui étaient persuadé qu'en C++
Moi j'ai vu des développeurs Visual C++ sous windows qui étaient plus nuls que moi en c++ alors que je ne développe pas. A part utiliser les MFC, c'est gars là ne valent RIEN en programmation, ils ne savent pas résoudre correctement un problème algorithmique tous seuls. Et ça j'en ai vu des tonnes, des développeurs windows. Y'en a surement des très bons, mais c'est loin d'être la majorité.
Heureusement, personne n'a attendu borland pour sortir un environnement de développement sous linux digne de nom. il suffit de voir le nombre de programmes GPL développés uniquement avec les outils GNU. Quand Borland en aura autant a son actif, on en reparlera.
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Stephane JUTIN . Évalué à 0.
Je reconnais que les arguments du style "j'ai déja vu des gens qui" sont un peu facile, en même temps je ne t'ai pas beaucoup entendu critiquer le niveau du post auquel je réponds (neuneus... types qui font du c++ sans toucher une seule fois au clavier ...).
Je luttais donc simplement contre l'affirmation "programmeur windows = incompétent en C++", en rappelant le fait que l'on trouve beaucoup plus de programmeur C only sous Unix que sous Windows.
A part utiliser les MFC, c'est gars là ne valent RIEN en programmation
Encore la fameuse idée reçue programmeur windows = neuneu.
Pour utiliser les MFC il faut au minimum maitriser les concepts principaux de C++ : classe, héritage, voir même template (ATL). Si c'est cela que tu appelle, ne rien connaitre en programmation ... que dire d'un développeur GTK par exemple qui ne maitrise que le C
Et même si moi maintenant je répugne à faire de l'arithmétique de pointeur à tout craint car je trouve cela illisible et plus difficile à maintenir, je l'ai déja fait dans le passé et je pourrais le refaire si je voulais.
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par icyfemur . Évalué à 1.
Delphi est un outil tres pratique et le langage qu'il y a derriere est très agréable à utiliser, et n'a rien a envier au C++.
C'est tres dommage que l'on ne puisse pas coder les applis QT/KDE en Pascal, je pense que un certain nombre de personnes s'y interesseraient de très pres.
Par contre, à propos de Kylix, je l'ai eu entre les mains, mais j'ai jamais réussi a faire fonctionner une appli en dehors de l'EDI (erreurs de librairies...).
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par vrm (site web personnel) . Évalué à -3.
[..]
j'ai jamais réussi a faire fonctionner une appli en dehors de l'EDI
C'est ça un neuneu :)
Hop -1 (même pas honte)
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Même pas un standard ISO, ou de quoi faire de la POO ?
Pascal est mort. Delphi je veux bien, mais Pascal...
[^] # Re: c++ sous linux ? enfin depuis le temps qu'on l'attendait
Posté par Jean-Noël Avila . Évalué à 0.
simple problème de librairies à placer aux bons endroits. C'est documenté dans les FAQ.
Sinon, tout à fait d'accord avec toi. <TROLL> Pascal Rulez </TROLL> et le dernières versions de l'IDE de Borland, associé avec un framework d'objet bien pensé permettent le développement d'applications en un temps record.
Cette vitesse de développement est surtout attribuable à Pascal. La version objet est limpide, ce qui n'est pas le cas du C++...
# impatience ???
Posté par deubeuliou . Évalué à -1.
pas moi... j'ai déjà gcc !!!
[^] # Re: impatience ???
Posté par kadreg . Évalué à 10.
[^] # Re: impatience ???
Posté par Bouchet Thierry . Évalué à -1.
--
La roue tourne, et pourtant le hamster est mort.
# il sont fou!
Posté par ccuche . Évalué à -4.
Il ont deja JBuilder.....en plus gcj c'est pas si mal. Si c'etait du C y aurait rien a redire, mais faut etre fou pour encore faire du C++!!!
Moi, je serait content quand on poura faire du Smalltalk80 sous linux avec gtk+ et le framebuffer :-B
[^] # Re: il sont fou!
Posté par kesako . Évalué à -5.
faut etre fou pour faire une interface graphique en C (comme gnome) et non en C++ (comme kde/qt)
[^] # Re: il sont fou!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
- le C++ est le seul langage objet rapide, c'est déjà un intérêt énorme ;
- Gnome, bien qu'écrit en C, n'a rien à envier à KDE, je trouve (à part son file manager, peut-être) ; alors, c'est si pourri que ça le C ?
Franchement, faut être psychopathe pour faire du Java. Si au moins ça marchait correctement.
[^] # Re: il sont fou!
Posté par bad sheep (site web personnel) . Évalué à 6.
D'ailleurs, il me semble qu'il y a bcp moins de dev KDE que GNOME, or, KDE est + avancé (ça, c'est indéniablen, même si ils ont comméncé avant)... donc à mon sens, le C++ et les extensions trolltech (les signaux) FONT VRAIMENT GAGNER du temps en matière de dev... je te parle même pas de la réutilisation du code 1000 fois plus importante qu'avec GNOMR. Les langages objets sont très adaptés à la réutilisation, le C, bcp moins.
[^] # Re: il sont fou!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
C'est un pur troll. Je ne te parlais pas de KDE en tant qu'environnement de développement, mais en tant que bureau avec des applications. Et non, l'environnement Gnome n'a pas grand-chose à envier à KDE. C'est bien la preuve qu'on peut faire de très belles choses en C (même si personnellement, j'utiliserait autre chose pour faire une interface graphique).
[^] # Re: il sont fou!
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Essaie de développer une appli pour les deux, tu verra si tu restes du même avis.
alors, c'est si pourri que ça le C ?
Non, c'est juste que c'est vraiment pas dur de trouver mieux.
Franchement, faut être psychopathe pour faire du Java. Si au moins ça marchait correctement.
Ça marche correctement (moins sous Linux, où on n'a pas vraiment de bonnes implémentations), et les stats montrent que tu développes 3 fois plus vite avec qu'en C++.
[^] # Re: il sont fou!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Et qu'en Python ?
[^] # Re: il sont fou!
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Le problème, c'est qu'aucun des deux n'a derrière lui le quart du support qu'a Java (doc, extensions, etc...).
[^] # Re: il sont fou!
Posté par reno . Évalué à 0.
Parce que au niveau du nombre de bugs dans les librairies et du temps mis pour les corriger, Sun n'etait (est?) pas vraiment top.
Je me souviens entre autre:
* le Garbage Collector du JDK1.1.7 avait un bug fun: il supprimait des objets encore actif (ne prenait pas en compte les références statiques)
* le JDK1.2 était completement nul pour ce qui est d'imprimer..
Bref, Java c'est super sauf quand tu t'en sert!
[^] # Re: il sont fou!
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
# Vive les bons Clickodromes
Posté par Jérôme Bataille . Évalué à 5.
Moi qui vous parle, gcc j'adore, le libre n'en parlons pas,
les initiatives et le temps consacré par ses émules m'époustoufle.
J'ai roulé un peu ma bosse dans le monde microsoft et dans le monde Unix.
Et j'ai fait un peu le tour des outils d'IDE (les clicodromes).
Il faut dire que les outils proposé par le monde libre existent, mais ils sont
encore jeunes (Je pense à Kdevelop, mais il y en a beaucouop d'autres).
Cependant il faut reconnaitres les bon outils quand on en voit passer (c'est très rare).
Et malheureusement ce ne sont pas les meilleurs qui remportent le plus de succés.
Je pense à BeOS, OS/2, Camel ou Ada par exemple.
Je ne vois pas pourquoi sous prétexte que des outils sont commerciaux on ne devrait pas les couronner.
Or Delphi, C++ Builder, et Kylix sont de l'engence des outils que l'on peut couronner.
Ces outils reposent sur un principe bien connu du monde Unix:
assembler des petites choses (des programmes), qui font leur petit boulot dans leur coin,
mais bien.
Les petites choses des outils Borland ce sont les composants (ceux qu'on pose sur une fiche en
faisant click-click).
Après la programmation c'est du légo, et que je te relie tel composant avec tel autre,
et que je remplis telle propriété.
Les Composants ne font que ce que l'on demande de faire. Il sont bien dressés.
Je n'ai jamais vu de propriétés d'un composant Borland qui n'avaient rien à faire là.
Les seuls contre exemples à ceci sont les anciens composants réseau qui étaient un peu cafouilleux.
Il existe bien sur des composants privés, car il est tout à fait possible de créer les
siens (ce n'est pas très compliqué). Et là, libre à soi de faire n'importe quoi,
mais quand même un certain formalisme fait office de garde fou.
Le 2ème intéret de ces outils c'est que la programmation que l'on ajoute derrière les composants
permet un contrôle total et parfait de l'application.
Une fois le modèle événementiel compris (c'est un apprentissage peu simple il est vrai),
on programme vite et très bien.
Pour résumer: d'abord on fait click-click avec l'interface, et puis ensuite on code pour de vrai.
Forcément, puisque les interfaces des composants sont affichées devant vos yeux dans l'inspecteur
il est difficile de faire du code plus clair, on écrit dans telle méthode qui réponds à tel événement
de tel composant.
Le 3eme intérêt de Kylix et des outils Borland et C++ Builder est la portabilité Windows / Unix.
Les 2 mondes font beaucoup de tentatives pour se rapprocher, et souvent elles sont réussies.
Mais beaucoup de guerres subsistent encore, l'homme est comme cela.
Or, Kylix c'est quand même un pont énorme entre les deux mondes.
Qui permettra de gagner beaucoup de temps sur le portage d'une application (que ce soit dans un sens ou dans l'autre).
Alors, pour ceux qui n'ont pas encore gouté, essayer vous allez peut-être apprecier ;-)
[^] # Trollons joyeux
Posté par Toufou (site web personnel) . Évalué à -2.
Pas ceux de la VCL qui est une grosse bouse truffée de bugs. Et le peu que j'ai testé de CLX m'a fait revenir à la VCL.
[^] # Re: Trollons joyeux
Posté par Jérôme Bataille . Évalué à -2.
[^] # Re: Trollons joyeux
Posté par Toufou (site web personnel) . Évalué à -2.
Sous CLX pour windows, il faudrait que je retrouve mon test pour trouver des exemples. Et puis, quitte à faire du QT, autant en faire du natif, non ?
La présence de Kylix et BCBuilder dans le monde Linux-pour-PC ne va certainement pas révolutionner le monde du libre/open source, d'autant plus qu'il existe des IDE (comme KDevellop ou Lazzarus) qui promettent nettement plus et qui ne sont pas liées à un toolkit ou à une architecture. Certes, elles ne sont pas finies, mais bon, celles de borland non plus (pas plus que VB de MS, je ne connais pas VC++). Kylix et Lazzarus, au moins, ont un avenir et bénéficient d'un avantage énorme: c'est au minimum de l'Open Source.
[^] # Re: Vive les bons Clickodromes
Posté par Jar Jar Binks (site web personnel) . Évalué à -4.
Si j'ai bien compris, on doit décrire la structure de son programme dans l'ensemble avant d'avoir écrit quoi que ce soit ?
C'est vraiment n'importe quoi.
Allez -1, feed the troll.
# Vous avez vraiment une drole de mentalite !
Posté par Samuel Pajilewski . Évalué à -6.
Franchement traiter de neuneus les gens qui v*codent avec un IDE C++ ne fait pas avancer les choses.
J'entends parler de VI. Encore une betise. VI c'est bien pour de petits projets mais quand faut pisser 10 000 lignes de code en 2 mois (cahier des charges oblige) et bien on est content d'avoir des trucs comme Kylix, C++ Builder ou Forte Java.
GCC meilleur compilateur au monde : encore une Betise : Le compilateur Kylix est 2 fois plus performant (CF Test GCC vs Compilateur Kylix).
Faut arreter les conneries les mecs : meme si moi meme j'adore les ecrans noirs avec ecriture grises, je suis heureux d'avoir des environnement graphiques performants meme si ils m'enervent un peu...
[^] # Désolé, je crois que je vais nourrir le troll...
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
Ça dépend ce que signifie « intégriste ». Si c'est condamner d'un bloc les logiciels propriétaires, je crois que tu te trompes de cible.
Si c'est condamner d'un bloc le logiciel propriétaire, alors oui, je suis intégriste et indécrottable. Mais ça ne m'empêche pas de trouver quelques logiciels propriétaires très réussis... dommage qu'ils ne soient pas libres.
Franchement traiter de neuneus les gens qui v*codent avec un IDE C++ ne fait pas avancer les choses.
Ça ne fait peut-être pas avancer les choses, mais c'est le cas. Un IDE pour la programmation, c'est comme un traitement de texte WYSIWYG (c'est même pire) : ça ne sert à rien, juste à attirer l'oeil du neuneu devant.
J'entends parler de VI. Encore une betise. VI c'est bien pour de petits projets mais quand faut pisser 10 000 lignes de code en 2 mois (cahier des charges oblige) et bien on est content d'avoir des trucs comme Kylix, C++ Builder ou Forte Java.
Dis-moi, tu connais emacs ? Ça a justement été écrit pour ça (entre autres).
GCC meilleur compilateur au monde : encore une Betise : Le compilateur Kylix est 2 fois plus performant (CF Test GCC vs Compilateur Kylix).
Tu compares gpc et kylix, là, je suppose. Parce que comparer un compilateur C à un compilateur Pascal, faut le faire.
Ensuite, que signifie un compilateur 2 fois plus performant ? 2 fois plus rapide à compiler ? à exécuter ? 2 fois plus économe en mémoire ? en taille d'exécutable ? 2 fois plus portable (OUUUUUPS !) ?
Enfin, je ne pense pas que gpc soit particulièrement optimisé, parce que plus grand-monde n'a besoin du pascal, et subséquemment plus grand-monde ne bosse dessus (et franchement, on s'en fout du pascal).
Faut arreter les conneries les mecs : meme si moi meme j'adore les ecrans noirs avec ecriture grises, je suis heureux d'avoir des environnement graphiques performants meme si ils m'enervent un peu...
Faut voir pour quoi faire. Un clickodrome comme navigateur web, comme lanceur d'applications ou comme gestionnaire de fichiers, c'est génial. Mais croire que les interfaces peuvent tout résoudre est une pure illusion.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par pasBill pasGates . Évalué à 6.
Mon dieu ce qu'on peut lire comme conneries des fois ici...
Petit exemple de l'utilite d'une IDE:
Tu tapes sous VC++ :
MyClass NewInstance(3,4,6);
NewInstance.
---> Et la oh miracle, il te montre toutes les methodes et les donnees membres de la classe, plus besoin de se casser les burnes a retourner dans l'autre fichier voir ce que c'est, et une fois que t'as tape le nom de la methode, oh miracle encore, il te montre quels parametres sont necessaires et leur type, quand tu vois les noms des parametres ca t'evite de les mettres dans le mauvais ordre(genre le nom du directory a la place du filename et autres, ce qui est un bug, ca ne se voit pas a la compilation), etc...
Ca c'est HYPER utile, ca evite de perdre du temps a chercher le nom de la methode, a se souvenir du type de parametre, a compiler 3 fois parce que tu t'es gourre en tapant, etc...
On peut aussi parler de cette magnifique fonction qui permet de voir tous les endroits d'ou une fonction est appellee, chose ENORMEMENT utile quand tu modifies quelque chose.
Et ce n'est qu'un exemple parmis bien d'autres.
Voila, toi tu t'amuses avec ton petit editeur de texte, moi avec une IDE de mon choix, on code le meme soft et je te paries que je le termine bien avant toi, et probablement avec moins de bugs.
Non faut arreter de delirer quand meme, les IDE c'est un gain de temps ENORME.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
Hop, un petit grep (voire un sed dans les cas simples), et c'est tout bon.
Dans une application en plein développement, ce cas m'arrive à peu près aussi souvent que le précédent (et c'est beaucoup, beaucoup plus chiant à la main.
En plus, pour ton cas, emacs a un browser de classes qui doit faire à peu près la même chose, mais je ne vais pas m'avancer, je ne l'utilise pas (le browser, hein, emacs il faut être fou pour ne pas l'utiliser).
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par pasBill pasGates . Évalué à 9.
T'arrives a trouver toutes les occurences avec le grep, maintenant pour changer les parametres automatiquement, ben tu m'expliqueras comment tu fais vu que tu donnes des parametres differents selon les endroits(notamment les fonctions avec des parametres par defaut).
Et pour ca, ben moi je vais dans Edit -> Find in Files, j'entre mon expression et hop dans la fenetre du bas j'ai toutes les entrees, je cliques sur chacune et je suis dessus, je peux changer les parametres.
Notes qu'il y a surement des trucs qu'un IDE ne peut pas faire et que d'autres outils peuvent faire, le miracle etant que tu peux tout a fait utiliser les 2 en meme temps histoire d'avoir les avantages des 2.
Une IDE c'est un avantage ENORME, ca fait pas le cafe et le beurre, mais il est TRES clair qu'un dev avec une IDE est plus efficace que sans.
Quand a emacs, ben justement emacs + browser de classe c'est deja un IDE, basique certes mais c'est un IDE.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
Avec sed (ou la fonction équivalente d'emacs), j'ai dit. Demande à Dae si tu veux un cours.
Cela dit, c'est quand même pour les cas bourrins, en général remplacer les occurences avec les fonctions d'emacs suffit largement.
Pour le reste, je ne suis pas d'accord, mais ton point de vue se défend tout à fait.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Ce que la plupart des IDEs avec de bonnes features de refactoring savent très bien faire, on en a testé quelques uns avec des potes au boulot il y a deux jours :
http://www.refactoring.com/#tools(...)
Et y a bien un mode emacs qui aide un peu pour ça, mais c'est pas exactement ce qu'il y a de plus commode.
Hop, un petit grep (voire un sed dans les cas simples), et c'est tout bon.
Euh, tu as vraiment déjà appliqué ce dont tu parles ? :-)
Comme le souligne pasBillGates qui a parfaitement raison pour le reste, grep ne va pas beaucoup t'aider pour modifier un texte. sed un peu plus, mais pour "changer les paramètres" d'une fonction dans du code, tu peux t'accrocher. Pour faire ça de manière fiable il faut sortir un vrai parser, pas un truc "line oriented".
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à 1.
Petit exemple de l'utilite d'une IDE:
(...)
Ca c'est HYPER utile,
Il était plutot question des IDE style Borland par rapport à ceux qui existent déja sous Linux.
Tu n'as pas tort avec ton exemple, mais ça se fait déja avec Emacs (j'ai pas utilisé, je sais que ca existe au moins pour Java). De ce coté là les outils ne manquent pas.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par pasBill pasGates . Évalué à 1.
Mon propos n'est pas de dire que VC++ est mieux que xyz ou que il manque xyz a Linux, mon propos c'est : Une IDE c'est d'une utilite enorme pour programmer, et je vois ca tous les jours au boulot.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par kesako . Évalué à 1.
Pour programmer des trucs que microsoft veut te voir programmer (MFC, ActiveX,...) oui. On est pratiquement force de passer par la. Pour les IHM aussi (cf Glade, KDevelop,...), ca va plus vite mais sans etre absolument indispensable ( sauf pour les MFC !).
Pour faire un appli classique genre serveur ou librairie , ca n'a strictement aucun avantage.
Comme d'autre l'ont dit dans cette news, si tu connais bien emacs, gcc et gdb tu fais aussi bien sinon mieux. Et perso, je dirais beaucoup plus propre.
L'important c'est d'avoir apris a programmer *sans* IDE pour bien comprendre ce qu'il fait et bien en tirer parti. Malheureusement c'est de moins en moins le cas en dehors du monde unix et opensource.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par pasBill pasGates . Évalué à -1.
La partie Wizard pour creer des GUI ce n'est qu'une partie de l'IDE.
J'ai l'experience des 2 XEmacs et une IDE(VC++), il n'y a pas photo, l'IDE est bien plus efficace.
Rien que l'exemple du dessus(avoir les noms des methodes, les parametres et leur type, le class browser...) montre l'utilite enorme d'une IDE, ca evite de perdre tu temps a aller regarder dans 4 fichiers differents, ca evite de recompiler 5 fois apres s'etre trompe de parametres, ca evite les bugs ou tu melanges 2 parametres du meme type dans l'appel de fonction car tu les as mis dans le desordre, etc...
Je passes mes journees a programmer depuis un bon moment, et c'est plus que flagrant, une IDE j'aurais un mal certain a m'en passer maintenant tellement c'est pratique.
Faut pas confondre IDE et Wizards, l'un(les wizards) est compris dans l'autre, mais une IDE c'est bien plus que ca.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à 0.
Si c'est pas du troll ça.
Alors l'IDE est plus efficace, certes, mais de quelle IDE parles-tu ? VC++, Emacs, ou XEmacs ?
Comme je l'ai dit, ton exemple n'est pas propre à VC++. J'ai un collègue qui a ça sous Emacs quand il fait du Java.
Maintenant tu peux comparer les fonctionnalités entre IDEs, mais c'est pas gagné parce que :
- l'IDE n'est pas forcément un outil unique, ça peut etre un ensemble de quelques outils
- il faudrait connaitre parfaitement chaque IDE pour pouvoir prétendre les comparer.
Faut pas confondre IDE et Wizards, l'un(les wizards) est compris dans l'autre, mais une IDE c'est bien plus que ca.
Tu fais bien de mettre en garde contre les confusions. Faudra penser à faire la différence entre éditeur de texte et IDE aussi.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Oui, il y a bien quelques modules (x)emacs qui font ça plus ou moins bien, mais ça reste très en dessous d'un bon IDE. En plus, comme tu le soulignes ces modes ne sont que pour Java. Pour C++ il n'y a rien, à par speedbar qui n'est pas vraiment comparable (normal, le langage est beaucoup plus dur à parser).
Mais bon, est-ce bien la peine de discuter...
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à 0.
Effectivement il y a toujours des améliorations à réaliser. Ce n'est d'ailleurs pas réservé à (X)Emacs.
Mais bon, est-ce bien la peine de discuter...
Quand je vois que certains vont jusqu'à prétendre qu'(x)emacs n'est pas un IDE (c'est le point sur lequel je répondais), c'est clair qu'ils n'ont pas l'intention de discuter. Quelqu'un de disposé à comparer des fonctionnalités, des solutions, ne l'aurait pas affirmé, et aurait dit qu'il manque telle ou telle chose dans les IDE existantes.
Pour ce qui est des modes Java, je sais pas, j'ai pas utilisé moi-meme. Celui qui m'en a parlé n'as pas cet avis, il n'échangerait pas contre un IDE à la Borland, faudrait voir où en sont ces modules. Si c'est absent des modes C++, là oui c'est clairement un manque. Ce qui est surprenant, c'est qu'avec tout ce qui existe déjà, ce ne soit pas déja fait : ca donne plutot l'impression que les développeurs ne sont pas convaincus par cette manière de faire, et qu'ils choisissent d'autres solutions, équivalentes. Ils peuvent très bien etre aussi à l'aise et efficace avec ces outils qu'avec des IDE à la Borland. Ca dépend un peu de chacun, on peut etre hermétique à certains outils, etre efficace avec ou pas. Donc effectivement, il manque certainement des outils à la Borland, pour ceux qui ont absolument besoin de ce genre d'outil.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à -2.
XEmacs est un très bon éditeur de texte et je suis d'accord pour dire qu'aucun IDE, à ma connaissance, ne dispose d'un editeur aussi puissant qu'XEmacs. Mais ça n'est pas un IDE. Il manque beaucoup trop de choses pour ça.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à 0.
Mais Emacs + modules qui vont bien, en est un. Et une partie de ces modules là sont présents par défaut. En fait, pasBill s'est mal exprimé dans le post auquel j'ai répondu, et comme il l'a dit ailleurs, emacs est un IDE, meme basique, dès lors qu'il a certaines fonctionnalités caractéristiques d'IDE. (browser de classes...). Il est de toutes facons clair qu'il propose largement plus que ce qu'étaient les premiers IDE. Alors on peut comparer les fonctionnalités, mais dans tous les cas on a affaire à des IDE. A moins que tu aies ta propre définition d'IDE dans laquelle il faudrait absolument telle ou telle fonctionnalité, et qui sera forcément subjective (parce que de la meme manière, je pourrais dire que les IDE qui n'interfacent pas CVS aussi bien qu'Emacs ne peuvent pas etre considérés comme de vrais IDE)
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Non. Ou alors un vraiment très mauvais. Y a pas de project builder, pas de gestion des options passés au compilo et au link, pas de bon browser de code, pas de complétion intelligente, pas d'info dynamique pour avoir le proto de la méthode dont tu viens de taper le nom, etc...
Bon, je laisse tomber, ça devient vraiment puéril.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à 1.
Très mauvais si tu veux, selon tes critères, tes besoins.
Mais avoir une arborescence de classes, des méthodes, cliquer sur le nom de l'une d'entre elles et voir sa définition dans une fenetre pendant qu'on code dans une autre, c'est pas une fonctionnalité de base d'un éditeur de texte. De meme que compiler dans une fenetre et mettre en surbrillance les lignes d'erreur dans le code. C'est basique, mais c'est une des bases des IDE. Tu as d'autres exigences, mais la catégorie n'a rien à voir avec la qualité. Pour ce qui est du controle de versions, à moins qu'il y ait eu d'énormes progrès, emacs est meilleur que la plupart des IDE.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Non, mais c'est une fonctionalité de base d'un IDE, et, pour la N-eme fois, contrairement à ce que tu soutiens, XEmacs n'est pas un IDE. Content de voir que tu arrives enfin à assimiler ce concept.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à 1.
> Non, mais c'est une fonctionalité de base d'un IDE,
Exactement, et c'est bien pour ça que j'en ai parlé puisque c'est une fonctionnalité d'Emacs. Tout comme le controle de versions, le suivi de la compilation, etc.
pour la N-eme fois, contrairement à ce que tu soutiens, XEmacs n'est pas un IDE.
Toujours selon ta propre définition, pour laquelle on n'a toujours pas de critères. Emacs possède donc les fonctionnalités de base d'un IDE mais n'est pas un IDE ? Tu devrais etre plus explicite dans ta définition d'IDE parce que la différence est vraiment subtile alors.
Content de voir que tu arrives enfin à assimiler ce concept.
Arf, pour avoir mal compris à ce point là, faut vraiment que tu connaisses mal Emacs, c'est à dire uniquement en tant qu'editeur. Si ce n'était que pour faire de l'édition, on ne prendrait pas Emacs mais un autre éditeur, plus léger, plus puissant (et très connu). Si on se sert d'Emacs pour développer, c'est pour l'environnement, l'IDE, pas pour l'éditeur, qui est bien mais pas le meilleur.
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Tu n'as pas du lire le post dans lequel je dis que j'utilise Emacs ou XEmacs depuis à peu près 10 ans. J'ai même contribué du code à l'un de ces modules dont on parle, func-menu :
Cherche "glaurent" dans cette page, tu trouvera mon ancienne adresse sur worldnet :
http://www.mit.edu/afs/athena/contrib/xemacs/lib/xemacs/xemacs-pack(...))
Crois-tu vraiment que je "connais mal Emacs" ?
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par #3588 . Évalué à -1.
Alors ne fait pas semblant de ne pas connaitre les fonctionnalités existantes, comme celle que je donnais, concernant l'affichage des classes et des méthodes. Si tu connais très bien Emacs, tant mieux pour toi. Si tu fais semblant de ne pas connaitres ses fonctionnalités essentielles, tu perds toute crédibilité. C'est de la mauvaise foi juste pour le plaisir de dénigrer ? Quand je vois ça effectivement, c'est pas la peine de continuer.
-1 (et /ignore troll)
[^] # Re: Désolé, je crois que je vais nourrir le troll...
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Oui, là, je suis un gros vilain troll qui aime rien qu'a dire du mal du gentil Emacs. Ça te va comme ça ?
[^] # un IDE c'est bien, mais des bonnes libs c'est encore mieux, et de loin
Posté par tanguy_k (site web personnel) . Évalué à 4.
Pour le C, gtk est tout de même a des années lumières du Win32SDK
Pour le C++, QT est bien mieux foutu que les MFC
En gros je préfère très largement ne pas avoir d'IDE ou un IDE limité et utiliser gtk ou QT
que d'utiliser Visual et de devoir coder en MFC et encore pire en SDK.
J'ai pas essayé Borland C++ mais tous ceux qui l'ont utilisé ne peuvent plus piffrer le developpement avec les libs de Visual, exactement comme moi :)
[^] # Re: un IDE c'est bien, mais des bonnes libs c'est encore mieux, et de loin
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
C'est quand même curieux a quel point chaque fois qu'on parle d'un truc ou Linux n'est pas champion, il y en a toujours qui se mettent la tête dans le sable et cherchent tous les arguments possible pour ne pas avoir à admettre le problème.
[^] # Re: un IDE c'est bien, mais des bonnes libs c'est encore mieux, et de loin
Posté par tanguy_k (site web personnel) . Évalué à 5.
c'est évident et j'ai jamais dit le contraire.
il y en a toujours qui se mettent la tête dans le sable et cherchent tous les arguments possible pour ne pas avoir à admettre le problème.
J'ai jamais dit que Linux était parfait et n'avait pas de problème.
Mais dans ce domaine, Visual est loin d'être la panacé, je comprendrais jamais les gens qui programment avec cette bouse, le seul truc de bien c'est la complétion. Les MFC et le SDK c'est de la merde en boite.
Pour les IDE sous linux il y a KDevelop, KDEStudio, Anjusta, CodeWarrior et surement pleins d'autres qui doivent supporter la comparaison avec Visual au niveau facilité et puissance de l'interface.
C'est sur que si les gens developpent depuis plusieurs années sous Visual ca doit être dur de changer. Moi j'ai commencé avec Visual + SDK et je regrette largement pas d'avoir abandonnée cette merde de SDK. C'est comme si sous unix on utilisait encore les libs X11 pour faire des logiciels en mode graphiques.
[^] # Re: un IDE c'est bien, mais des bonnes libs c'est encore mieux, et de loin
Posté par sam Sho . Évalué à 1.
hum, le vilain bouh le vilain (je me demande si je vais pas faire une interface en asm pour l'embeter lui...) ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.