Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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
Discussion :
c'est marrant, moi j'ai pas entendu la même chose quand j'étais petitEnvoyé par jlliagre
l'accumulation des déchets et la raréfaction des ressources en 2000 allait pousser les digients a en finir avec l'arme atomique
et en 2150 : le peu d’humain survivant (au moins y'a des survivant) vive en orbite autour de la terre en attendant que les radiations baissent.
par contre j'ai pas vu d'ordinateur quantique.
En effet. Pour être précis, refonte en 2008 en cobol-85 d'un code écrit en 1972 en cobol-1(mais qui était passé en COBOL-85 avec le temps). En 2013, j'ai eu des nouvelles, ça tournait du feu de Dieu(pas que grâce à moi, hein, d'autres sont passés dessus depuis). Évidemment, ce n'est pas pour de l'interface. Tous ces vieux langages sont condamnés à ne faire que du serveur central, pendant que les jolis trucs pour les utilisateurs seront faits avec des frameworks javascript ou autre remplacés tous les deux ans.
Mais pour du serveur central(ou de l'embarqué, ou tout ce qui n'est pas directement au contact de l'utilisateur final), c'est hautement débuggué, c'est performant, les gens savent faire, l'existant est énorme et fonctionne nickel, pourquoi changer?
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Exactement, on ne change pas quelque chose qui tourne, on le maintient.
Mais si on te demande de faire un nouveau projet, le fera tu en cobol ? je pense que non.
Les nouveaux projets se font sur des technos "moderne" (pas la dernière techno du moment sur la dernière version fraîchement sortie hier, mais pas trop vielle non plus). Les nouveau projet se font en Java8/9, python 3.4/3.5/3.6, C++ > 11...etc des trucs sortie après 2010 au moins.
en 2018 plus personne ne fait un nouveau projet en python2.7 par exemple, mais il arrive de devoir maintenir du vieux code python2.7 parce que la migration est trop coûteuse.
ça a changé par rapport à l'année dernière alors...
https://www.developpez.com/actu/1671...-Semaphore-CI/
Le seul point noir dans tout ça est que les anciennes technos réclament des compétences qui ne se renouvelles pas (ou pas suffisamment), ce qui entraîne dans le meilleur des cas à un surcoût en cas de maintenance.
En quoi?À la fois C et C ++ vous permettent d'avoir (plus ou moins) le contrôle total du matériel
ça dépend. Évidemment, si c'est une page blanche, la probabilité de partir sur autre chose est très forte. Mais si c'est un projet pour se brancher sur un existant en COBOL..... J'ai vu beaucoup plus de conversions JAVA ratées que réussies. Et pas mal de nouveaux projets en COBOL pour rajouter au COBOL existant, tous réussis. Le dernier en 2012, avant de changer de métier(et de partir au soleil).
Et pour l'avant dernier, en 2011, il s'agissait de données qui venaient du serveur JAVA, que je toutouillais, et que je renvoyais. en fion de projet, j'ai naïvement demandé si ça n'aurait pas été plus simple pour la maintenance de faire ça en JAVA , au lieu de se taper les transferts LINUX==>MVS==>LINUX. Réponse de la MOA : "vous étiez deux fois moins chers à l'estimation! et en plus, sur votre partie, vous n'avez dépassé que de 5%, les gens du JAVA ont tendance à dépasser de 30%". J'ai vérifié ses chiffres, ils étaient presque exacts. Sur un autre projet, plus petit, j'avais chiffré 15 jours, les Javaistes 25.
Je suis sur que des gens faisant du C ou du C++ auraient été très performants aussi. Mais, comme dit par ZenZiTone, ça ne se trouve pas facilement.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
L'information est incrémentale : les inepties récentes du C++ s'ajoutent à celles plus anciennes et à celles du C.
Le type "en trois semaines" connait tous ces erreurs et s'il n'est pas totalement con ne va pas les refaire (mais certains concepteurs de langages semblent totalement cons).
C/C++ n'existe même pas, le sous ensemble commun des programmes valides dans les deux langages n'est pas intéressant. Déjà C n'existe pas, personne n'étant capable de dire quels usages d'une union sont valides. C++ encore moins.
You made my day.
Les OS qu'utilisent nos clients ne gèrent pas le C99, donc nous sommes obligés de compiler explicitement en C89.
Tu crois franchement que si on a un nouveau développement on va se demander s'il y a moyen d'utiliser les super-nouveaux langages à la mode qui changent de version tous les 3 mois ? Ou bien on reprend ce qui fonctionne et qui ne contient que les bugs que l'on fait (et donc pas ceux du compilateur/de la machine virtuelle/autre) ?
relis mon message :
Utiliser une techno un peu près à jour c'est des failles de sécurité corrigé et un support toujours valide.Les nouveaux projets se font sur des technos "moderne" (pas la dernière techno du moment sur la dernière version fraîchement sortie hier, mais pas trop vielle non plus).
le problème est peut être la.Les OS qu'utilisent nos clients ne gèrent pas le C99
Comme tous dans la vie faut évoluer à un moment donné.
Je ne suis pas partisan des framework web js qui change tous les mois. Mais je ne suis pas partisans non plus à rester dans du C89, il vaut mieu se diriger sur du C11
Honnêtement sa t'apporte quoi de coder en C89 ? tu sait que tes clients devrons (assez vite) changer d'os, car un truc qui a plus de 20ans a un moment il sera remplacé. Et quand ce jour arrivera ton client devra repasser à la caisse parceque le code en C89 de gangsoleil ne sera pas fonctionnel sur des systèmes récents.
Il faut faire le calcule entre maintenir un vieux truc ou le remplacer, a un moment donné il faut remplacer c'est moins cher.
J'ai eu un problème similaire récemment, une machine Linux avec que python2.7 d'installé. Je l'ai forcé à rajouté python 3.5 et j'ai codé le programme en python3.
Il a compris que le support python2.7 se termine en 2020 et que si il ne voulait pas devoir refaire mon code dans 3-4ans il avait intérêt à installer python3 (qui fonctionne en parallèle de 2.7)
Il est important de faire comprendre au client l'importance d'utiliser les dernières/avant dernière versions quand on développe un nouveau projet.
Justement, C/ C++ produit du binaire et n'a rien à faire du système d'exploitation/ de l'environnement dans lequel l'exécutable travaille.
Donc le méga pire scénario, tu auras toujours un exécutable qui fonctionnera quelque part
Et ensuite, coder "aussi vieux" permet d'être compatible avec la majorité des compilateurs qui existent.
Python 2.7 sera mort lorsque la V.M. 2.7 sera retirée des dépôts
Même pas car on pourra toujours le télécharger et l'installer à la main.Python 2.7 sera mort lorsque la V.M. 2.7 sera retirée des dépôts
D'ailleurs, c'est encore le cas pour Python 1.6 : https://www.python.org/download/releases/1.6.1/
Ce que ça m'apporte ? Le fait que les clients puissent l'installer... Donc en gros, ça nous apporte des clients (et pas des petits pour info).
OS mis à jour régulièrement, pas de soucis. Supporté par IBM, avec des évolutions régulières.
Tu prends le truc à l'envers : le code C89 fonctionne sur les anciens systèmes comme sur les plus récents, contrairement au C11 qui n'est pas compatible avec certains OS.
C'est bien là mon soucis : entre python 2.7 et 3.2, il y a eu une rupture d'interface qui fait que les programmes utilisant certaines fonctionnalités de la 2.7 doivent être ré-écrits en 3.2 (ou supérieure). Mais pourquoi faire, volontairement, une telle rupture ? Apporter de nouvelles choses à un langage, c'est bien, mais supprimer les "anciennes" fonctionnalités utilisées dans beaucoup de programmes, vraiment, je ne vois pas de raison.
Parce que l'Histoire nous a appris qu'essayer de conserver la rétrocompatibilité sur 30 ans donne des software / langages inutilement lourds et complexes? c.f Windows ou C++.Mais pourquoi faire, volontairement, une telle rupture ? Apporter de nouvelles choses à un langage, c'est bien, mais supprimer les "anciennes" fonctionnalités utilisées dans beaucoup de programmes, vraiment, je ne vois pas de raison.
Dommage que ça ne s'applique pas au hardware (amd64 est compatible avec x86, qui date de 1978), ça nous aurait peut-être évité spectre et meltdown...
C'est bien ce que je dis.
On fait un concours. Tu prend ton C++ et tu me fait une appli de gestion avec une base de données de ton choix, avec une IHM web ou Windows/Linux. Prêt. Partez!
... Fini
Il ne faut pas confondre portabilité et cross-compilation : essaye de compiler netBSD avec le compilateur C d'HP-UX et on en reparle.
La portabilité d'un code ne se définit pas par l'utilisation de GCC.
Les applis embarqués sont effectivement un des domaines de prédilection du C/C++.
Non, Développer des applications de gestions n'est pas à la portée de n'importe qui ! Il faut concevoir la base de données, étudier la volumétrie et son évolution dans le temps, optimiser les requêtes, définir les couches logiciels, les développer, ...
Certes, il y a des outils pour automatiser et simplifier tout ça. Mais quand tu te retrouve avec une base de plusieurs gigas en production avec des utilisateurs qui t'incendient en permanence parce que ton appli est trop lente, et bien tu jette ces outils merveilleux et tu reprend à la base.
C'est simplement que le niveau de tes sous-traitants est mauvais. La maintenance des applications va en prendre un coup
Je ne crois pas qu'ils soient plus mauvais que la moyenne. D'ailleurs ils reprennent leur soft quand ca chie; dans tous les cas ils coutent toujours moins cher qu'un dev en metropole (salire /4 au minimum pour nos sous traitants a l'ile maurice, beaucoup plus pour les indiens qui ne sont pas reputés pour etre les plus mauvais en dev sur PC).C'est simplement que le niveau de tes sous-traitants est mauvais. La maintenance des applications va en prendre un coup
Et des devs avec un ego surdimensionné qui se croient des super developpeurs on en a vu passer des tonnes (WPF, SL etc) et la maintenance logiciel derriere les usines a gaz fabriquées ne valent pas mieux.
Ben, en COBOL, dans les temps anciens, il y avait une syntaxe qui s'appellait ALTER PROCEED, et dont la fonction était de modifier la cible d'un GO TO. Est-ce que tu comprends pourquoi ça a été banni, malgré les problèmes de rétro-compatibilité que cela a entrainé?
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Liberal1, tu sembles oublier que beaucoup de ces langages modernes héritent du C. PHP, C++ etc ont été développé en C puis lorsque des technos plus intéressantes sont apparus ils ont été migré dessus.
Dire que C/C++ n'a pas de sous-ensemble commun me fait dire que tu n'as pas beaucoup développer avec. La syntaxe est très proche, le typage de base aussi etc.
Le C et le C++ ne sont pas parfaits mais les autres langages aussi. Encore une fois tout dépend de ton cas d'utilisation.
De quelles inepties parles-tu ? Dans quel contexte ?
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.
Répondre avec citation
Partager