Pas perdre de vue que c'est un langage non-propriétaire, qui ne dépend de Microsoft, Apple ou autre, et avec un standard ISO.
Version imprimable
Pas perdre de vue que c'est un langage non-propriétaire, qui ne dépend de Microsoft, Apple ou autre, et avec un standard ISO.
Je comprends entièrement qu'on enlève, de temps en temps, quelque chose, même si cela doit malheureusement casser une retro-compatibilité. Le C n'a peut-être pas assez évolué de ce côté là (seule gets est marquée dépréciée si je me souviens bien, mais pas encore enlevée), Java semble plus proactif, mais à un rythme qui semble beaucoup plus lent que sur les langages modernes qui ont tendance à dire "attention, dans 4 mois on casse tout, démerdez-vous pour patchez le code chez tous vos clients".Citation:
Envoyé par el_slapper
Il y a quelques bricoles qui disparaissent dans le C++ moderne, et même un mot clé qui a changé de sens ("auto") mais le comité de normalisation a fait vraiment gaffe, en examinant des millions de lignes de codes, pour évaluer l'impact que ça aurait.
Certains aimeraient bien supprimer les macros, mais il me parait assez invraisemblable que cela se fasse, il y a un risque maximum de rupture qui pourrait semer une grande confusion en produisant deux branches divergentes.
C'est en partie fait avec les constexpr.Citation:
Envoyé par wolinn
Je ne me suis pas mis au C++1y, mais à ce que j'ai compris cela offre plus de flexibilité (avec des fonctions expression par exemple) mais ne remplacent pas totalement les macros.
Les macros peuvent disparaitre lorsque le système de compilation sera refait. Quoique, la compilation dynamique "à la Java" que le comité prévoit, c'est juste normaliser le format des fichiers "precompiled header" :roll: :roll:
On peut quasiment se passer des macros, surtout avec le C++ 11/14, mais le sens de ma remarque était qu'il est invraisemblable qu'elles disparaissent de la spécification C++ à échéance prévisible parce qu'elles ont été largement utilisées depuis les débuts du C++, et des bibliothèques entières en dépendent.Citation:
Envoyé par foetus
Je parle d'utilisations anciennes des macros pour définir des fonctions, par exemple, ou même des classes, et d'autres constructions bizarres, pas simplement du #define en début des fichiers qui empêche les redéfinitions pendant la compilation.
Citation:
Envoyé par wolinn
Qt repose sur des macros notamment en ce qui concerne les slots et les signaux. Supprimer les macros tuerait Qt.
Ils vont durer encore quelques décennies je pense.
Je crois que la vie d'un langage dépend surtout des technologies en place et du modèle économique. Aujourd'hui, le langage le plus demandé en entreprise, c'est le Java/J2EE. Je ne saurais dire pourquoi on utilise encore ce langage. Sûrement qu'il y a aussi un intérêt économique pour les SSII. Je ne sais pas.
Aujourd'hui, je vois surtout une demande en C/C++ par les studios de jeux. Les frameworks et SDK utilisés sont codés en C/C++, donc c'est normal.
Pour ma part, je crois plus à l'avenir des langages web (HTML5 / Javascript) qu'aux langages compilés. Il faudra bien un jour se débarrasser de cette couche "chaine de compilation/MakeFile et build" indigeste.
Mon avis.
pour la sous-traitance en embarqué c'est en chine que ça se passeCitation:
Envoyé par kilroyFR
Pour la simulation et la CAO, on a besoin de toute la puissance de calcul disponible, on en a jamais assez pour faire tourner des modèles météorologique, simuler des galaxies, ou des écoulements de fluides, ou des assemblages mécaniques de plus en plus complexes.Citation:
Envoyé par zecreator
Les IHM peuvent bien être en langages interprétés, mais au final, on appelle toujours du code compilé écrit en C, C++ ou FORTRAN pour inverser une matrice 1000*1000 ou résoudre un système d'équations différentielles, même si c'est enfoui dans des bibliothèques.
Avis qui n'engage que moi : parce-qu'il n'est pas trop difficile de former des gens à Java.Citation:
Envoyé par zecreator
A mon avis, pour les langages populaires, l'avenir existe au moins pour maintenir les logiciels existant et c'est le cas pour C, C++, Java, C#, Python qui grimpe...
A partir du moment où il y a des évolutions sur les sdk, c'est que ça vit.
Pour revenir à C et C++ et des nouveaux développements, ils sont utilisés sur de l'embarqué et dans la plupart des objets connectés qui pourraient constituer un marché important demain.
Avec le développement du cloud, les contraintes d'optimisation des tâches et du code reviennent à l'ordre du jour et si développer en C/C++ peut constituer une économie importante sur de gros batch quotidiens, il peut être tentant pour les entreprises d'y revenir...
Les succès de Python et R dans le calcul scientifique sont souvent dus à l'intégration dans l'écosystème de bibliothèques écrites en C/C++ ou fortran.
Les jeux video utilisent également encore beaucoup C et C++
Les vrais concurrents de ces 2 langages encore très populaires sont Rust, Go (peut-être d'autres), qui peuvent produire du code machine, mais je pense qu'ils ne les égalent pas encore en terme de performance.
https://benchmarksgame.alioth.debian...g=go&lang2=gcc
Donc plutôt d'accord avec Peter Wright
peut etre pour toi mais pour nous depuis 5 ans les softs embarqués en sous traitance c'est juste impossible et ca ne les interesse pas.Citation:
Envoyé par marc.collin
par contre tout ce qui est dev sur PC, la il faut reconnaitre qu'ils sont aussi bons que les devps de chez nous.
Google est en train de créer un nouvel OS pour le tout en un comme Wndows 10 qui s'appelle : fuchsia
Les logiciel et interface vont se eêtre développer avec Flutter, c'est à dire avec Dart. Certain produit android sont déjà développer avec flutter et le grand public ne sait pas.
Mais pour le kernel, ils ont construit un truc appelé Zicron et pourtant c'est fait avec C++ / C.
Lien du dépot miroir
L'âge du projet a environ deux ans (par rapport à dépot). S'il voulait, ils pouvait déjà avec d'autres languages et pourtant ils ont choisi C / C++. Donc je pense que C et C++ ont des beaux jours devant eux.
Oui c'est vrai, le C/C++ est beaucoup utilisé pour le métier. Je trouve ces langages moins utiles coté IHM. Ce serait même plutôt un frein. Quand je vois la bouillie de code qu'il faut pour afficher un fenêtre Windows avec quelques widgets, alors qu'avec Java, une simple instance de JFrame prend une ligne....Citation:
Envoyé par wolinn
Il est vrai que Java est moins compliqué a développer. L'intérêt de Java est aussi de pouvoir comprendre facilement le concept Objet. Les langages C/C++ ont un coté plus technique. Comprendre les liens entre les fichiers, les directives de compilation. Associer les librairies... Cet aspect m'a toujours freiné pour m'investir dans ces langages.Citation:
Envoyé par el_slapper
Il m'arrive de les utiliser pour développer des petits jeux retro pour mes vieilles consoles ou vieux ordis. SDCC par exemple est excellent.
Les pseudos prophètes des languages à haut niveau et GC qui remplaceront tout dans un future proches ( proche depuis 20 ans) m'ont toujours fait doucement rigoler.
Je vais troller un peu car c'est Vendredi.
Si on prends l'état des lieux en 2018 on a :
- Tous les Kernels de 95% des OS faits en C (parfois C++) incluant, Windows, Linux, XNU ( OSX), iOS et Fushia. Car le code kernel est incompatible avec le concepte de GC, ou de runtime.
- Toutes les applications Desktop client lourdes qui sont fait en C++, incluant les Web Browsers, les suites de bureautiques ( Office, Libre Office), les app systemes ( navigateurs de fichiers, exploreurs, système config) car les grosses apps ont besoin d'une gestion fine de la mémoire.
- Toues les jeux vidéos ou applications 3D et CAO sont fait en C++ : Unreal Engine, Unigine, CryEngine et tous les jeux dérivés, Blender, Maya, Cathia & co car 3D = performance et low-latence.
- Tous les softs embarqués sont fait en C pour des raisons de places, incluant votre box Internet, votre voiture et l'avion que vous venez de prendre.
- Tous les drivers sont fait en C car code kernel.
- Toutes les Databases engines majeures ( MariaDB, MySQL, MongoDB, Redis, Oracle, SQLServers) sont fait en C++ ou C pour des questions de latences, performances et de contrôle fin des I/O.
- Tous les Web Servers majeures incluant Apache, Ngnix, IIS, lighthttpd sont fait en C++ ou C. ( à l'exception de Caddy, en Go ).
- Toutes les libs systèmes, framework majeurs systèmes sont fait en C ou C++ car utilisables dans tous les autres languages.
- Toutes les applications scientifiques ont généralement un coeur en C/C++ ( ou Fortran ) avec une interface dans un scripting language ( python ou autre ) pour des raisons de performances.
Donc si on prend la question autrement: Qu'est-ce qui reste en autre chose que C et C++ ?
- Le Web (in browser ou meme serveur ) car c'est le domaine exclusive de Javascript.
- Les Web services, ou application serveurs en Go, .NET, Java ( ou PHP pour les adeptes du sado-masochisme ).
F
C'était pas la peine, justement parce que c'est vendredi.Citation:
Envoyé par Firwen
Tu ferais pas un p'tite prière tous les soirs au Dieu du C/C++ toi ?Citation:
Envoyé par Firwen
Après, tu as raison de minimiser la portée du domaine web. C'est sûr que c'est pas comme-ci c'était un domaine majeur de l'informatique aujourd'hui lol
Tu ferais pas un p'tite prière tous les soirs au Dieu du JS toi ?Citation:
Envoyé par zecreator
Après, tu as raison de maximiser la portée du domaine web. C'est pas comme si tout ce que tu fais en web repose sur une base C/C++ et sera obsolète dans 2 ans.
Obsolète dans 2 ans, je ne sais pas. J'ai des app web qui tournent depuis 5 ans, sans avoir eu (trop) à les retoucher.Citation:
Envoyé par AoCannaille
je pense qu'il faut encourager l'utilisation de langages de développement plus simples (C#, Java) et utiliser des langages "puissants" comme le C/C++ pour des calculs complexes ou pour interpréter des choses rapidement. Mon avis : utiliser directement du C/C++ pour développer un éditeur de texte, ce n'est pas ainsi que ces langages prouverons leur supériorité. Aujourd'hui, une IHM développée en Java est toute aussi performante qu'une IHM développée en C/C++.
On voit arriver une certaine maturité du Web, au point où les outils de bureautique Desktop peuvent être facilement remplacés par des outils on-line. La démocratisation des Web OS va également apporter, dans quelques années, un vrai changement des utilisateurs. Tout sera dématérialisé, en ligne. Et les technologies de développement seront orientés webdev.
C'est vrai que j'exagère avec 2 ans. C'est surtout le front qui se met vite à la poubelle si on suit la mode fluctuante des conceptions d'IHM, et pas les techno en elles-même.Citation:
Envoyé par zecreator
Oui enfin, quand on compare les bench de visual studio code (exploitant du JS donc) et de notepad++, ça tient la route pour de l'occasionnel, mais ya pas photo sur la montée en charge...Citation:
je pense qu'il faut encourager l'utilisation de langages de développement plus simples (C#, Java) et utiliser des langages "puissants" comme le C/C++ pour des calculs complexes ou pour interpréter des choses rapidement. Mon avis : utiliser directement du C/C++ pour développer un éditeur de texte, ce n'est pas ainsi que ces langages prouverons leur supériorité.
Comme il y a 15 ans MySQL challengait Oracle sur les petits volumes mais se faisait exploser sur des volumes industriels.
Aujourd'hui une IHM en Java développée proprement sera aussi performante qu'une IHM développée sans trop d'effort en C++ (les IHM en C, je n'y crois plus vraiment ^^)Citation:
Aujourd'hui, une IHM développée en Java est toute aussi performante qu'une IHM développée en C/C++.
D'ailleurs, si on exclue le temps de lancement de la JVM et les interruptions du GC, java n'a jamais été très lent par rapport au C++. Il se traine une réputation de merde à cause des freeze d'IHM quand le GC se lançait, mais sinon c'est le même ordre de grandeur sur les tâches classiques.
Par contre, en ram, ce n'est clairement pas comparable, une IHM en JAVA aura toujours besoin d'énormément de ram, ram qu'on préfère garder pour ce à quoi sert l'IHM, et pas instancier un JButton qui pèse 10 fois plus qu'un QButton...
J'ai testé de faire des albums photo dans le navigateur... Une plaie! je suis retourné rapidement à une appli desktop (malgré le fait que le fournisseur de cette application ne permette pas les albums A5 portraits alors que celui sur le web oui :( ). Et encore, j'ai pas le PC du quidam moyen, j'imagine pas sur des config plus light...Citation:
On voit arriver une certaine maturité du Web, au point où les outils de bureautique Desktop peuvent être facilement remplacés par des outils on-line. La démocratisation des Web OS va également apporter, dans quelques années, un vrai changement des utilisateurs. Tout sera dématérialisé, en ligne. Et les technologies de développement seront orientés webdev.
Au même titre que Word/Excel online dépannent, mais impossible d'en devenir un power-user...
Certaines applications sont juste incompatible avec le web, ou alors c'est juste du gachis de ressources informatiques.
Au final, ce ne sont pas les langages qui doivent prouver leur supériorité, mais les paradigmes sous-jacents. Un smart-pointeur sera toujours plus efficace qu'un GC, alors qu'au final ça remplit le même rôle...
En l’occurrence, c'est plutôt le fonctionnel qui fait une entrée en force dans les langages type Java/C++ et pour autant ce ne sont pas les langages fonctionnels qui leur passent devant.
Au même titre que Windows a atteind une telle masse critique qu'il peut sans soucis absorber les innovations d'un challenger avant de voir un impact sur sa part de marché, C++ ou Java vont continuer à se mettre à jour avec des nouveautés des langages concurrent mais ne vont probablement pas être devancés avant le passage aux langages quantiques.
J'avoue que j'utilise toujours C++ même pour les IHM, mais c'est surtout par habitude, c'est le langage que j'utilise depuis 25 ans, sur lequel je suis efficace, et puis je n'ai pas envie de passer mon temps à basculer d'un environnement à l'autre.
Je ne cherche pas à justifier que c'est un choix optimal, et si je débutais maintenant, peut-être que je ferais un autre choix pour les IHM.
J'avais évalué Java dès sa première version, dans les années 90, et ça ne m'avait pas bien convaincu à l'époque, mais je m'en suis quand même servi pour faire quelques applets dans un site web. Je n'y suis pas revenu depuis, alors que ça s'est certainement enrichi et ce serait peut-être viable maintenant pour mes applications.
Je me suis un peu intéressé à Python l'année dernière, et puis quand j'ai vu qu'il y avait des soucis de compatibilité d'une version à l'autre, j'ai laissé tombé et remis ça à plus tard, en attendant que ce langage soit un peu plus mature et stable. Je n'ai pas envie de me lancer avec dans des développements lourds si ça doit encore changer dans 2 ans sans crier gare.
Maintenant, je reste toujours ouvert à l'évaluation d'autres langages.