Si quelqu'un les a déjà essayés ou connait leurs limites/avantages/inconvénients, je suis preneur.
dmalloc http://dmalloc.com/
ccmalloc http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/
Electric Fence (efence) http://perens.com/FreeSoftware/
Valgrind http://developer.kde.org/~sewardj/
Boehm Collector http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Parallel Collector on Message Passing Environment http://www.yl.is.s.u-tokyo.ac.jp/gc/dgc/
LeakTracer http://www.andreasen.org/LeakTracer/
MemWatch http://www.linkdata.se/sourcecode.html
Memprof http://people.redhat.com/otaylor/memprof/
Aller plus loin
- Discussion sur Slashdot (10 clics)
# La pièce jointe qui n'est pas passée
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
http://www.andreasen.org/LeakTracer/(...)
Fuites de mémoire
Linux et d'autres Unix
Domaine public
Sans recompilation
C++
Version 2.2
MemWatch
http://www.linkdata.se/sourcecode.html(...)
Fuites de mémoire
Domaine public
Nécessite une recompilation
C
Version 2.67
Memprof
http://people.redhat.com/otaylor/memprof/(...)
Profil de la mémoire allouée et détection des fuites (avec GUI)
GPL
C. C++ ?
Sans recompilation
Version 0.4.1
dmalloc
http://dmalloc.com/(...)
libre
Multi-plateforme
C/C++
Nécessite une recompilation
Supporte le multi-thread
Version 4.8.2
ccmalloc
http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/(...)
Fuites de mémoire et problèmes de mémoire
GPL
Linux et Solaris
Nécessite une recompilation
Version 0.3.9
Electric Fence (efence)
http://perens.com/FreeSoftware/(...)
GPL
Détection des dépassements de limites
C
Version 2.2.2
Valgrind
http://developer.kde.org/~sewardj/(...)
Problèmes de mémoire (dont fuites)
Pour x86 linux.
Sans recompilation
Pas de support multi-thread
C/C++
Disponible seulement en snapshot
Boehm Collector
http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)
Garbage collector et détecteur de fuites
Licence compatible Debian en tout cas
Multi-plateforme
C/C++
Parallel Collector on Message Passing Environment
http://www.yl.is.s.u-tokyo.ac.jp/gc/dgc/(...)
Licence inconnue (pas de téléchargement)
Adresse de téléchargement invalide
[^] # Re: La pièce jointe qui n'est pas passée
Posté par MagicNinja . Évalué à 2.
>www.hpl.hp.com/personal/Hans_Boehm/gc/
>Garbage collector et détecteur de fuites
>Licence compatible Debian en tout cas
>Multi-plateforme
>C/C++
A verifier, mais je crois que c'est le GC utilise par gnustep et gobjc (compilateur gcc pour objective-c)
[^] # j'en rajouterai un
Posté par Troy McClure (site web personnel) . Évalué à 10.
http://www.cbmamiga.demon.co.uk/mpatrol/(...)
GPL
Peut s'utiliser avec ou sans recompilation,
Possibilité d'utiliser l'option -fcheck-memory-usage de gcc
Un joli manuel bien fait:
http://www.cbmamiga.demon.co.uk/mpatrol/files/mpatrol.pdf(...)
Multi-plateforme, C/C++
Il a l'air très complet, pour l'instant je ne l'ai utilisé que sur wmc², et il a été efficace ;)
[^] # Re: j'en rajouterai un
Posté par Laurent Mazet (site web personnel) . Évalué à 6.
J'ai du les tester a peu pres tous et je n'avais retenu que trois :
- Memprof. Peu performant mais tres simple d'utilisation, souvent suffisant pour tracker les memory leak sur de petits projets
- Dmalloc. Tres puissant mais trop complexe a maitriser. Hors les exemples d'utilisation decris dans la doc, c'est quasiement inutilisable.
- Mpatrol. Tres complet et finalement pas trop dur a utiliser.
Par contre, aucun ne permet de tester l'utilisation de variables non initialisees (fonction tres pratique de purify).
Il manque une derniere reference c'est Insure++ de Parasoft. Mais, honnettement le produit est tres cher et assez decevant (pas tres intuitif lorsqu'on travaille en C++, tres verbeux, et moins complet que Purify). Je ne mets pas de reference, cela serait de la pub indirecte :-)
Laurent
# Tests persos
Posté par Gnurou (site web personnel) . Évalué à 10.
-electric fence: sans doute le plus connu/utilisé. Il marque les zones mémoires libérées de telle sorte que si on essaie de lire à un endroit libéré, le programme plante à coup sûr. Après, un coup de gdb suffit à repérer l'erreur. Inconvénient: la mémoire ne peut être utilisé qu'une fois. Autant dire qu'avec un gros programme, il en faut des quantités pharaoniques...
-memprof: petit outil très sympa écrit en Gtk. Pas besoin de linker avec quoi que ce soit. Il affiche les leaks qu'il a trouvés et sert aussi de profiler. C'est sans doute l'outil qui m'a permis d'en repérer le plus - le plus sympa à utiliser aussi. Par contre, ca fait un bail qu'il n'a pas été mis à jour...
-je n'ai jamais utilisé Valgrind, mais il a une très bonne réputation. Notamment celle d'etre utilisé pour KDE.
Pour le reste, je ne connais pas vraiment. La news m'en a fait découvrir quelques uns. D'après des potes Windowsiens, aucun de ces outils n'est aussi bon que Purify, que je n'ai jamais testé personnellement, il m'est donc impossible de me prononcer. En tout cas, je me suis toujours passé de Purify, et tous ces outils me satisfont pleinement...
[^] # Re: Tests persos
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
[^] # Re: Tests persos
Posté par Troy McClure (site web personnel) . Évalué à 10.
Et sinon, c'est vrai que l'instrumentation du code pour vérifier les accès aux tableaux, c'est assez capital.. j'ai toujours pas compris si l'option '-fcheck-memory-usage' de gcc est plus ou moins équivalente à ça [j'ai pas réussi à l'utiliser avec mpatrol].. D'ailleurs cette option avait été originalement créée pour http://www.gnu.org/software/checker/checker.html(...) , programme que je n'ai jamais réussi à utiliser et qui a l'air d'être mort...
[^] # Re: Tests persos
Posté par Troy McClure (site web personnel) . Évalué à 10.
il detecte absolument tous les accès aux variables non initialisées, c'est vraiment la catégorie au-dessus des mallocs debuggers :) Après avoir survolé en diagonale le manuel, j'en ai retenu qu'il fonctionne en émulant le processeur (un pentium du base) ce qui lui permet de chopper absolument tous les trucs bizarres. Et le programme continue à fonctionner à une vitesse tout a fait acceptable.
Y'a juste les signaux qui foutent un peu le bordel, mais vu que c'est un programme en développement (release valgrind-20020315b), il marche déjà formidablement bien.
Bref, je suis très très enthousiaste ! je crois c'est la vraie alternative à purify.
Et sinon, comme dit plus bas, je pense aussi que cette news mériterait de passer en première page.
[^] # Re: Tests persos
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
[^] # Re: Tests persos
Posté par Laurent Mazet (site web personnel) . Évalué à 3.
Merci pour le test.
Laurent
[^] # Re: Tests persos
Posté par michael lefevre (site web personnel) . Évalué à 1.
Y'a des mecs qui l'utilise donc en interne pour debugger les serveurs!
[^] # Purify n'est pas sans défaut..
Posté par reno . Évalué à 10.
On peut filtrer bien sur ce type d'erreur, mais c'est dommage: s'il y a vraiment une lecture de variable non-initialisée on risque de ne pas la voir..
D'après ce que j'ai lu valgrind n'a pas ce probleme (il en a d'autres: multi-threading)..
[^] # Re: Tests persos
Posté par pasBill pasGates . Évalué à 1.
Il se trouve dans le resource kit et/ou le SDK.
Ca permet de modifier les allocations pour n'importe quel executable(faut juste lancer l'outil en specifiant le nom du soft avant de lancer ledit soft) de plusieurs manieres:
- "full": chaque allocation est placee a la fin d'une page avec une guard page apres --> AV direct si il y a un ovverun, et il detecte les underrun en remplissant le debut de la page avec un pattern
- "light": plusieurs alloc par page, mais avec des pattern pour detecter les overrun/underrun, defaut: le probleme n'est detecte qu'au moment du free. Avantage: ca bouffe vachement moins de RAM.
Pas besoin de torcher ca a coup de [-], ca pourrait servir pour les softs libres developpes sous Windows.
[^] # Re: Tests persos
Posté par Dugland Bob . Évalué à 2.
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je vote pour cette news en première page [++++]
Posté par Olivier M. . Évalué à 10.
Depuis une semaine ou deux, les seules news interessantes sont dans la boite Autres, c'est bien triste.
[^] # Re: Je vote pour cette news en première page [++++]
Posté par homoanonymus . Évalué à -8.
Je m'explique, pour moi cette news c'est quasi du chinois, meme en lisant les posts (si, si, j'essai de me culturer, qui sait un jour j'serais peut etre programmeur !) donc si tu veut faire fuir le neewbie ya pas mieux !
Et deusio, ce post est la preuve meme que les news autres sont quand meme lu (a defaut d'etre compris!) AUTRES ne veut pas dire moins bien, ca veut juste dire autres (elle est facile celle là)
Voilou, j'espere que tu comprends mon point de vue qui n'est surement pas d'exclure les news comme celle là qui pourtant me passe largement au dessus de la tête.
[^] # Re: Je vote pour cette news en première page [++++]
Posté par Pierre Tramo . Évalué à 4.
Je m'explique, pour moi cette news c'est quasi du chinois, meme en lisant les posts (si, si, j'essai de me culturer, qui sait un jour j'serais peut etre programmeur !) donc si tu veut faire fuir le neewbie ya pas mieux !
Franchement, je trouve que le problème est le même avec les news qui passent sur la page principale en ce moment. Personnellement, j'aime les news techniques. Et la plupart des news juridiques, economiques, politiques (cf alenvers dans la news du virus linux) ne m'intéressent que très peu, et me donnent en général mal à la tête.
Tu trouves que les news techniques risquent de rebuter le newbie ? Je ne trouve pas les news actuelles de la page principale très abordables non plus pour un newbie. Regarde celles portant sur l'ICANN, Lessig, les articles sur les brevets, etc.
Attention, je n'ai pas dit qu'elles n'étaient pas importantes pour la communauté. Juste qu'elles n'entrent pas forcément dans mes centres d'intérêts personnels.
Donc, mon avis, c'est que cela manque un peu de technique, effectivement. Bon, ceci dit, on a la faille OpenSSH, ou encore d'excellentes interventions sur Le Hurd aussi. Si je pouvais avoir les nerws de la boîte Autres dans le canard, ce serait déjà un plus.
-1 pour hs total.
[^] # Re: Je vote pour cette news en première page [++++]
Posté par sensei . Évalué à 3.
Comme ça, le canard, il intègre ça vite fait bien fait, en plus, ca permettra même d'avoir les news de deux sites différents pour ceux qui se foutent (existent-ils) de la boite autre...
Allez, je me met pas -1, parce que je veux que les modéros me disent pourquoi ce serait pas possible, ou bien qu'ils le fassent !
C'était ma minute nécessaire...
Co1n Co1n !
[^] # Re: Je vote pour cette news en première page [++++]
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Euh les modéros modèrent et les développeurs daCode développent... En ce moment, nous (les développeurs daCode) bossons plutôt sur la sortie de la version 1.4. Maintenant si tu fournis le patch/correctif, pas de problème.
(l'ordre « qu'ils le fassent ! » est un peu déplacé. Certains pourraient te dire d'aller te faire f..tre)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je vote pour cette news en première page [++++]
Posté par homoanonymus . Évalué à 0.
Ce que je voulais dire c'est que la boite autre n'est pas une poubelle !
Chacun ses centres d'intéret, moi la prog c'est pas mon truc mais ca me choquerais pas outre mesure si la news passait en première page.
Réciproquement une news politicojuridicoeconomico... me gènerais pas dans la boite autre, mème si souvent c'est rudement important (l'avenir du libre se joue parfois).
Mais le gros problème, c'est que tout ne peut pas passer en première page. La solution idéale serait de personaliser ses choix comme propose alenvert, mais en attendant...
Quoiqu'il y a peut-etre une solution simple:
Si le nombre de commentaires dépasse une certaine limite disons 27, la news zappe directement à la première page (et réciproquement, si une news principale n'attire pas plus de 5 commentaires=>case autres)
C'est possible ?
---> -1 car désolé les gars de poluer votre news avec ce "débat".
# fonctions de la libc
Posté par togno . Évalué à 10.
Memory -> Memory Allocation -> Allocation Debugging
En gros, vous appelez une fonction mrtrace() au début de votre programme. Et vous définissez une variable d'environnement MALLOC_TRACE qui contiendra le nom d'un fichier où vous allez logguer les traces.
Pour de petits programmes, ça vaut peut-être le coup d'utiliser ça.
[^] # Re: fonctions de la libc
Posté par Yann Droneaud (site web personnel) . Évalué à 7.
ex:
int
main(void)
{
mtrace();
do_the_rest_tm();
muntrace();
return 0;
}
ensuite on lance le programe:
$ MALLOC_TRACE=log.mtrace ./mon_prog
ca genere un fichier de log
on le consulte avec:
$ mtrace ./mon_prog log.mtrace
Ca permet de voir où (la fonction) a été allouer la memoire qui n'a pas été libéré au moment de l'appel a muntrace().
Le probleme c'est que si vous avez une fonction
d'allocation (qui appelle malloc()) c'est toujours cette fonction qui sera indiqué par
mtrace: ca montre pas quelle fonction
a fait la demande d'allocation, mais la fonction
qui a appelé malloc().
Ca reste pratique quand meme, mais il faut savoir
distingué les "fuites" provoqué par la libc elle meme.
# au XXI ème siècle ?
Posté par Dugland Bob . Évalué à -10.
c'est marrant, Smalltalk normalisé en 1980 n'a pas ce problème.
j'ai ma petite liste d'outils à moi :
Lisp
Scheme
Smalltalk
O' caml
objective C
Java
Perl
Python
Haskell
...
à compléter
Le premier qui me parle de GC en C ou en C++ je l'éclate ; je parle de vrais outils !
[^] # Re: au XXI ème siècle ?
Posté par lorill (site web personnel) . Évalué à -5.
BrainFuck ?
[^] # Re: au XXI ème siècle ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à -3.
[OUI]
hop, -1
[^] # Re: au XXI ème siècle ?
Posté par Jean-Yves B. . Évalué à 0.
[1] http://www.eiffel.com(...)
[2] http://smalleiffel.loria.fr(...)
[^] # Re: au XXI ème siècle ?
Posté par Gnurou (site web personnel) . Évalué à 7.
Allez, j'y participe:
Va faire un programme rapide dans un des langages que tu cites - ou un truc bien critique genre un système d'exploitation ou une librairie graphique... Il y aura toujours des dinos pour programmer en C tant que ca sera utile. Devoir gérer la mémoire soi même ca peut paraître lourd - ben ouais mais au moins c'est *efficace*.
Pourquoi pas Visual Basic tant que t'y es, tsss...
C++ roulaize d'abord.
-1
[^] # Re: au XXI ème siècle ?
Posté par Yann Hodique (site web personnel) . Évalué à 5.
Au risque de paraître complètement archaïque, il paraît qu'il y a même encore des gens qui programment en assembleur! T'y crois à ça toi? Des bouts de code en assembleur qui marchent?
Bon c'est sûrement des rumeurs tout ça...
-1 car vraiment trollesque
[^] # Re: au XXI ème siècle ?
Posté par Gnurou (site web personnel) . Évalué à 0.
De toute facon, le seul assembleur légal sera bientôt le code .Net, alors...
-1
[^] # Re: au XXI ème siècle ?
Posté par reno . Évalué à 3.
Pour résoudre ce probléme a mon avis il faudrait 2 choses:
- changer le modele de sécurité (pas seulement root et le reste): les modeles de sécurité "a jeton" cf Eros par exemple (non ce n'est pas cochon) permettent de diminiuer les risques..
- utiliser d'autre language que le C: Ada, Modula, Eiffel serait pas mal: compilé (donc relativement performant), avec un GC (évite les problèmes liés à la mauvaise gestion de la mémoire cf zlib par exemple).
D'apres ce que j'ai lu un programme avec GC utilise environ 2* la mémoire d'un programme ou la mémoire est gérée manuellement, ce qui est moins un problème maintenant que le prix de la mémoire a baissé.
[^] # Re: au XXI ème siècle ?
Posté par Edouard Gomez (site web personnel) . Évalué à 8.
</feed the troll>
--
Edouard Gomez
Java, je t'aime, Java je t'adore...
[^] # Re: au XXI ème siècle ?
Posté par Philippe F (site web personnel) . Évalué à 4.
Ca veut pas dire que tout ce que je fais prends necessairement des centaines de Go de memoire, juste que c'est une consideration qui passe apres l'efficacite.
[^] # Re: au XXI ème siècle ?
Posté par Pierre Tramo . Évalué à 3.
Personnellement, j'utilise autant du C que du Java, des shell scripts, etc... selon les circonstances.
[Le premier qui trolle sur les langages que j'ai cité prend la porte.]
[^] # Re: au XXI ème siècle ?
Posté par Vivi (site web personnel) . Évalué à 0.
ouais, trollons ...
Va faire un programme rapide dans un des langages que tu cites
c'est possible (cf. OCaml)
Il y aura toujours des dinos pour programmer en C tant que ca sera utile.
Bien sûr. Le problème c'est que c'est de plus en plus rarement utile mais certains ont apparemment du mal à s'en rendre compte.
Devoir gérer la mémoire soi même ca peut paraître lourd
ça l'est, on est d'accord.
mais au moins c'est *efficace*.
bof, les bugs aussi ils sont efficaces.
C++ roulaize d'abord.
beurk ...
[^] # Re: au XXI ème siècle ?
Posté par daniel . Évalué à 3.
alors pour un logiciel dont la rapidité est essentielle, d'accord mais pour le reste...
J'ajouterais même que la solution que j'aime beaucoup c'est le mixage de langages :
du C pour ce qui est long et du python pour le GUI par exemple. quelqu'un connaît une bonne référence sur la programmation multi-langages ?
PS : allez voir de ce côté , vous verrez de beaux lanagages de programmation ;o) http://www.tuxedo.org/~esr/retro/(...)
[^] # Re: au XXI ème siècle ?
Posté par Yann Droneaud (site web personnel) . Évalué à 5.
Les interpreteurs/runtime de ces langages sont
écrit en quoi ? ;)
[^] # Re: au XXI ème siècle ?
Posté par Dugland Bob . Évalué à 0.
et _c'est_ rapide, sauf si c'est un programmeur C qui écrit.
Il faudrait peut-être s'attaquer à la complexité avant de dire que c'est lent.
Il faudrait aussi éliminer les préjugés (cf. le modèle de mémoire minable de OpenCascade).
Je crois que l'image du hacker inculte, chevelu et borné n'est pas prête de disparaître.
Tous les benchs sérieux que j'ai vu plaident pour des langages de haut niveau (même ceux de gens qui avaient des intérêts économiques contraires).
[^] # Re: au XXI ème siècle ?
Posté par Cru Kilu . Évalué à 9.
- des programmeurs en assembleur, que c'est des hommes des cavernes qui parlent directement à l'électronique, c'est totalement néandertalien comme attitude ; mais on est bien content d'avoir des driver à chaque nouveau périphérique qui sort
- des programmeurs de script ; bien entendu, c'est hyper méga plus cool de faire du perl que du bash, mais je me souviens plus pourquoi ? Ah oui, la syntaxe est plus claire :)
- des programmeurs en C, des hommes, des vrais, qui n'hésitent pas à faire des malloc et des free, mais maintenant ça fait has been
- des programmeurs en C++, c'est la classe, ça roXor grave, top rock&roll ! bon ça compile pas partout mais c pas grave
- des programmeurs en java, c'est le fin du top, c'est hyper portable, sauf quand t'as pas le bon jdk. Plus besoin de faire des free, c'est géant, c'était la difficulté majeure dans la programmation !
Non sérieusement, pourquoi ce snobisme qui pousse à croire que seul les outils les plus récents doivent être utilisés ? Pourquoi un langage devrait-il en démoder un autre ? Pourquoi un concepteur d'application dénigrerait-il ceux qui ont conçu les couches inférieures de son appli ?
Inversement, pourquoi un programmeur en c ou en asm serait un vieux dinosaure et devrait abandonner ces langages ? Il est programmé en quoi le noyau de Linux ? hmmm ?
Amis lecteurs qui avez une vision partielle des langages de programmation, prenez garde, car vous allez être démodés dès l'apparition du prochain nouveau super langage de la mort.
Amis lecteurs qui considerez les nouveaux outils comme des pratiques suspectes, non élégantes et inflationnistes, prenez votre clavier et concevez-en de nouveaux !
[^] # Re: au XXI ème siècle ?
Posté par Yann Guidon (site web personnel) . Évalué à 1.
j'ai moins de problèmes avec, qu'avec le C.
C sapulpaté mais je suis obligé de passer par là :-(
et ton post n'a pas parlé de
LISP
SMALLTALK
EIFFEL
ADA
COBOL
PASCAL
FORTRAN
et tous ces langages qui ne servent que dans les livres...
franchement, moi maintenant je m'éclate au VHDL :-P
ça c'est un langage de mecs qui pensent et qui FONT de VRAIES choses.
non mais, moi aussi je peux troller ;-)
[^] # Re: au XXI ème siècle ?
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Au hasard : parce qu'en général ils ont tendance à mieux marcher que les anciens.
On code plus vite en C++ qu'en C, et encore plus vite en Java. A moins d'être forcé pour une raison quelconque d'utiliser C, quel est l'interet ?
C'est pas parce qu'une solution marche qu'on ne peut pas en trouver une meilleure.
[^] # Re: au XXI ème siècle ?
Posté par Cru Kilu . Évalué à 3.
On code plus vite dans le langage qu'on maîtrise le mieux, et il en va de même au niveau du débugage, et de la relecture.
Pourquoi alors faire du prosélitisme pour tel ou tel langage ? Je n'arrive pas à comprendre ce snobisme pour la progression des langages.
C'est pas parce qu'il y a une solution plus récente qu'elle doit éradiquer une solution bien connue.
Et je le répète, méfiez-vous des modes. Il y a 10 ans, celui qui ne faisait pas du Ada était naze ; il y a 5 ans, point de salut sans le c++, maintenant c'est du java à tous les étages ; et demain ?
Le C, ça fait 30 ans que ça existe, c'est une valeur sûre.
[^] # Re: au XXI ème siècle ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, c'est faux. C'est le genre d'argument bidon qu'on sort pour pouvoir refuser d'évoluer la conscience tranquille.
Je maitrise Java moins bien que C++ et pourtant je code plus vite en Java, simplement parce que le langage a un GC et une librarie bien plus complète que celle de C++.
Je n'arrive pas à comprendre ce snobisme pour la progression des langages.
Ça s'appelle le progrès. Chaque nouveau langage tire les leçons des précédents. C'est flagrant quand tu passe de C++ à Java, et de Java à C#.
C'est pas parce qu'il y a une solution plus récente qu'elle doit éradiquer une solution bien connue.
Si, c'est pour ça qu'on crée de nouvelles solutions.
Le C, ça fait 30 ans que ça existe, c'est une valeur sûre.
Le cheval existe depuis des millénaires, c'est une valeur sûre. L'automobile n'est qu'une mode.
[^] # Re: au XXI ème siècle ?
Posté par Dugland Bob . Évalué à 1.
Du style : "Le C, ça fait 30 ans que ça existe, c'est une valeur sûre"
le LISP a été inventé en 1958, Smalltalk en 1972, scheme pareil, ça fait 44 ans que ça existe mais ça doit être à un mec de 15 à qui tu répond.
d'autre part, y'a un bon bench :
http://www.bagley.org/~doug/shootout/(...)
(faites gaffe, les listes n'en sont pas, sinon les fonctionnels exploseraient les autres)
Mais tout ça c'est de la merde parce que c'est pas C !
D'autre part, ici personne ne développe d'application 'généraliste", on n'a que des développeurs de drivers, de temps-réel (mal informés) et de noyaux.
[^] # Re: au XXI ème siècle ?
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Je sais, mais c'est assez relaxant aussi... :-)
D'autre part, ici personne ne développe d'application 'généraliste"
Euh si, moi je développe un éditeur/séquenceur MIDI :
http://rosegarden.sf.net(...)
[^] # Efficacité des compilateurs
Posté par bobert . Évalué à 3.
mettre au point un compilateur efficace pour un
langage donné; Le simple fait que le
gcc, compilateur C sous le frontend GCC, soit encore amélioré malgré
son grand age prouve que ce n'est pas chose facile
et justifie a lui seul le choix d'un langage comme
le C.
Maintenant, est-ce que vous savez s'il existe une estimation
quantitative du degré d'optimisation
du code genere par les compilateurs de la distribution GCC ?
C'est une question tres vague, et qui depend enormement de
la plate-forme pour laquelle on compile, mais supposons
qu'on veuille ecrire un programme toto qui execute
une serie de taches t. Supposons en plus qu'on soit pote avec le
meilleur programmeur en assembleur sur i386, et que celui-ci
nous ait donne le listing du meilleur code assembleur possible ass
qui execute t.
On peut ecrire un programme qui execute t dans n'importe
quel langage. A priori, si je choisis d'ecrire mon programme en c,
je peux esperer que le code genere par gcc se rapprochera
tres pres de ass. Mais si je choisis par exemple objective-c,
y a-t-il un moyen de savoir en quoi le code genere par le compilateur objective-c de gnu
differera de ass ? Idem pour g++, gcj, etc...
Pour resumer, aussi vague la question soit-elle, est-ce qu'on peut avoir
une idee de l'efficacite relative du code genere par les compilateurs
de la distribution GCC ?
A+
Bob
--
desole, j'ai fini par lacher les accents, mais j'ai un clavier qwerty et les eacute and co ca me les brise menu...
[^] # Re: au XXI ème siècle ?
Posté par Brundle Mouche . Évalué à 2.
Bon c'est super tous les langages que tu cite, mais pour de l'embarque ou des drivers par exemple c'est pas bien terrible.
Certes gerer une application sous environnement graphique en C ou C++, en etant oblige de passer par un Visual %^#^*^&@ c'est mauvais et peu elegant (en general). Mais pour de l'embarque, ou le CPU ne fonctionne bien souvent pas au-dela de 500 Mhz (consommation, chaleur, densitee...), et ou la memoire est une ressource rare rien ne vaut un bon vieux C++.
Pour les drivers rien de tel que du C (c'est prevu pour: adresage direct ,de la memoire, codage en quasi-asm...).
Faut pas tout melanger. Le langage unniversel n'existe pas et n'existera jamais. C'est un concept pour les feignants intellectuels et les etroits d'esprits (et boum re-troll).
[^] # Re: au XXI ème siècle ?
Posté par Dugland Bob . Évalué à -2.
C'est un site de développeur du noyau ?
La plupart du temps c'est la flemme d'apprendre un langage qui conduit à utiliser le C.
Quand tu vois le ramassi de conneries au dessus (ça prends plus de mémoire, c'est plus lent, on utilise le C pour écrire les compilos [et alors ?], la meilleure : je développe des drivers ou le noyau [à temps plein ?]).
Surtout que la plupart des langages permettent une interconnexion avec le C pour les fonctions critiques.
C'est dommage de discréditer ainsi un site pas mal par ailleur.
[^] # Re: au XXI ème siècle ?
Posté par Brundle Mouche . Évalué à 1.
-1 HS
[^] # Re: au XXI ème siècle ?
Posté par Cru Kilu . Évalué à 2.
A propos de java, je suis toujours subjugué par les programmeurs qui se battent pour ne pas lancer trop de machines virtuelles en même temps (mais c'est pas parce que ça consomme trop de mémoire, bien sûûûûûûûr), ou par la beauté intrinsèque d'un appel système en plein milieu d'un prog java (hopefully noone will notice :)
En quoi comparer des performances de langages jette-t'il le discrédit sur DLFP ? Il me semble que c'est le bon endroit, non ? En plus il y a des informaticiens de tout age, de tout expérience, des gens qui savent de quoi ils parlent, parfois des gens objectifs :)
Il y a même des gens qui se passent très bien des derniers langages !
[^] # Re: au XXI ème siècle ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Je serais curieux de savoir quelle expérience tu as toi pour affirmer une annerie pareille.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.