<mode="ironique">
mais bien sûr, invoquons une jvm pour afficher des PNG....
Les langages compilés (C/C++/fortran/...) reste incontournables et ce n'est pas prés de changer (ne serait-ce que pour coder les interpreteurs). Or, avec ces langages, il n'y a pas de garde barrière. C'est bien au programmeur de réfléchir (une vertue de plus en plus rare on dirait). Cependant, l'avantage c'est la performance. Je sais, beaucoup vont me dire qu'aujourd'hui ce n'est plus un problème, que les machines sont puissantes, que les ressources (mémoire, CPU, disque, ..) sont peu onéreurses.... Mais, personnellement, je trouve ce genre de raisonnement absurde. Evidement, je ne dis pas qu'il faut tout coder en C sous pretexte de performance. Cependant, je n'imagine pas utiliser un langage de très haut niveau et/ou interprété pour implémenter des "briques de base" comme un toolkit graphique.
Dis-moi, tu blagues ou tu penses vraiment qu'il y a une antinomie entre "langage compilé" et "gestion automatique de la mémoire" ?
Dis-moi, où est-ce que j'ai parlé de JVM, de très haut niveau, d'interprété ?
Et, dis-moi, est-ce que tu es au courant qu'il existe au moins un langage compilé avec gestion automatique de la mémoire qui a exactement les même performances que le C, sous linux ?
Tu as l'air bon en C et en assembleur mais il te faudrait connaître d'autres choses je pense.
hélas je ne blague pas. Une gestion automatique de la mémoire ajoute inévitablement un overhead non négligeable. Je ne connais aucun langage compilé qui offre une gestion de la mémoire avec "garde-fous" (les smart-pointer du C++ ou les bibliothèques genre efence sont des "rustines" dans le sens ou il est assez facile de les mettre en défaut). Aussi, je pense que pour les couches de bas niveau, le développeur dois se reposer sur un algorithme sain et une programmation propre. Il doit éviter les facilités qu'offre certains langages qui automatise certaine tache de gestion. Pour les applications cependant, il ne faut pas se priver (dans la mesure où on ne code pas un bout de code critique) !
Cependant, il est toujours possible faire rajouter du code à la compilation pour valider les accès mémoire (genre purify ou dans une moindre mesure valgrind). Mais cela pose le problème de l'exhaustivité des tests.....
PS. je ne code (quasiment) pas en ASM et je pense connaitre plusieurs langages de programmation, dont une bonne partie non compilé (...)
Une gestion automatique de la mémoire ajoute inévitablement un overhead non négligeable.
Et quand les tests eux-même prouvent le contraire ?[1]
Je ne connais aucun langage compilé qui offre une gestion de la mémoire avec "garde-fous"
Moi je connais[2] juste ocaml, mlton, smlnj, bigloo, cmucl, et encore c'est dans la sous-catégorie de ceux qui ont les même performances que C à moins de 5% près.
Ça me fascine à quel point les gens en général et les linuxiens en particulier s'accrochent de toutes leurs forces à leurs vieux langages qui génèrent un nombre incalculable de segfault et de trous de sécurité qui n'existeraient même pas si on voulait bien essayer de consacrer un peu de temps à utiliser les résultats de la recherche en informatique des années 60/70 (c'est pas trop demander en théorie). Le pire c'est que sous Linux je pense que vous êtes une majorité de programmeurs de ton avis.
J'ai l'impression que de débat dérape: j'ai simplement dit que chaque langage possède sont domaine de prédilection. Le bench dont tu propose le lien semble aussi l'indiquer. Par exemple, pour le calcul scientifique, aucun langage ne fait mieux que les langage bas niveau (C, fortarna)... au prix d'une plus grande difficulté de programmation.
Je te réponds que ton "overhead non négligeable" est battu en brèche par le comparatif proposé. Et je te réponds qu'il existe des langages compilés avec systèmes de gestion automatique de mémoire, le contraire de ce que tu affirmais avant, et je te cite même des exemples et je te donne un lien. Je ne vois pas en quoi ça dérape, tu ne réponds même plus à mes arguments.
C'est plutôt toi qui change le débat si tu veux parler de "domaine de prédilection" des langages (ce n'est pas ce dont on parle, on parle d'utiliser un langage avec gestion automatique de la mémoire pour quelque chose comme GdkPixbuf) ou bien encore de calcul scientifique.
Moi je te réponds juste qu'affirmer qu'il n'existe pas de langage compilé avec gestion automatique de la mémoire est faux, et que parler d'"overhead non négligeable" m'a l'air faux d'après les résultats qu'on peut lire en suivant mon lien.
Je te réponds que ton "overhead non négligeable" est battu en brèche par le comparatif proposé.
cela reste un bench: sur un produit matriciel la vesion C est nettement plus rapide que celle OCalm (presque 40%).... Cela reste un point particulier j'en conviens.
Moi je te réponds juste qu'affirmer qu'il n'existe pas de langage compilé avec gestion automatique de la mémoire est faux, et que parler d'"overhead non négligeable" m'a l'air faux d'après les résultats qu'on peut lire en suivant mon lien.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...). Le tout est de savoir si il est négligeable. Dans certain cas il l'est, ou du moins il est acceptable; dans d'autre il ne l'est pas. Pour ma part, je pense que dans les couches bas niveau il ne l'est pas. Il ne parait pas choquant de dire que GdkPixbuf est un composant "bas niveau" dans le sens ou on peut "empiler dessus" plusieurs couches logicielle.
Je suis d'accord qu'il ne s'agit que d'un bench, mais ce bench a le bon goût d'être relativement complet par rapport aux autres puisqu'il aborde plusieurs types d'algo différents, et n'oublie pas de tester la consommation mémoire. Si tu veux encore parler de produit matriciel ou de calcul scientifique, je ne me battrai pas sur ce point pour la simple raison que je ne connais pas assez ce domaine, et il est possible que la stratégie d'allocation mémoire de ocaml (ou d'un autre équivalent) soit peu compatible avec les données et algorithmes en jeu.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...)
Ben je suis désolé je suis pas d'accord. Sur les processeurs modernes par exemple, les règles d'optimisation pour produire un code assembleur performant sont tellement complexes et nombreuses que même si optimiser une petite boucle sera plus rapide à la main, pour un algorithme plus long il vaudra mieux l'écrire en C et avoir un compilateur performant (ou un autre langage).
Ton argument, même s'il a l'air théoriquement séduisant, n'est pas vrai en toute circonstance, en particulier dans celles où les choses à prendre en compte sont trop nombreuses ou trop complexes pour l'esprit humain.
Dans le cas de l'allocation mémoire (mais tu parlais du cas général dans cet argument-là), je suis d'accord qu'en théorie une gestion automatique devrait impacter les performances. On voit que pour le calcul matriciel comme tu en parler, gcc est nettement devant. Mais pour fibonacci ocaml est nettement devant ! Alors que penser ?
Je pense que toutes choses considérées, ça vaut le coup de perdre quelques pourcents (on en est là) de performance brute en utilisant un langage à gestion automatique de la mémoire, pour l'énorme prix de supprimer magiquement 95% des segfaults et une bonne partie (je ne saurais pas la chiffrer) des problèmes de sécurité. Après tout, les processeurs augmentent leur puissance annuellement à un rythme plus rapide que quelques pourcents - et on utilise aussi des processeurs qui sont en permanence en famine d'accès mémoire, ce qui montre qu'il y a déjà beaucoup de performance gâchée pour des buts beaucoup moins nobles.
Bien sûr c'est là le point essentiel de notre divergence :)
Le pire c'est que sous Linux je pense que vous êtes une majorité de programmeurs de ton avis.
Personnellement, je programme en C, et je vais t'expliquer pourquoi : lorsque je veux faire un appel-système, en C, il me suffit d'un coup de RTFM. Dans tous les autres langages, je suis perdu (sauf en shell, mais ce langage a beaucoup trop de limitations).
Si, un jour, un autre langage (comme Java, par exemple) venait avec une aide semblable embarquée dans les systèmes Linux, j'essayerais sans doute, mais d'ici-là, je préfère m'en tenir à mon bon vieux C.
En résumé, m^eme s'il est antédiluvien, je préfère programmer avec, parce que je sais que je trouverai toujours une solution à mes problèmes, et où la trouver.
Quel genre de programme tu fais pour avoir besoin de faire des syscalls tout le temps ? En general tu as une bibliotheque autour du langage qui cache les syscalls et on n'a pas besoin de plus... Par exemple je sais qu'en perl il "manque" des syscalls mais que je n'ai jamais besoin d'y acceder (et au passage si tu cherches de la doc bien faite sur un langage, la serie de man de perl plus perldoc sont encore bien plus efficaces que les man du C).
Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.
Quel genre de programme tu fais pour avoir besoin de faire des syscalls tout le temps ?
Ca dépend. Je programme pour plusieurs raisons :
1) pour m'amuser. Là, je me déchaine sur les appels-système, parce que c'est ce qui m'amuse le plus. Cela dit, les programmes de ce genre ne servent à rien d'autre qu'à me distraire (dernièrement, j'ai codé un programme dont le seul intérêt était que l'on pouvait changer ou même arrêter dynamiquement son interface, mais qui ne faisait rien d'utile, juste pour voir si c'était possible), donc, sitôt débogués, sitôt oubliés.
2) pour développer un projet. Là, je fais assez peu d'appels-système, mais en revanche, dès que je dois en faire un (genre lancer plusieurs threads, forker, créer une socket...), je le fais sans hésiter. Sans le C, je nagerais...
En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .
Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.
Bref, comme bien des programmeurs, je fais avant tout ce qui m'amuse...
Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.
Nous sommes donc d'accord :-). Et, pour apporter de l'eau à ton moulin, j'ajoute que je trouve effectivement la gestion de la mémoire pénible en C, ce qui me fait perdre du temps par rapport à un code Java. Mais j'aime tant les appels-système... :-)
Au fait, est-ce que quelqu'un sait où on peut trouver la liste des appels-systèmes Windows en C? J'aimerais comparer avec les appels-systèmes Linux, mais je n'ai pas trouvé, même sur mon Google favori :-( .
2) pour développer un projet. Là, je fais assez peu d'appels-système, mais en revanche, dès que je dois en faire un (genre lancer plusieurs threads, forker, créer une socket...), je le fais sans hésiter. Sans le C, je nagerais...
Il y a appel système et appel système... fork, socket ou open sont très bien supportés dans plein de langages, en C ou en Perl par exemple. Sans le C, en Perl, je peux t'assurer que tu ne nagerais pas (en Python ou en Ruby aussi, je ne veux pas seulement prêcher pour ma chapelle).
En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .
Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.
Non mais faut voir aussi... dans les deux listes suivantes, tu utilises plutôt quoi :
1. fork, socket, read, write
2. statfs, brk, getdents, init_module
La première liste est un exemple de ce qui est dispo en Perl (utile dans les programmes), la deuxième de ce qui n'est pas dispo en Perl[1] (utile en gros seulement dans les applis système). Si tu as déjà utilisé directement quelque chose de la deuxième liste, ça n'a pas dû être très souvent (sauf si tes applis sont monstrueusement proches du système).
[1] en fait ils sont dispo mais c'est juste pas aussi simple qu'un appel de fonction Perl traditionnel
Les langages compilés (C/C++/fortran/...) reste incontournable
Pas d'accord du tout la ... si on pouvais se débarrasser du Fortran ce serrait un grand progrés ... Il avait de gros avantages à l'epoque (meilleur compilo et facilité de vectorisation) mais maintenant se serrait pas mal de l'oublier un peu ...
je n'imagine pas utiliser un langage de très haut niveau [...] pour implémenter [...] un toolkit graphique.
Et bien justement tu est à coté de la plaque. Pour pouvoir manipuler des abstractions comme "une fenètre", "un ecran", "une police" ... tu as interet d'avoir un langage de haut niveau sinon tu vas te retrouver comme à la bonne époque ou pour dessiner sur l'ecran il fallait manipuler directement une partie de la memoire video.
Regarde GTK, ils se battent pour avoir une bilbliothèque de haut niveau avec un langage qui n'offre que peu d'abstraction : le résultat est une bibliothèque pseudo-objet qui est compléxifié à outrance a cause du langage utilisé de base.
(je ne critique pas du tout GTK, mais on vois bien qu'ils ont décidé de proposer des abstraction -et c'est normal- qui ne sont pas facilement manipulable avec le langage sous-jacent)
Ensuite niveau perf, d'autres langages de beaucoup plus haut niveau propose une rapidité d'éxécution quasi-égale et un niveau de sécurité du code infiniment meilleur (OCaml et Eiffel par exemple).
Pour finir je pense que les langages de trop bas niveau vont se faire exploser quand nous commencerons a avoir plusieurs processeurs ou plusieurs machines pour éxécuter nos applications; car optimiser une aplication "par le haut" est infiniment plus profitable que "par le bas".
bon, il n'y a pas que ca, il y a aussi les typages de psycho-rigides.
bon, je me debrouille en C et C++ ...
par contre, je me posais la question suivante ... si un langage de programmation doit etre independant de l'architecture ...
pourquoi avoir : short int, int, long int, long long int, float, double, long double, ... sans oublier les signed et unsigned ... avec des contraintes chiantes ?
alors qu'a la rigeur un type numerique avec la possibilité de forcer un contexte :
- signé ou non
- virgules fixe ou flottante
- une borne superieure et inferieure
par contre, je me posais la question suivante ... si un langage de programmation doit etre independant de l'architecture ...
Le mythe de la "portabilité" du C a la peau dure. Il suffit de regarder la tronche d'un code C ultra-portable comme par exemple gzip pour voir qu'il faut que le programmeur rustine dans tous les coins si il veut être compilé "partout". Ce qu'il y a c'est que le C est tellement proche de l'assembleur dans l'esprit qu'il n'était je pense pas envisageable de définir une fois pour toute des types de base de taille constante qui risquaient d'impacter beaucoup trop les performances lorsque le support natif de la taille en question n'était pas disponible.
le C ca pue ... et le pire est qu'il existe des trucs tres bien et plus performant que le C si on ne code pas dessus comme on a appris à faire du C ...
quand je code j'applique le modele suivant :
- tout ce qui peut etre fait avec un machin le plus portable qui soit au risque ( et non au prix ) de la perf, je prend de l'interpreté ( LISP / perl principalement )
- tout ce qui doit etre un peu portable mais dont je doit pouvoir garantir une certaine reactivité, je prend un macro assembleur ( C / C++ principalement et ADA depuis peu )
- tout ce qui necessite une gestion critique du temps, je prends un assembleur ( 80x86 & PPC principalement )
sinon, au niveau assembleur, il y a des gens qui ont eu une idee geniale : faire un macro assembleur sur un processeur à registre et pile avec la possibilité d'avoir un support objet au niveau de l'assembleur.
et le pire c'est que ca marche ...
je ne vais pas me faire le perroquet de ce projet, donc je n'en parlerai pas plus, mais pour info, il est lié à la recherche de la perle parfaite.
si un gars un jour se dit que prendre ce projet et le coller sur un crusoë en natif, ca peut etre cool puisque l'on peut recoder les opcodes à la volé ...
... c'est comme dire qu'un jour on marchera sur la lune ou que l'on volera dans le ciel ... c'est de la science fiction ;)
au niveau assembleur, il y a des gens qui ont eu une idee geniale : faire un macro assembleur sur un processeur à registre et pile avec la possibilité d'avoir un support objet au niveau de l'assembleur.
< humour >
Ca y est, ils vont nous faire un helloworld en assembleur orienté objet. Pour l'héritage, on fait :
Vu qu'une faille similaire a été découverte dans QT et qu'elle est programmée en C++ aux dernières nouvelles, je ne comprends pas trop ton acharnement sur ce vénérable langage qu'est le C...
En suivant le lien d'Aurel, on s'aperçoit que s'il y a bien moyen de nuire "offert" cela ne va pas jusqu'à la prise de contrôle de la machine.
Les nuisances possibles seraient plutôt le crash de l'appli ou plus perturbant le hogging du processeur.
2 cts
# Ajout
Posté par GEDsismik (site web personnel) . Évalué à 2.
[^] # Re: Ajout
Posté par aurel . Évalué à 1.
# C
Posté par gc (site web personnel) . Évalué à -5.
[^] # Re: C
Posté par Nicolas LAURENT . Évalué à 1.
mais bien sûr, invoquons une jvm pour afficher des PNG....
Les langages compilés (C/C++/fortran/...) reste incontournables et ce n'est pas prés de changer (ne serait-ce que pour coder les interpreteurs). Or, avec ces langages, il n'y a pas de garde barrière. C'est bien au programmeur de réfléchir (une vertue de plus en plus rare on dirait). Cependant, l'avantage c'est la performance. Je sais, beaucoup vont me dire qu'aujourd'hui ce n'est plus un problème, que les machines sont puissantes, que les ressources (mémoire, CPU, disque, ..) sont peu onéreurses.... Mais, personnellement, je trouve ce genre de raisonnement absurde. Evidement, je ne dis pas qu'il faut tout coder en C sous pretexte de performance. Cependant, je n'imagine pas utiliser un langage de très haut niveau et/ou interprété pour implémenter des "briques de base" comme un toolkit graphique.
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 3.
Dis-moi, où est-ce que j'ai parlé de JVM, de très haut niveau, d'interprété ?
Et, dis-moi, est-ce que tu es au courant qu'il existe au moins un langage compilé avec gestion automatique de la mémoire qui a exactement les même performances que le C, sous linux ?
Tu as l'air bon en C et en assembleur mais il te faudrait connaître d'autres choses je pense.
[^] # Re: C
Posté par Nicolas LAURENT . Évalué à -1.
Cependant, il est toujours possible faire rajouter du code à la compilation pour valider les accès mémoire (genre purify ou dans une moindre mesure valgrind). Mais cela pose le problème de l'exhaustivité des tests.....
PS. je ne code (quasiment) pas en ASM et je pense connaitre plusieurs langages de programmation, dont une bonne partie non compilé (...)
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 5.
Et quand les tests eux-même prouvent le contraire ?[1]
Je ne connais aucun langage compilé qui offre une gestion de la mémoire avec "garde-fous"
Moi je connais[2] juste ocaml, mlton, smlnj, bigloo, cmucl, et encore c'est dans la sous-catégorie de ceux qui ont les même performances que C à moins de 5% près.
Ça me fascine à quel point les gens en général et les linuxiens en particulier s'accrochent de toutes leurs forces à leurs vieux langages qui génèrent un nombre incalculable de segfault et de trous de sécurité qui n'existeraient même pas si on voulait bien essayer de consacrer un peu de temps à utiliser les résultats de la recherche en informatique des années 60/70 (c'est pas trop demander en théorie). Le pire c'est que sous Linux je pense que vous êtes une majorité de programmeurs de ton avis.
[1] http://www.bagley.org/~doug/shootout/craps.shtml(...) (et encore, GCC a du faire moins de progrès que ses concurrents depuis 2001)
[2] "connaitre" est un bien grand mot, je n'ai jamais programmé sérieusement avec (à mon grand regret)
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 1.
Il n'y a qu'à voir la fabuleuse raclée dans le score qu'est en train de se prendre mon commentaire initiateur de ce fil de discussion :)
[^] # Re: C
Posté par Nicolas LAURENT . Évalué à 1.
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 2.
C'est plutôt toi qui change le débat si tu veux parler de "domaine de prédilection" des langages (ce n'est pas ce dont on parle, on parle d'utiliser un langage avec gestion automatique de la mémoire pour quelque chose comme GdkPixbuf) ou bien encore de calcul scientifique.
Moi je te réponds juste qu'affirmer qu'il n'existe pas de langage compilé avec gestion automatique de la mémoire est faux, et que parler d'"overhead non négligeable" m'a l'air faux d'après les résultats qu'on peut lire en suivant mon lien.
[^] # Re: C
Posté par Nicolas LAURENT . Évalué à 1.
cela reste un bench: sur un produit matriciel la vesion C est nettement plus rapide que celle OCalm (presque 40%).... Cela reste un point particulier j'en conviens.
Moi je te réponds juste qu'affirmer qu'il n'existe pas de langage compilé avec gestion automatique de la mémoire est faux, et que parler d'"overhead non négligeable" m'a l'air faux d'après les résultats qu'on peut lire en suivant mon lien.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...). Le tout est de savoir si il est négligeable. Dans certain cas il l'est, ou du moins il est acceptable; dans d'autre il ne l'est pas. Pour ma part, je pense que dans les couches bas niveau il ne l'est pas. Il ne parait pas choquant de dire que GdkPixbuf est un composant "bas niveau" dans le sens ou on peut "empiler dessus" plusieurs couches logicielle.
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 2.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...)
Ben je suis désolé je suis pas d'accord. Sur les processeurs modernes par exemple, les règles d'optimisation pour produire un code assembleur performant sont tellement complexes et nombreuses que même si optimiser une petite boucle sera plus rapide à la main, pour un algorithme plus long il vaudra mieux l'écrire en C et avoir un compilateur performant (ou un autre langage).
Ton argument, même s'il a l'air théoriquement séduisant, n'est pas vrai en toute circonstance, en particulier dans celles où les choses à prendre en compte sont trop nombreuses ou trop complexes pour l'esprit humain.
Dans le cas de l'allocation mémoire (mais tu parlais du cas général dans cet argument-là), je suis d'accord qu'en théorie une gestion automatique devrait impacter les performances. On voit que pour le calcul matriciel comme tu en parler, gcc est nettement devant. Mais pour fibonacci ocaml est nettement devant ! Alors que penser ?
Je pense que toutes choses considérées, ça vaut le coup de perdre quelques pourcents (on en est là) de performance brute en utilisant un langage à gestion automatique de la mémoire, pour l'énorme prix de supprimer magiquement 95% des segfaults et une bonne partie (je ne saurais pas la chiffrer) des problèmes de sécurité. Après tout, les processeurs augmentent leur puissance annuellement à un rythme plus rapide que quelques pourcents - et on utilise aussi des processeurs qui sont en permanence en famine d'accès mémoire, ce qui montre qu'il y a déjà beaucoup de performance gâchée pour des buts beaucoup moins nobles.
Bien sûr c'est là le point essentiel de notre divergence :)
[^] # Re: C
Posté par CoinKoin . Évalué à 2.
Personnellement, je programme en C, et je vais t'expliquer pourquoi : lorsque je veux faire un appel-système, en C, il me suffit d'un coup de RTFM. Dans tous les autres langages, je suis perdu (sauf en shell, mais ce langage a beaucoup trop de limitations).
Si, un jour, un autre langage (comme Java, par exemple) venait avec une aide semblable embarquée dans les systèmes Linux, j'essayerais sans doute, mais d'ici-là, je préfère m'en tenir à mon bon vieux C.
En résumé, m^eme s'il est antédiluvien, je préfère programmer avec, parce que je sais que je trouverai toujours une solution à mes problèmes, et où la trouver.
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 3.
Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.
[^] # Re: C
Posté par CoinKoin . Évalué à 2.
Ca dépend. Je programme pour plusieurs raisons :
1) pour m'amuser. Là, je me déchaine sur les appels-système, parce que c'est ce qui m'amuse le plus. Cela dit, les programmes de ce genre ne servent à rien d'autre qu'à me distraire (dernièrement, j'ai codé un programme dont le seul intérêt était que l'on pouvait changer ou même arrêter dynamiquement son interface, mais qui ne faisait rien d'utile, juste pour voir si c'était possible), donc, sitôt débogués, sitôt oubliés.
2) pour développer un projet. Là, je fais assez peu d'appels-système, mais en revanche, dès que je dois en faire un (genre lancer plusieurs threads, forker, créer une socket...), je le fais sans hésiter. Sans le C, je nagerais...
En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .
Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.
Bref, comme bien des programmeurs, je fais avant tout ce qui m'amuse...
Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.
Nous sommes donc d'accord :-). Et, pour apporter de l'eau à ton moulin, j'ajoute que je trouve effectivement la gestion de la mémoire pénible en C, ce qui me fait perdre du temps par rapport à un code Java. Mais j'aime tant les appels-système... :-)
Au fait, est-ce que quelqu'un sait où on peut trouver la liste des appels-systèmes Windows en C? J'aimerais comparer avec les appels-systèmes Linux, mais je n'ai pas trouvé, même sur mon Google favori :-( .
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 2.
Il y a appel système et appel système... fork, socket ou open sont très bien supportés dans plein de langages, en C ou en Perl par exemple. Sans le C, en Perl, je peux t'assurer que tu ne nagerais pas (en Python ou en Ruby aussi, je ne veux pas seulement prêcher pour ma chapelle).
En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .
Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.
Non mais faut voir aussi... dans les deux listes suivantes, tu utilises plutôt quoi :
1. fork, socket, read, write
2. statfs, brk, getdents, init_module
La première liste est un exemple de ce qui est dispo en Perl (utile dans les programmes), la deuxième de ce qui n'est pas dispo en Perl[1] (utile en gros seulement dans les applis système). Si tu as déjà utilisé directement quelque chose de la deuxième liste, ça n'a pas dû être très souvent (sauf si tes applis sont monstrueusement proches du système).
[1] en fait ils sont dispo mais c'est juste pas aussi simple qu'un appel de fonction Perl traditionnel
[^] # Re: C
Posté par CoinKoin . Évalué à 2.
Bien vu : je ne les ai jamais employés. Bon, ben, je vais peut-être essayer le Perl, puisque c'est ça...
[^] # Re: C
Posté par thecat . Évalué à 1.
Pas d'accord du tout la ... si on pouvais se débarrasser du Fortran ce serrait un grand progrés ... Il avait de gros avantages à l'epoque (meilleur compilo et facilité de vectorisation) mais maintenant se serrait pas mal de l'oublier un peu ...
je n'imagine pas utiliser un langage de très haut niveau [...] pour implémenter [...] un toolkit graphique.
Et bien justement tu est à coté de la plaque. Pour pouvoir manipuler des abstractions comme "une fenètre", "un ecran", "une police" ... tu as interet d'avoir un langage de haut niveau sinon tu vas te retrouver comme à la bonne époque ou pour dessiner sur l'ecran il fallait manipuler directement une partie de la memoire video.
Regarde GTK, ils se battent pour avoir une bilbliothèque de haut niveau avec un langage qui n'offre que peu d'abstraction : le résultat est une bibliothèque pseudo-objet qui est compléxifié à outrance a cause du langage utilisé de base.
(je ne critique pas du tout GTK, mais on vois bien qu'ils ont décidé de proposer des abstraction -et c'est normal- qui ne sont pas facilement manipulable avec le langage sous-jacent)
Ensuite niveau perf, d'autres langages de beaucoup plus haut niveau propose une rapidité d'éxécution quasi-égale et un niveau de sécurité du code infiniment meilleur (OCaml et Eiffel par exemple).
Pour finir je pense que les langages de trop bas niveau vont se faire exploser quand nous commencerons a avoir plusieurs processeurs ou plusieurs machines pour éxécuter nos applications; car optimiser une aplication "par le haut" est infiniment plus profitable que "par le bas".
[^] # Re: C
Posté par Gniarf . Évalué à 2.
il faudra tout de même des couches basses et des langages de bas niveau pour les coder.
[^] # Re: C
Posté par Mouns (site web personnel) . Évalué à 1.
je t'aime !
je ne suis pas seul à crier !
mon ami ! mon amour ! ma mie !
cachez ce malloc que je ne saurais voir !
\\o o//
bon, il n'y a pas que ca, il y a aussi les typages de psycho-rigides.
bon, je me debrouille en C et C++ ...
par contre, je me posais la question suivante ... si un langage de programmation doit etre independant de l'architecture ...
pourquoi avoir : short int, int, long int, long long int, float, double, long double, ... sans oublier les signed et unsigned ... avec des contraintes chiantes ?
alors qu'a la rigeur un type numerique avec la possibilité de forcer un contexte :
- signé ou non
- virgules fixe ou flottante
- une borne superieure et inferieure
c pas facile mais c beaucoup plus simple :)
ya d'autres choses aussi ...
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 3.
Tu es belle ! *smack*
par contre, je me posais la question suivante ... si un langage de programmation doit etre independant de l'architecture ...
Le mythe de la "portabilité" du C a la peau dure. Il suffit de regarder la tronche d'un code C ultra-portable comme par exemple gzip pour voir qu'il faut que le programmeur rustine dans tous les coins si il veut être compilé "partout". Ce qu'il y a c'est que le C est tellement proche de l'assembleur dans l'esprit qu'il n'était je pense pas envisageable de définir une fois pour toute des types de base de taille constante qui risquaient d'impacter beaucoup trop les performances lorsque le support natif de la taille en question n'était pas disponible.
[^] # Re: C
Posté par Mouns (site web personnel) . Évalué à 1.
le C ca pue ... et le pire est qu'il existe des trucs tres bien et plus performant que le C si on ne code pas dessus comme on a appris à faire du C ...
quand je code j'applique le modele suivant :
- tout ce qui peut etre fait avec un machin le plus portable qui soit au risque ( et non au prix ) de la perf, je prend de l'interpreté ( LISP / perl principalement )
- tout ce qui doit etre un peu portable mais dont je doit pouvoir garantir une certaine reactivité, je prend un macro assembleur ( C / C++ principalement et ADA depuis peu )
- tout ce qui necessite une gestion critique du temps, je prends un assembleur ( 80x86 & PPC principalement )
sinon, au niveau assembleur, il y a des gens qui ont eu une idee geniale : faire un macro assembleur sur un processeur à registre et pile avec la possibilité d'avoir un support objet au niveau de l'assembleur.
et le pire c'est que ca marche ...
je ne vais pas me faire le perroquet de ce projet, donc je n'en parlerai pas plus, mais pour info, il est lié à la recherche de la perle parfaite.
si un gars un jour se dit que prendre ce projet et le coller sur un crusoë en natif, ca peut etre cool puisque l'on peut recoder les opcodes à la volé ...
... c'est comme dire qu'un jour on marchera sur la lune ou que l'on volera dans le ciel ... c'est de la science fiction ;)
[^] # Re: C
Posté par CoinKoin . Évalué à 2.
< humour >
Ca y est, ils vont nous faire un helloworld en assembleur orienté objet. Pour l'héritage, on fait :
heritl %eax %ecx
< /humour >
:-)
[^] # Re: C
Posté par Mouns (site web personnel) . Évalué à 1.
la double translation des pointeurs avec gestion des bornes sur les compatible 80386->PentiumIV et sur les PPC depuis le 601 ou le 603.
mais le modele plat de memoire avec superposition des espaces code/donnees/pile est encore de vigueur.
( et paf paf le buffer overflow )
[^] # Re: C
Posté par Frédéric Lopez . Évalué à 1.
[^] # Re: C
Posté par gc (site web personnel) . Évalué à 2.
# Ça ne va pas jusque là
Posté par Sisyphe Plâtrier . Évalué à 5.
Les nuisances possibles seraient plutôt le crash de l'appli ou plus perturbant le hogging du processeur.
2 cts
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.