C et C++ permettent d'avoir plus de contrôle sur le matériel
C et C++ vous permettent d'écrire du code très efficace
Les langages C et C++ sont portables
C et C++ sont des langages qui évoluent
C et C++ sont largement utilisés
C++ a peut-être de l'avenir, mais je doute que ça soit le cas de C
C a peut-être de l'avenir, mais je doute que ça soit le cas de C++
Je pense qu'ils n'ont plus beaucoup d'années devant eux
Autre (à préciser)
Pas d'avis
Par exemple, avec C++ Builder, on a des mots-clefs qui n'existent pas en C++ standard, comme __property et __finally.
On a aussi des restrictions spéciales qui n'existent pas dans le C++ standard. Par exemple, quand on essaie d'instancier une variable automatique dont le type (appelons-le X) dérive d'une certaines classe TObject, alors on a une erreur de compilation, même si le constructeur de X est public. Par contre, si on alloue dans la mémoire dynamique en écrivant new X, ça compile.
En Qt, on a le moc (Meta-Object Compiler) qui, avant le préprocesseur, parse le code C++ et prend en compte les macros spéciales de Qt (par exemple signals, que le préprocesseur transformera en protected) pour générer des fichiers cpp supplémentaires, avec un préfixe "moc_". Après cette phase préliminaire, le tout peut être compilé par un compilateur qui respecte le standard C++.
Edit : changement de l'hyperlien de __property.
Non, malheureusement, une bibliothèque "à la C++" et une bibliothèque de composants réutilisables, cela n'a rien à voir. Si la bibliothèque suffisait, on aurait arrêté toutes les évolutions de langage, en particulier sur ce langage Java qui prétendait être "C++ sans les ennuis du C++"... Et C++Builder n'aurait pas autant de succès. Sincèrement, expliquer la modularité à des gens qui vous parlent de Pascal orienté composant et d'Ada, c'est ne pas comprendre d'où ça vient.
Et j'ai déjà traité l'argument de popularité : si vous avez envie de rouler en Twingo car il y en a beaucoup sur la route, libre à vous. Mais vous n'allez pas avoir beaucoup de place pour vos bagages, ni beaucoup de vitesse, ni beaucoup de freinage, ni beaucoup de sécurité. Moi, je roule en Rolls... avec quelques millions de collègues...
J'ajoute que si j'étais vous, j'utiliserais l'argument de popularité avec beaucoup de prudence : il y a des millions de développeurs C++ en Inde et en Chine, qui programment aussi bien (ou aussi mal) que vous, et qui coûtent beaucoup, beaucoup, moins cher... Le développement C++ en France et en Europe: "no futur". Si j'étais vous, je ferais comme moi, et je trouverai tous les avantages comparatifs que je peux trouver, afin de ne pas avoir à être en concurrence avec eux, mais à vérifier leur travail, à les auditer, à écrire les spécs ou les cahiers de recette, ou à aller bien plus vite... Mais c'est vous qui voyez ...
Bonjour à tous,
Bon moi aussi je dois être un imbécile parce que je ne vois pas de fiche résumé. Dans 1-summary il y a un tableur, mais il n'explique pas l'arborescence du projet.
Par contre moi je perds du temps à le trouver le source... Où est l'algorithme de conversion en lettres ? Quand j'ouvre 4-Sources je tombe sur des répertoires dont je n'ai aucune idée de l'utilité. Quand je regarde les types de fichiers, je trouve des images, du XML, pleins de trucs dont je n'ai aucune idée, mais pas des sources. Je suis censé regarder quoi si je veux voir les algorithmes ?
Donc C++Builder ils roulent en twingo ?
Mais oui. D'ailleurs, Ada, qui est un langage parfait depuis le début, a arrêté d'évoluer depuis les années 80...
Argument de popularité...
Vous n'avez rien traité du tout, vous avez radoté sur l'analogie de la twingo. Et on sait tous ce que valent les analogies : https://byorgey.wordpress.com/2009/0...orial-fallacy/
Dernière modification par Invité ; 23/03/2018 à 23h46.
Ada continue d'évoluer : Ada 2012 est très intéressant, et Jean-Pierre Rosen est, avec le reste du groupe de travail Ada, en train de préparer le prochain Ada. Sera-t-il 2018 ou 2019, je ne saurais le dire. Mais "arrêté d'évoluer" est une erreur factuelle. Du reste, même l'Ada d'origine reste supérieur au C++ d'aujourd'hui. Alors l'Ada d'aujourd'hui...
D'ailleurs, Fortran aussi continue d'évoluer, Fortran95 est très intéressant, implémenté dans de nombreux compilateurs, et Fortran2005 encore plus, mais le nombre de compilateurs qui l'implémente est restreint, c'est dommage.
Vous avez raison. Je reformule: quel que soit le nombre d'utilisateurs de C++Builder, cela reste le meilleur des dialectes du C++.
Je vous conseille le livre "L'analogie, coeur de la pensée", par Douglas Hofstadter et Emmanuel Sander. Voilà un argument d'autorité en faveur de l'analogie.
Du reste, la concurrence effrénée des codeurs (on ne peut pas écrire "développeurs") chinois et indiens est bien présente: Développeur C++ en France et en Europe => no future.
Il faut savoir payer, plus exactement investir. Je paye bien davantage pour Delphi, mais c'est bien plus rentable. Le retour sur investissement est énorme. Nous sommes des développeurs professionnels, nous gagnons notre vie avec ce métier, nous sommes payés pour programmer, il est normal que nous payons pour de bons outils.
A l'inverse, je reconnais que payer de l'argent pour un environnement C++, y compris Qt, ça apparaît comme une décision d’investissement bien discutable...
Bonjour Bérenger,
merci de faire l'effort. Tous les fichiers pascal ont une extension .pas.
La décomposition du répertoire 4-Sources est la suivante:
- Common : sources, à la fois pour le composant non-visuel et les composants visuels.
- Delphi : projets pour compiler les composants,
- Help/Docbook : fichiers XML source
- Help/HtmlHelp : fichier CHM compilé d'aide dans le sous-répertoire HtmlHelp. Ce fichier s'installe dans l'EDI
- Help/XML: XML généré par Delphi listant tous les éléments présents dans les sources. permet de s'assurer qu'on n'a rien oublié d'important
- Help/EDIExtension: sources de l'expert Delphi pour rajouter directement un menu d'aide sur le composant dans l'EDI,
- Includes : comporte un fichier .inc pour <essayer> de rester compatible Delphi/FPC, les deux compilateurs ayant évolué chacun de leur côté.
- Resources : sources pour créer les icônes des composants. Ces icônes vont apparaître dans la palette de l'EDI pour "glisser/déplacer" le composant dans l'application,
- Typhon : projet pour compiler les composants en codeTyphon, un équivalent libre de Delphi basé sur FPC/Lazarus (répertoire pas encore en synchronisation avec la version Delphi).
Les algorithmes de conversion sont dans les fichiers N2L.<Language>NumberConversion.pas. Avec l'héritage, on peut trouver des éléments utiles dans N2L.BaseNumberConversion.pas ou N2L.AbstractBaseConversionTool.pas.
Les interfaces des composants sont décrites dans N2L.Number2LetterIntf.pas. Dans le répertoire 3-Design/Printed UML Diagrams, on trouve les diagrammes UML imprimés qui expliquent l'articulation des composants autour des interfaces de ce fichier.
Le répertoire 5-Tests possède une structure similaire. Tous les sources des tests sont dans le répertoire 5-Tests/Common (peux ceux qui sont compilables dans les 2 environnements) et dans 5-Tests/Delphi pour les tests unitaires Delphi, etc.
Je reconnais que pour des gens qui ne connaissent pas Delphi, il faudrait documenter davantage l'arborescence projet qui est la même pour tous les composants, peu ou prou. Je rajouterai cela dans une version améliorée.
Encore une fois, merci beaucoup pour l'effort.
Bien cordialement,
ThierryC
Quel compilateur as-tu utilisé avec C++ Builder ? BCC32 ? Si oui, il s'agit d'un compilateur qui traîne une montagne de bogues et ne supporte pas entièrement le C++11 (la version 2011 du C++), même sur les versions récentes de C++ Builder.
L'avantage de Qt, c'est que, après la phase du moc, on peut utiliser n'importe quel compilateur qui supporte le C++ standard. Cela évite de dépendre de compilateurs C++ de Embarcadero en retard par rapport à GCC, MSVC et CLang (le vrai Clang, pas le compilateur C++ 64 bits de Embarcadero basé sur une ancienne version de Clang).
Absolument : quand C++ évolue, c'est pour essayer vainement de corriger les "ennuis" du langage alors que quand Ada évolue, c'est "intéressant".
C'est évident.
Mais bien sûr, les "codeurs" chinois et indiens sont objectivement inférieurs aux "développeurs". Mais bon, les "développeurs" européens vont quand même disparaître à cause des "codeurs". De toute façon, tous sont bien inférieurs aux merveilleux "auditeurs", véritable élite de l'informatique, dont vous faites parti et qu'en pure bonté vous quittez parfois pour venir ici nous élever un peu de notre misère intellectuelle.
Bonjour, vous pouvez ironiser tout votre soûl, vous n'avez aucun argument technique. Je ne vous vois pas réaliser de composants équivalents à ceux que j'ai faits. Objectivement, la sécurité des types est inférieure en C++, les génériques aussi, la performance aussi, la sureté de fonctionnement aussi, l'approche composant aussi, la lisibilité enfin. Tout ceci impacte la qualité et les délais d'abord, les coûts ensuite, les livrables enfin, puis le turnover... Et l'auditeur arrive. Il n'est pas missionné par des les développeurs, il est missionné par la direction générale, ou par le client... Et ses conclusions sont sans appel.
Un article est paru en Inde, où il est indiqué que 95% des développeurs indiens ne savent pas "coder". Je vous invite à le retrouver sur la Toile...
Effectivement, il y a une grande différence entre un codeur et un programmeur. Pisser du code est à la portée du premier venu, en C++ tout particulièrement...
Et oui, je confirme que vous vous êtes enfermés dans votre langage C++. Bien que j'utilise de nombreux autres langages, Je connais C++, je le pratique couramment, j'ai fait des grands projets avec, je génère des sources, je suis formateur, et j'en connais fort bien les limites. Je ne suis pas le seul. Par exemple, les inventeurs de Java ont conçu à l'origine leur langage comme étant "le C++ sans les ennuis du C++". Cela a dérivé, hélas. Clairement, vous ne savez pas faire la démarche inverse et tenter de vous ouvrir à d'autres langages plus sûrs comme Pascal, Eiffel ou Ada, et à vérifier par vous-même combien votre pratique de l'informatique en serait transformée.
Le sujet est ici l'avenir du C++, je reste dans le sujet : "no future" pour les développeurs européens, et un travail formidable pour les auditeurs avec tous ces projets qui vont aller dans le mur. C'est excellent! Ceci dit, il eut été préférable pour nos professions que nous passions à autre chose.
Cordialement,
ThierryC
Figurez-vous que je ne suis pas à la retraite et que je n'ai actuellement pas 63 heures à passer sur ce projet.
Merci pour ce procès, malheureusement vous ne connaissez rien de ma vie. J'ai utilisé professionnellement des langages très différents : langages Orientés Objet basé classe, langages OO basé prototype et langages fonctionnels. Java, C++, Pascal, Eiffel et Ada sont des langages OO basé classe, donc en fait relativement proches. Ouvrez-vous à des langages vraiment différents, votre pratique de l'informatique en sera transformée.
Encore un qui laisse le gant à terre. Ces développeurs C++ n'ont que de la tchatche. Le seul argument qui reste est celui de la popularité.
Dès qu'on s'attaque sérieusement à leurs mythes, il n'y a plus rien, et tous les prétextes sont bons pour ne pas concourir, et ne pas démontrer que leur langage est effectivement très inférieur à des langages similaires, mais sûrs.
Cher Simon, Si je compare C++ à Pascal, Ada et Eiffel, c'est effectivement que les paradigmes sont proches, mais que les réalisations sont meilleures. Ce fil de discussion concerne bien l'avenir de C++ que je souhaite le plus bref possible. Faites œuvre citoyenne et aidez-nous à détruire l'utilisation de C++ qui ne répond à plus aucun besoin et qui est nuisible en soi. Ainsi que tous ces autres langages qui ont le même type de syntaxe et la même absence de lisibilité.
Par ailleurs, vous utilisez de nombreux autres langages, comme moi. Et sans doute, vous les mélangez dans le même projet en fonction des besoins, comme moi. Et peut-être même inventez-vous des DSL si nécessaire, comme moi. Je vous en félicite. Vous avez visiblement toutes les alternatives à votre disposition. Laissez tomber le C++, sauf les projets "legacy", le temps de pourvoir à leur remplacement.
En tout cas, je vous souhaite de bons développements et une bonne continuation.
Bien cordialement,
ThierryC
Pour ce que j'ai à faire, l'argument est surtout un problème de performances avec un langage comme Ada.
J'ai déjà fourni plus haut dans la discussion des benchmarks sur des programmes de calcul intensif.
Du coup, je ne vois pas bien l'intérêt de "concourir" pour démontrer l'éventuelle supériorité de Ada sur un problème de peu d'intérêt pour moi, alors que des benchmarks suggèrent une nette infériorité de Ada et son compilateur sur un point qui est fondamental pour mon usage.
Néanmoins, j'ai pris la peine d'installer le compilateur GNAT, de rassembler des cours de Ada, j'irais même jusqu'à programmer une petite application réelle (probablement un moteur de calcul d'images de synthèse simplifié).
J'ai un budget temps limité d'une semaine par an pour évaluer un langage, donc matériellement pas le temps de tester les centaines de langages dont les promoteurs clament la supériorité. Cette année, ce sera donc Ada, et rien d'autre, et au plus une semaine sur le sujet avant de conclure.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager