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
Discussion :
Et bien...
Bonjour,
Si vous supprimez le mot "trop" du titre, la réponse est alors évidente pour qui à déjà mis un tout petit peu son nez dans un OS (ou un compilateur), surtout s'il veut qu'il soit "portable".Envoyé par Hinault Romaric
Surtout RIEN !
Et si les concepts d'abstraction des langages modernes étaient carrément contre-productifs ?
J'adore l'objet pour un tas de raisons simples comme la prise en charge de l'allocation et la libération de mémoire. J'adore que le type string me permette les concaténations, les insertions, les tableaux dynamiques de strings dynamiques. Tout ça est génial mais c'est lent et impossible à optimiser
Pensez donc , en C je sauve l'image de toutes mes variables globales avec un memcpy() ; Comment faire en C++ ? En C#, il faut parcourir chaque élément du segment data dans une boucle pour aller chercher les variables une par une (Marshal).
En C pas de boucle, pas de piège , juste un pointeur et une longueur ..
Vous pensez vraiment que ça va changer ? Moi je doute .. La modernité , c'est justement ce que je veux éviter quand je compile de l'ARM 7 !
Un autre argument de l'objet selon moi est le partage du travail en équipe , le C n'aide pas dans ce cas mais on finit par se partager les tâches de façon informelle alors qu'en objet il y a moins de chances que les devs se marchent dessus si vous voyez ce que je veux dire...
A mon avis un langage qui pourrait se positionner comme une vraie alternative à C est un langage qui étend le C et non un langage nouveau avec une syntaxe totalement différente du C. En d'autres termes, si BitC ajoute la programamtion fonctionnelle avec une syntaxe très différente (IA) du C pourquoi ne pas ajouter ce paradigme sans changer(de façon significative) la syntaxe!
C'est mon avis,
Programmer c'est comme dessiner.
Je vais répondre par une autre question : pourquoi remplacer la langue française par une autre langue ?
euh... Tu n'as pas souvent dû analyser les perfs d'un programme, alors, ou vouloir l'optimiser... *
De plus, suivant le domaine, une modélisation du flux un découpage du soft, une maintenance, est souvent beaucoup plus simple....
*: par exemple les "new" font des allocs et des initialisations sytématiques. Quelqu'un qui sait ce qu'il fait d'une part pourrait créer un tableau, entièrement ou partiellement dynamique, d'autre part pourrait "économier" out un tas d'initialisations si les valeurs sont en fait utilisées seulement après avoir été crites une fois : on peut donc économier N fois les intilialisations sytématique des new.. Et ce n'est qu'un exemple parmi d'autre...
Absolument..
Cette(ces) mode(s) revien(nen)t à chaque fois à vouloir refaire un Espéranto, dont on a vu ce que ça donnait.
Entre la flemme, l'existant, et l'effort pour apprendre, pourquoi diable quelqu'un voudrait-il apprendre un nouveau langage si un déjà pratiqué non seulement permet de faire de faire le job mais aussi de commnuiquer avec d'autres ??
A part quelques formations universitaires et quelques domaines très pointus de recherche, l'écrasante partie de notre boulot ne demande qu'une application fine et réfléchie de quelques "procédures" ...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
et qu'est ce qui t'empêche de faire la même chose en c++, avec en bonus le typage, les templates et tout le reste.
utiliser le c++ n'implique pas d'utiliser des hiérarchies d'objets polymorphiques de fous, ou des designs patterns qui font le café.
c'est typiquement le genre de commentaire que j'ai décrit, tu crois que ça va tout foutre en l'air alors que c'est juste du c++, tu as les avantages et tu n'es pas obligé d'utiliser les concepts de hauts niveaux.
L'idée de base n'est pas idiote : chercher à faire "mieux", sans autre information, ça n'est jamais inutile.
Maintenant, chercher à faire "mieux" en remplaçant tout ce qui est vieux, juste parceque c'est vieux, me parait être quelque peux présomptueux(et jeuniste). Je ne connais rien en programmation système, mais je m'y connais en COBOL, et il ne survit pas uniquement par sa présence. Dans sa niche, on a pas fait mieux(dès qu'on en sort, évidemment, on souffre...). J'imagine que le C pour le système, c'est pareil : Il offre une palette d'outils limitée à ce qui est utile, sans superflu, mais avec tout ce qui est indispensable présent en natif.
J'insiste sur cette notion de natif. En java, on peut faire tout ce que je fais en cobol(ou que d'autres font en C). Mais ça nécéssitera de passer par des outillages plus ou moins maison, par des contorsions diverses, et au final couteuses, tant en termes de performances que de lisibilité. Je ne connais rien en programmation système, mais je ne parviens pas quand même à l'imaginer sans pointeurs : avec un pointeur, on s'adresse à Dieu(la mémoire) plutôt qu'à ses saints(le nom de variable qui va nous diriger vers le pointeur qui nous amène à la mémoire). Les abstractions ne permettent pas d'être aussi près du composant.
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.
Bon... Déjà, en C, le travail en équipe est autant possible qu'en C++.
Après tout, le C est un langage modulaire, non?
Quand on me parle de l'objet pour travailler en équipe, ça me fait doucement sourire.
Découper une tâche implique de l'avoir au préalable bien définie.
L'orienté objet est une façon de découper comme les autres, que je qualifierais simplement de "descendant de la programmation modulaire". Le truc, c'est qu'en POO, chaque classe est un module. Ou du moins devrais parce que j'ai pu voir un ou deux codes sources qui ne respectaient pas ça. Résultat, dur à maintenir. Mais ça ne viens pas du paradigme, en C ça aurait été le même bordel. Et en brainfuck aussi
Ensuite, il est, comme il a déjà été dit, possible de faire de la programmation orientée objet en C, c'est juste que l'on a pas un compilateur aussi casse-pied sur les cast et que les accès aux données/fonctions ne peuvent être régulés. Et, naturellement, la syntaxe n'est pas vraiment adaptée.
Quant à ton histoire d'initialiser séparément de l'allocation, j'ai plusieurs solutions pour toi, et tu peux déjà en appliquer une (la première):
_ garder la même procédure qu'en C. Malloc & co marchent très bien en C++ malgré qu'il existe des alternatives tout aussi souples. Oui, marchent très bien, y compris avec des classes, c'est juste qu'après il faut appeler le constructeur à la main.
_ surcharger LES opérateurS new et new[]. Evite d'avoir une séquence un peu bizarroïde d'appels à malloc puis au constructeur. C'est à dire, lui dire de ne pas appeler le constructeur, je pense. Suis pas tout à fait sûr de comment on fait ni de ses effets... Je sais qu'on peut le faire car je connaît les capacités de C++, mais je n'ai pas encore eu d'intérêt à utiliser ce type de techniques.
_ utiliser les vector pour remplacer les tableaux. Enfin, si on a un truc dont la taille varie au cours du temps, ou n'est pas connue à la compilation naturellement (sinon, on peut simplement utiliser des tableaux. Ou des tableaux de pointeurs. Et il me semble même qu'il soit possible de faire des tableaux de références bien que je n'en sois pas sûr... J'ai encore de vieux réflexes pointeurs). Le memcpy reste utilisable sur un vector d'ailleurs, mais je te l'accorde, il doit y avoir une petite quinzaine d'octets supplémentaires. Mieux vaut utiliser l'opérateur d'affectation ou le constructeur par copie. Voir mieux, en terme de perfs si on veut juste bouger la bête, la fonction std::move.
Honnêtement, je suis plutôt d'accord avec stardeath par rapport aux arguments que l'on entend en défaveur du C++.
Au fait, vous connaissez tous, j'imagine, la philosophie gardée à l'esprit lors de l'ajout de choses au langage C++ : "you don't pay for what you don't need.
Ca veut simplement dire que si on utilise pas une fonctionnalité du langage, on ne paye pas les conséquences. C'est justement fait pour garder la vitesse du C. Le C++ utilisé en "mode C" devrait donc théoriquement avoir les mêmes performances. (J'ai précisé théoriquement uniquement parce que je n'ai pas vérifié par moi-même)
C'est pour ça que, contrairement à d'autres langages, il faut déclarer une fonction virtuelle pour qu'elle le soit, pour éviter de coller des vtable où il n'y en a pas besoin. Idem pour la RTTI, qui existe bel et bien, mais qui nécessite des utilisations explicite.
Le seul point, pour le moment, que j'aie vu et que je trouve assez vrai, c'est le fait qu'il existe du "code caché" ou plutôt mal contrôlable (du moins, c'est faisable, juste pas évident d'y penser toujours) a cause des héritages. Du coup il faut savoir si une fonction est virtuelle ou pas, surchargée ou pas... Si on a pas la documentation de ce que l'on utilise (ou qu'elle n'est pas exhaustive), ça peut devenir pénible (j'en ai un souvenir assez récent).
C++ est multi paradigme, il n'est pas limité à l'impératif classique comme le C, ni à la POO comme JAVA. Il peut faire soit l'un, soit l'autre, soit les deux à la fois. (sans parler de la programmation générique)
Pour en revenir au langage Ctruc, une chose parmi les avantages du C (à mon humble avis) n'a pas été dite:
_ que le langage soit compilé
_ pas de garbage collector, le dev est quand même censé savoir ce qu'il fait mieux que la machine (comment ça, j'aime pas les GC?)
Parce que bon... la mode actuelle, c'est quand même ces satanées VM, systématiquement dotées de GC. Quel langage récent n'en a pas d'ailleurs?
Tout est dit
C'est pas faux.
J'ai du mal à comprendre le fondement du débat : "Comment attirer les programmeurs systèmes vers un langage moderne ?". Mais.... ont-ils besoin d'un langage moderne ? Le débat est parti du principe que "oui, le C has been" et qu'il lui faut le remplacer. Le passif en C de toute l'informatique actuelle est énorme et, comme dit ci-avant, le C s'impose comme le langage naturel pour communiquer avec tout cela (l'exemple des API des systèmes était bon).
Mon avis est que le C répond parfaitement aux besoins des gens qui l'utilisent. Il est fiable et stable. Si ces gens en avaient marre du C, il y aurait déjà eu tout plein de propositions pour remplacer ce langage et probablement qu'une de ces solutions aurait déjà réussi à s'imposer.
Quand à savoir si on peut l'améliorer et ajouter des nouvelles fonctionnalités, c'est possible en les ajoutant à la prochaine norme, non ?
Le bitC ? Non clairement non, s'il n'est pas déjà mort il ne décollera jamais.
En revanche, j'utilise beaucoup l'Ocaml. Ce langage réunit à la fois les paradigmes de programmation fonctionnelle, objet et générique. Il bénéficie d'un excellent support puisque inventé à l'INRIA (Institut National de Recherche en Informatique et Automatique) et son succès, bien que lent, est croissant. Je pense notamment à la preuve de la démonstration sur l'empilement optimum des sphères dans un espace réduit qui est calculée depuis plus d'une dizaine d'années et qui est programmée en Ocaml, preuve d'un langage sur.
Et la cerise sur le gateau : ce langage s'interface très aisément avec du C.
Je ne vais pas vous faire une apologie de l'Ocaml ici mais à toute les personnes qui me diront que passer du C à l'Ocaml est trop difficile parce-que différent, ce langage est enseigné aux étudiants de Licence 3 Informatique au sein de l'ISTIC à l'Université de Rennes I et les étudiants font très bien le passage de l'un à l'autre.
ça avait été un des premiers langage que j'ai appris pendant mes études, et cela m'a notamment apporté la compréhension de la récursivité.
t'appelle ça un "bonus" ???
Franchement, vos idées du C et du procédural sont tellement loin de la réalité que vos arguments sonnent tout aussi stupides que ce que vous reprochez aux autres...
Ce sont 2 paradigmes différents, avec lesquels on peut faire la même chose. L'un ne nécesite pas d'apprentissage de concepts particuliers, à part comment marche une machine. L'autre nécessite un apprentissage et une programmation avec des concepts différents.
L'un est considéré par les universitaires comme "has been", l'autre est considéré "à la mode".
Il se trouve que, outre la formidable différence dans les existants, que ce soit un physicien ou un électronicien a plus de "rapports" avec la manière dont marche une machine, et dans l'analyse de ce qu'il doit faire pour lui faire faire ce qu'il veut. Un langage procédural sera donc plus adapté à sa manière de penser, simultanément au fait qu'il sea plus adapté aux architectures des machines..
Pourquoi est-ce que les langages de scripts sont procéduraux ????
Bref, de même que le Fortran est ce qu'il y a de mieux pour les calculs scientifiques majeurs (R restera une "niche"), le C est le plus adapté aux processus systèmes, ou aux descriptions d'arbres. Les scripts seront plus adaptés aux appels de programmes tout faits, de même que Java est plus adapté aux affichages multi-plateformes "à la volée", et C++ est un langage plus adapté aux gens qui l'ont appris..
Il n'y a pas de Vérité Absolue...
S'étonner de la position du C revient à s'étonner que 75% des humains utilisent un couteau et une foruchette pour manger.. 25% utilisent des baguettes, st-ce que pour autant cela fait des 75% d'autres des stupides ou hasbeen ??
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
et qu'est ce que tu reproches au c++, qui est au passage du c, qui ferait que ça serait une ignominie de faire de la prog système avec?
parce que bon, les arguments en faveur du c sont utilisables pour le c++, et le c++ a des trucs en plus par rapport au c (bon ou mauvais, mais en aucun cas obligatoire).
Personnellement, je suis un fanatique de la programmation fonctionnelle (quasi exclusivement Haskell) et j'ai du mal à voir l’intérêt de l'utiliser au niveau système (notamment dans les parties critiques). La très grande sécurité qu'apporte Haskell à tout même un impact sur les performances (malgré les optimisations impressionnantes faite par GHC, le compilateur principal, qui doit être certainement le compilateur le plus avancé du monde)
Haskell vient avec un lot de nouveaux concepts (dont son système de typage) qui peut être déroutant (surtout pour des personnes qui ont de la bouteille dans la programmation impérative). Et pour preuve, il y a pas mal de malentendu:
- En programmation fonctionnelle, on évite pas les effets bord, on cherche à les rendre visibles explicitement (via la monade I0 en Haskell, via l'unicité en Clean)
- La programmation fonctionnelle ne se résume pas qu'aux fonctions anonymes
Le typage du C++ est horrible et mal fichu (la généricité est limitée, une utilisation abusives de l'héritage).
Un autre point que beaucoup de personnes oublient également c'est que ce n'est pas le niveau d'abstraction du langage qui fait les performances mais le compilateur. Il a de très grande chance qu'un code écrit en assembleur par un humain soit plus lent que celui écrit par un compilateur C moderne. Il y a bien entendu des cas particuliers.
On se pose la question d'utiliser un nouveau langage seulement quand celui-ci pose trop de soucis. S'il y a bien un langage dont les programmeurs se plaignent peu, c'est bien le C.
Avec toute les connaissances, l'expérience, les libs, bonnes pratiques et autres codes déjà existant accumulés en C depuis le temps, il est pas né le langage, ni le moment où l'on s'en passera pour utiliser autre chose.
Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
Un peu de programmation réseau ?
Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.
En gros, la question posee est "Pourquoi ne pas remplacer un langage imperatif par un langage fonctionnel" ???
Peut-etre simplement parce que ce sont deux manieres de penser qui sont assez eloignees l'une de l'autre, et que donc les gens qui sont aujourd'hui des developpeurs systemes n'ont pas envie d'etre debutant dans un nouveau langage !
Combien de lib systemes C existent ? Combien sont compatibles ML ou Haskell ?
Je reconnais de tres grandes forces a ces langages, mais je ne vois vraiment pas leur interet en systeme : ils sont beaucoup trop haut niveau pour permettre de faire exactement ce que l'on veut : une trop grande partie est laissee au compilateur.
Recommencer alors que le bon vieux C satisfait encore la cour des programmeurs systemes c'est un enorme perd temps. Peut etre l'ameliorer un peu.:chin
Généralement un nouveau langage est née lorsqu'il y a eu des nouveaux concepts.Avec toute les connaissances, l'expérience, les libs, bonnes pratiques et autres codes déjà existant accumulés en C depuis le temps, il est pas né le langage, ni le moment où l'on s'en passera pour utiliser autre chose.
Typiquement le concept de prog objet a fait naitre le C++ et le Java entre autre.
Il est évident qu'un nouveau langage ne reprenant que le concept procédural ou objet ferait un bide au vue de l'existant...
A l'avenir je ne doute pas que de nouveaux langages permettant de modéliser des concepts inédits voient le jour!
Salut,
En quoi cet exemple illustre-t-il une meilleure sécurité de typage du C++ ? À mes yeux, cela démontre seulement un mauvais choix de type et une mauvaise gestion de la part du programmeur. En effet, d'une part, si l'on s'en tient au C89, il me semble déjà que le choix d'un long serait nettement plus pertinent (étant donné qu'il est garantit d'être composé d'au moins 32 bits de valeurs), d'autre part étant donné qu'il n'existe pas de type entier prédéfinit pour contenir un pointeur, il me paraît judicieux de recourir à un typedef afin d'adapter facilement le code.
Enfin, depuis le C99, les types intptr_t et uintptr_t ont été introduit et évitent ce genre de problème.
le code de base a peut être été mal fait, ce n'est pas le propos, le compilateur fait silence radio quand je lui dit que compiler en 64 bits, par contre si je compile en c++, je me fais insulter dans tous les sens, donc je ne plantais plus lamentablement en exécution, mais je ne pouvais plus compiler, je trouve ça quand même plus secure.
ensuite le c++ a introduit les x_cast, qui sont quand même beaucoup plus expressif qu'un cast c, qui oblige à choisir le bon cast et ainsi rendre le code moins abscons (et en plus ce n'est pas obligatoire, le cast c existe encore)
quant au c99, et là c'est un avis perso, si c'est pour avoir du c qui ressemble à du c++, autant faire du c++. mais ces types sont quand même bienvenue.
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