Après avoir vainement cherché un « printf debugging considered harmful » j'en suis arrivé à la conclusion qu'il n'existait pas et j'ai donc décidé de l'écrire moi même.
J'appelle « printf debugging » le fait d'ajouter du code temporaire dans le seul but de débugger du code existant. En C, le code ajouté étant généralement un appel à printf(3) permettant par exemple de retrouver quelle partie du code a été exécutée avant le segfault dont on cherche la cause. Cette technique est particulièrement populaire chez les programmeurs débutants qui n'ont pas envie d'apprendre à se servir d'un debugger « parce qu'ils s'en passent très bien » (moi aussi j'ai dit ça à une époque). Dans ce document je tente de montrer que le printf debugging pose un certains nombre de problèmes que n'ont pas d'autres méthodes.
$ while true; do vi && make && ./plop ; done
Le premier problème le plus évident qu'on rencontre quand on pratique le printf debugging est qu'il est nécessaire de recompiler et réexécuter le code concerné plusieurs fois. En effet, on trouve rarement le bug en rajoutant un seul printf, d'où plusieurs cycles d'édition, compilation, exécution qui font perdre un temps considérable.
Le deuxième problème qui apparaît lorsque l'on a ajouté des printf un peu partout est de les retrouver tous pour les enlever une fois le bug corrigé. Ca semble trivial mais ça prend aussi du temps et il n'est pas rare d'en oublier l'un ou l'autre caché au fin fond d'une branche d'exécution qui sera prise trop rarement pour être remarqué rapidement.
Une alternative permettant d'éviter ce problème est d'utiliser un système de logging permanent (dés)activable plus ou moins dynamiquement (via une variable d'environnement, un argument ou une option de compilation par exemple) associé à un système d'assertions. De plus ça incite à écrire des messages compréhensible plutôt qu'un « toto » qui n'aura plus de signification pour personne une fois la session de debugging finie. Il existe de nombreux systèmes de logging plus ou moins complexes mais pour commencer autant s'en tenir à un simple macro qui affiche ou non son argument selon que l'on veuille afficher les logs ou non [1].
« C'est Heinsenberg qui est sur l'autoroute... » [2]
Un autre problème plus rare mais bien plus pervers est que l'ajout de code peut modifier ou masquer le bug. C'est ce qu'on appelle un heinsenbug : il devient inobservable quand on essaie d'en déterminer la nature mais réapparaît aussitôt le printf retiré. Ce genre de bug à tendance à se retrouver dans les programmes concurrents mais peut aussi être causé par de subtiles problèmes dans la gestion de la mémoire et sans doute d'autres choses. L'utilisation d'un debugger classique permet de retrouver un certains nombre de ces heinsenbugs mais pas tous.
D'autres problèmes qui peuvent sembler plus triviaux sont liés au printf debugging. Il est par exemple impossible de debugger printf lui même avec cette méthode et les systèmes de cache la rendent souvent inutile si on n'en tient pas compte.
En conclusion, le printf debugging peut être utile dans certains cas mais on rencontre vite ses limites qui peuvent être dépassées avec un usage judicieux d'un système de logging, d'assertions et d'un debugger.
À lire aussi : « Debugging 101 » [3]. Cet article déconseille l'utilisation générale de debuggers « classiques » en faveur du prinf debugging mais je persiste à penser que l'utilisation d'un système de logging et d'un debuggers plus évolués [4] reste souvent préférable. Et je suis tout à fait d'accord avec l'utilisation du « design by contract » tel qu'expliqué (ainsi qu'avec la plupart du reste de l'article).
[1] Personnellement en C99 pour des petits projets j'utilise ceci :
Quand on développe, on compile normalement et quand on passe en « production », on définit le macro NDEBUG qui éliminera aussi les assert(3). Le macro debug() s'utilise de la même manière que printf(3) mais on le laissera dans le code final.#ifndef NDEBUG
# define debug(...) fprintf(stderr, __VA_ARGS__)
#else
# define debug(...)
#endif
[2] Heinsenberg est sur l'autoroute au volant de sa voiture quand il se fait interpeller par un agent de police.
« Vous savez à quelle vitesse vous rouliez ? »
« Non, mais je sais où je suis »
Si vous n'avez pas compris, vous devriez chercher de la documentation sur le principe d'incertitude d'Heisenberg. Je déconseille cette blague dans les soirées comportant moins de 50% de physiciens/chimistes/ingénieurs.
[3] http://www.hacknot.info/hacknot/action/showEntry?eid=85
[4] L'« Omniscient Debugger » par exemple permet de retourner en arrière dans l'exécution du code.
http://www.lambdacs.com/debugger/debugger.html
http://video.google.com/videoplay?docid=3897010229726822034
# exceptions
Posté par Vincent BRZUSCZAK . Évalué à 2.
C'est pratique, mais un débutant ne s'intéresse pas toujours au sujet.
[^] # Re: exceptions
Posté par Troy McClure (site web personnel) . Évalué à 2.
D'ailleurs l'auteur du journal a oublié de parler du debugger qu'il utilise. gdb en ligne de commande sous HPUX ou le debugger de visual studio sous windows vista ?
[^] # Re: exceptions
Posté par Krunch (site web personnel) . Évalué à 5.
Concernant les exceptions, je recommande les lectures suivantes :
http://www.joelonsoftware.com/items/2003/10/13.html
http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.(...)
http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.(...)
http://blogs.msdn.com/oldnewthing/archive/2005/03/17/397468.(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: exceptions
Posté par Vincent BRZUSCZAK . Évalué à 1.
[^] # Re: exceptions
Posté par Krunch (site web personnel) . Évalué à 4.
Au passage, si on veut vraiment, en C aussi on peut avoir des exceptions : http://www.freetype.org/david/reliable-c.html
Et plein d'autres trucs d'ailleurs : http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html http://developer.gnome.org/doc/API/2.0/gobject/index.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# re
Posté par Sylvain (site web personnel) . Évalué à 2.
[^] # Re: re
Posté par Sylvain (site web personnel) . Évalué à 3.
Ce principe, énoncé en 1927 par le physicien allemand Karl Werner Heisenberg, nous indique les limites sur la précision de mesure que l’on puisse obtenir sur l’information d’un système donné.
Le monde quantique échappe à toutes nos tentatives de le délimiter dans une zone précise de l’espace : lorsqu’on essaie de mesurer la position d’une particule avec une grande précision, l’information sur sa vitesse est incertaine.
Et inversement, lorsqu’on veut connaître sa vitesse avec une précision accrue, sa position devient floue... Il y a une limite infranchissable à la connaissance que l’on puisse obtenir sur l’information d’un système; cette limite est connue sous le nom du principe d’incertitude.
Mais attention : cette imprécision n’est pas due à l’imperfection des appareils de mesure, c’est une réalité intrinsèque du monde atomique. Bien évidemment dans notre monde ce principe d’incertitude ne s’applique pas. On peut par exemple connaître à la fois et avec une grande précision la vitesse et la position d’une voiture.
-----------------------------
Donc ca serait la complexité de determiner la vitesse ET la position ?
[^] # Re: re
Posté par Wawet76 . Évalué à 2.
[^] # Re: re
Posté par fabien . Évalué à 4.
le fait d'observer un objet (de l'echelle de l'atome) influe sur lui-même,
en moin light : c-a-d que le produits des incertitudes (des mesures) est de l'ordre de la constante de planck.
[^] # Re: re
Posté par account . Évalué à 6.
[^] # Re: re
Posté par _Mekare_ . Évalué à 2.
Imagine que tu veux déterminer la position et la vitesse d'un atome. De la même façon tu vas l'"éclairer". Sauf que ton photon est aussi une particule (enfin y a la dualité mais bon simplifions). Donc que va faire ton photon en ricochant sur ton atome ? Et bien il va le dévier et donc modifier sa vitesse. Ainsi tu sauras où il est mais tu ne pourras plus déterminer sa vitesse (en tout cas plus celle qu'il avait avant ta mesure).
Mekare
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: re
Posté par Jerome Herman . Évalué à 1.
Mouais, faut le dire vite.
Le photon qui "ricoche" c'ets quand même une approximation plus que grossiére. Un photon ca va tout droit. Eventuellement c'est absorbé puis un autre photon est réémis dans une autre direction mais c'est pas vraiment le même photon.
[^] # Re: re
Posté par Sebastien . Évalué à 1.
Ceci est egalement une approximation grossiere :). Un photon ne va pas tout droit. Il suit les geodesiques de l'espace temps (c'est beau... mais surement inexact, ma relat' G est "un peu" rouillee).
Du coup, un "rayon lumineux" est devie aux environs d'un champ de matiere intense (genre une galaxie, un trou noir,...) qui modifie la courbure de l'espace-temps.
C'est ce qui est appele "lentilles gravitationnelles" ou "anneaux d'Einstein".
Une rapide recherche donne:
http://www.techno-science.net/?onglet=news&news=2035
http://commons.wikimedia.org/wiki/Image:Einstein_rings_zoom.(...)
http://www.futura-sciences.com/news-hubble-observe-lentilles(...)
[^] # Re: re
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: re
Posté par Sebastien . Évalué à 1.
[^] # Re: re
Posté par Jerome Herman . Évalué à 2.
De toute façon vu qu'il n'existe qu'en deux dimension il aurait du mal à tourner.
Après çà si un observateur a l'impression que le photon tourne c'est que l'espace est courbe (pour le temps le photon s'en fout, ca ne fait pas partie des deux dimension qu'il connait).
A noter qu'apparament ca marche aussi à proximité des neutrinos, ce qui évite d'avoir un déranger une galaxie pour rien.
[^] # Re: re
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Ou alors les deux dimensions dont tu parles, est la première une dimensions spatial (un ligne) et l'autre le temps. Sinon je vois pas comment il peut y avoir un déplacement. Non?
[^] # Re: re
Posté par Jerome Herman . Évalué à 3.
Le photon est un phénomène purement spatial, le temps ne s'écoule pas pour le photon. Le fait que le photon se "déplace" est lié à l'observateur.
En fait plus on se déplace vite, moins le temps s'écoule par rapport à un observateur fixe. C'est le principe de la théorie de la relativité.
Le photon ne connait que sa direction, son sens et son amplitude (sa longeur d'onde).
[^] # Re: re
Posté par psychoslave__ (site web personnel) . Évalué à 2.
# Comment profiter pleinement des possibilités de vim.
Posté par apom . Évalué à 0.
Fais-tu vraiment ça ?
[^] # Re: Comment profiter pleinement des possibilités de vim.
Posté par Krunch (site web personnel) . Évalué à 9.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: glib, je t'aime
Posté par Krunch (site web personnel) . Évalué à 6.
http://www.gnu.org/software/libc/manual/html_node/Backtraces(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: glib, je t'aime
Posté par galactikboulay . Évalué à 1.
# Claimed truth considered harmful
Posté par calandoa . Évalué à 10.
Je dirais plutôt que le fait que ce texte n'existe pas est une observation. Une conclusion serait par exemple que tu es le seul bon programmeur sur le net. Une autre serait qu'utiliser des printfs pour debuger un programme est considéré comme tout à fait correct par la majorité des programmeurs.
J'appuierai d'ailleurs cette deuxième conclusion en ajoutant que, même si tes remarques sont pertinantes, utiliser un debugger apporte aussi son lot d'inconvénients et n'est pas forcement un meilleur choix.
D'ailleurs, pour trouver un bug, même les solutions les pires sont acceptables si les meilleures n'ont rien donné...
[^] # Re: Claimed truth considered harmful
Posté par Krunch (site web personnel) . Évalué à 0.
C'est bien comme ça que je l'entend. Il n'y a pas de solution miracle. Mon journal tente de montrer au programmeur débutant qui ne connait que le printf debugging les limites de cette méthode.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Claimed truth considered harmful
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Claimed truth considered harmful
Posté par Jerome Herman . Évalué à 4.
D'un autre coté il a pas trop le choix. GDB en kernelspace ca le fait pas trop...
[^] # Re: Claimed truth considered harmful
Posté par woopla . Évalué à 1.
# J'ai eu ma période ...
Posté par Anonyme . Évalué à 10.
# define debug(...) fprintf(stderr,"%s : %s, line %i : ",\ __FILE__, __FUNCTION__, __LINE__);\ fprintf(stderr, __VA_ARGS__)Bon après tu peux y aller encore plus comme un bourrin et afficher direcetement ton code (bien plus rapide que de saisir un rapide descriptif donné a ta macro, le dévellopeur moyen se souvient de ce qu'il a écrit).# define debug(CODE, ...) fprintf(stderr,"%s::%s, line %i : ",\ __FILE__, __FUNCTION__, __LINE__);\ fprintf(stderr, "\"%s\" - ", #CODE);\ fprintf(stderr, __VA_ARGS__);\ CODEExemple : debug(appelFonction(param), "param : %s", param); te donnera comme sortie a l'exécution : après tu peux faire des truc sympa comme du avant/après :# define debug(CODE, ...) fprintf(stderr,"%s::%s, line %i : ",\ __FILE__, __FUNCTION__, __LINE__);\ fprintf (stderr, "\nbefore : ");\ fprintf(stderr, __VA_ARGS__);\ CODE;\ fprintf (stderr, "\nafter : ");\ fprintf(stderr, __VA_ARGS__)et bien sûr tu peux toujours faire:#if defined (DEBUG) # define debug(CODE, ...) fprintf(stderr,"%s::%s, line %i : ",\ __FILE__, __FUNCTION__, __LINE__);\ fprintf (stderr, "\nbefore : ");\ fprintf(stderr, __VA_ARGS__);\ CODE;\ fprintf (stderr, "\nafter : ");\ fprintf(stderr, __VA_ARGS__) #else # define debug(CODE, ...) CODE #endifBon après y'a moyen de se faire haïr par tout les relecteurs, donc bien penser a tout nettoyer :)# ouais
Posté par Anonyme . Évalué à 9.
Programmeurs débutants du genre Linus Torvalds :)
http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.h(...)
[^] # Re: ouais
Posté par Gregplus . Évalué à 4.
Il dit en gros que lorque l'on utilise un debugger, on a tendance à fixer les bugs un peu vite sans forcément tout bien voir comme il faut.
En tout cas moi j'ai toujours été étonné du nombre de développeurs qui ne savent pas utiliser un debugger ou n'en voient pas l'intéret, je dirais que ça représente au moins 80% des gens avec qui j'ai bossé.
[^] # Re: ouais
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ouais
Posté par peau chat . Évalué à 5.
Ben faut dire que quand tu cherches un bug dans une application multithreadée avec tâches concurrentes, des communications entre objets par signaux/slots et des communications interprocessus genre avec un DCOP serveur ou un kioslave, le débugger ça fait plus perdre de temps qu'autre chose.
Et si ton bug est un race condition, l'utilisation d'un debugger peut aussi induire des Heisenbugs...
[^] # Re: ouais
Posté par Gabriel Linder . Évalué à 4.
Si vous en connaissez d'autres, je suis preneur :)
[^] # Re: ouais
Posté par lasher . Évalué à 4.
Sauf qu'en fait, dès que tu passes à du multi-process/multi-thread, l'utilisation de printf sur la sortie standard est plutôt déconseillée, vu que tu ne maîtrises pas l'ordre d'affichage des messages et que tu peux même en avoir certains qui passent à la trape.
[^] # Re: ouais
Posté par lolop (site web personnel) . Évalué à 3.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: ouais
Posté par Laurent A. . Évalué à 1.
Ça paraît difficile à première vue, et ça l'ait, néanmoins je suis tombé récemment sur ce cas parce que le programme attrapait des signaux et déroutait l'exécution du thread receveur. Le thread receveur avait fait un lock() juste avant d'être dérouté, ce qui provoquait donc un blocage lorsqu'un autre thread voulait enregistrer quelque chose dans le log...
La solution consistait à bloquer les signaux pour tous les threads, sauf un.
[^] # Re: ouais
Posté par Jerome Herman . Évalué à 6.
Les rares fois ou j'ai debugé du multithreadé avec des printf sur la sortie standard, j'étais bien content de ne pas maitriser l'ordre d'affichage. En fait c'était même un peut le but. C'est là qu'on arrivait à de jolis use-case avec un affichage qui permettait de savori quel thread avait fait quoi avant/après tel autre thread.
Le gros défaut de la sortie standard c'est qu'ecrire dessus c'est non atomique, il peut donc se passer des choses entre le début et la fin de l'écriture (interrupt, segfault d'un autre thread qui plie le process etc.)
Gros problème pour faire du debug avec exclusivement des commandes atomiques il faut se lever de bonne heure (que ce soit avec printf, GDB ou des buffers extérieurs).
On peut tricher avec un process extérieur et des IPC mais généralement on obtient des résultats assez variables.
L'idéal c'est un simulateur qu'on peut mettre en pause, retour arrière, avance rapide quand on veut. Mais là il vaut mieux avoir de la ram et de la puissance CPU à disposition, parceque ca risque de ramer (surtout si vous avez des dizaines et des dizaines de threads).
Pour finir il est important de bien se rendre compte d'un chose : il ets impossible d'écrire un debuggueur parfait. Etre capable d'écrire un programme qui va trouver toutes les failles dans n'importe quel code est équivalent à écrire un programme capable de detecter si n'importe quel code va se terminer. Pour debugguer rien en remplace donc le cerveau. Certaines méthodes vont marcher, d'autres pas du tout mais il est assez difficile de savoir à priori lesquelles.
[^] # Re: ouais
Posté par Thomas Douillard . Évalué à 3.
C'est bien pire que ça, un debugger parfait devrait "deviner" ce que tu veux faire pour savoir si tu le fais correctement ;)
Les "prouveurs" automatique se basent sur une spécification formelle pour vérifier la correction du code.
Sinon, une autre solution pour éviter certaines failles est d'utiliser des langages qui en réduisent le nombre, en garantissant certaines choses (l'utilisation obligatoire d'utiliser des iterateurs sur un tableau pour éviter les dépacements de capacité pour éviter les débordements, ce genre de chose). D'utiliser des langages qui peuvent garantir certaines propriétés en somme. Inutile de chercher des erreurs que le langage ne permet pas de faire, surtout si trouver la totalité de ce genre d'erreurs est indécidable ^^
A nuancer cependant, c'est pas parce que c'est pas décidable dans le cas général qu'on construit systématiquement des programmes pour lesquels il est impossible de décider : les preuves d'indécidabilités sont souvent construites sur des cas extrêmes spécialement tordus et construits pour.
[^] # Re: ouais
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Le déboggueur, il ne trouve pas les bugs à ta place, il te donne une execution instrumentée et/ou pas à pas de ton programme. C'est de la pure technique, rien à voir avec les problèmes de décidabilité théoriques.
[^] # Re: ouais
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: ouais
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: ouais
Posté par Krunch (site web personnel) . Évalué à 2.
http://www.st.cs.uni-sb.de/dd/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ouais
Posté par Krunch (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ouais
Posté par patrick_g (site web personnel) . Évalué à 10.
Ce post de Linus est vraiment d'anthologie ! On sent bien le mec de caractère. J'ose même pas imaginer ce qui adviendrait si il était enfermé dans un cagibi avec Theo de Raadt....
# valgrind
Posté par gc (site web personnel) . Évalué à 10.
Après, inutile d'en faire une tartine ou de chercher d'autres raisons.
[^] # Re: valgrind
Posté par Gabriel Linder . Évalué à 3.
# "Considered Harmful" Essays Considered Harmful
Posté par Erwan . Évalué à 10.
# Au final...
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
Note au passage a propos des printf et du debugging: Ryan C. Gordon, porteur sous GNU/Linux d'une tonne de trucs (des jeux, mais pas seulement: vous lui devez google earth), ex de chez feu Lokigames, a indiqué dans un podcast récent comment il s'y prend pour porter un truc, généralement. Ce n'est bien sur qu'un début et ce sont des instructions basiques, mais j'ai trouvé ca pas mal: Il essaye de compiler le truc avec un makefile générique. A chaque endroit ou ca merde, il met un printf("FIXME"); a la place du code et continue jusqu'a ce que ca compile... Ensuite il corrige le code :-)
[^] # Re: Au final...
Posté par fouyaya . Évalué à 3.
Les études sont loin maintenant, mais j'ai le souvenir que le debug à coup de printf cémal si tu n'tilises pas le fflush() à outrance. De mémoire (je dis peut être une bétise) printf() met en mémoire ce que tu lui demande d'écrire, puis de temps à autre (pas "immédiatement") cette mémoire est _flushée_ ver la sortie (fd : standard, fichier, tty...).
Du coup, mieux vaut écire une macro PRINTF faisant appel à write() pour faire du debug. Tant qu'on y est, on peut ajouter à notre macro un argument qui affichera notre debug en fonction d'une variable DEBUG...
P.S. moi j'aimais bien le debug à coup de PRINTF, ca permettait de commenter le code tout en générant des logs compréhensibles pour les autres développeurs. Le gdb, c'est bien, mais il est parfois difficile de comprendre pourquoi un tel à écrit son code d'une manière bien précise...
[^] # Re: Au final...
Posté par galactikboulay . Évalué à 5.
[^] # Re: Au final...
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Si la sortie de printf est un fichier, le flush n'est pas automatique.
[^] # Re: Au final...
Posté par lasher . Évalué à 2.
Non non, il a raison, c'est le '\n' qui fait que le vidage du tampon est effectué pour printf().
[^] # Re: Au final...
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
[^] # Re: Au final...
Posté par Krunch (site web personnel) . Évalué à 1.
Relis ma définition :Ce que tu fais j'appelle ça du logging.
Par ailleurs, pour répondre à galactikboulay, le fait que printf(3) flush à chaque "\n" n'est sans doute pas très standard.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Au final...
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Tool
Posté par Pooly (site web personnel) . Évalué à 8.
# Mouaif...
Posté par lolop (site web personnel) . Évalué à 5.
Avec bien sûr de la compilation conditionnelle (non seulement globale avec _DEBUG et NDEBUG, mais aussi du DEBUG_MODULE au début des sources C, que je peux commenter/décommenter afin de désactiver/activer les lignes de déboguage d'un module).
L'argument du temps de compilation me semble, en 2006, avec les machines et les compilateurs que l'on a, un peu léger. Ca eu été vrai [**], ça l'est encore pour de très gros projets (OS, KDE & Co), mais faudrais pas exagérer.
Par contre, ça peut en effet avoir un gros inconvénient comme tu l'indiques: ça ajoute du temps d'exécution qui peut faire disparaître des bugs (typiquement quand on fait du pilotage d'instruments).
D'un autre côté, si en qq printf on n'a pas trouvé, en effet, passer au débugger, utiliser des points d'arrêt, de l'affichage du contenu de variables... tu as raison de vouloir montrer l'existence de ces outils, mais de là à considérer que le débogage via des traces est nocif, non.
[*] Des fonctions varargs qui ajoutent quelques infos, et qui soit renvoient vers un système de log, soit font du printf.
[**] Il y a une douzaine d'années j'avais un projet qui mettait une heure et quart à compiler, sur un 486DX33 sous Windows... on évitait autant que possible les "Rebuild All", mais la gestion des compilations sous l'environnement VC++ était suffisament foireuse pour qu'on soit régulièrement obligé de le faire. Quand le Pentium est arrivé, on est tombé à 1/4 d'heure de compil - le bonheur.
Et un peu auparavant, j'avais eu la joie de travailler en assembleur sur un Solar au CEA... compilation de plusieurs heures avec sortie du résultat sur une imprimante - là on dépouille vraiment le résultat.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Mouaif...
Posté par Krunch (site web personnel) . Évalué à 1.
Pour le debug de code concurrent, c'est toujours bien chiant mais les printf ont tendance à heisenbugger assez bien aussi dans ce cas. J'ai plutôt l'impression que la solution est d'utiliser un debugger système du genre de dtrace (qui fait plus du logging que du debugging proprement dit d'ailleurs).
Le problème c'est que bien souvent on printf debug rien que pour savoir si on est arrivé à un endroit dans le code alors qu'on peut aussi bien le faire plus rapidement avec un debugger sans avoir à modifier le code. S'il est vraiment intéressant de savoir régulièrement si un est passé par un endroit donné, alors autant laisser un debug() en permanence.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Mouaif...
Posté par CrEv (site web personnel) . Évalué à 1.
C'est pour ça que c'est pratique de pouvoir faire de la compilation incrémentielle et donc de modifier le code en debug :
- j'utilise le debugeur pour trouver mon probleme
- je corrige sans arrêter l'exécution
- je compile incrémentalement et je continue a exécuter pour verifier ma correction
Evidemment ça ne marche pas avec tout mais c'est très pratique pour ne pas avoir à recompiler / relancer le prog (surtout quand il y a des connexion non automatiques à des bdd par ex, authentifications, ouverture de fichiers, ... tout ce qui demande de refaire les même opérations qui servent à rien et qui font perdre du temps)
# Of GDB considered Harmful
Posté par Jerome Herman . Évalué à 10.
Restons clair, si GDB est un excellent outil pour former les programmeurs débutants à la notion de pointeur et de libération de mémoire, il ne devrait jamais être utilisé pour quoi que ce soit d'autre. Donc passé deux ans à faire du C de façon intensive jetez le aux oubliettes et utilisez des appels intracode pour vous informer des problèmes rencontrés (printf est une bonne solution dans 90% des cas)
Les inconvennients majeurs de GDB :
- Un programme C/C++ compilé en mode "debug" ne se comporte pas (parfois pas du tout) comme le même programme compilé en mode standard. les différences principales sont :
* différence dans le link des bibliothèques. Le simple fait d'activer GDB dans un programme qui lie une bibliothèque compilée sans les options de debug peut faire apparaitre/disparaitre pas mal de bugs.
* différence dans la signature des pointeurs de fonctions. Si vous avez le moindre paramêtre système dans votre fonction, il y a 9 chances sur 10 pour que sa signature change après un passage de GDB. Cela peut également faire apparaitre/disparaitre un paquet de bugs. (des segfault souvent)
* remontée de tout un tas d'appels systèmes pour suivre le déroulement du programme qui n'existent pas dans les versions compilées en standard.
- Dans la plupart des programmes, GDB ne peut pas grand chose pour vous :
* Oubliez le mot clef "volatile" à moins de s'en servir exclusivement pour GDB. (Bon vous allez me dire que de toute façon vous ne connaissiez pas le keyword volatile)
* Oubliez les interruptions systèmes, notamment alarm, gettime et sleep. Certains messages passent, d'autres sont trappés par GDB directemetn sans jamais atteindre votre programme.
* GDB est totalement inutile en cas de programmation concurrente/parallèle. Il ne comprend rien au fichiers mappés en mémoire par un autre process et a du mal avec les messages IPC/ITC (com entre processes, com entre threads) un peu complexe.
* Si pour une raison quelconque, la mémoire allouée par un process est désallouée par un autre, c'est festival.
* Pour les raisons évoquée plus haut n'essayez même pas d'utiliser GDB en dehors du userland, vous allez vous faire mal à le kernel.
- GDB vous empêche de comprendre ce qui se passe vraiment.
* GDB ne comprend pas le code, il le trace. Si vous avez fait une erreur conceptuelle quelque part, GDB vous maintiendra dans l'illusion quand allouant un octet mémoire de plus ou en castant un peu plus violamment une variable ca marche.
* GDB ne comprend pas ce que vous cherchez à faire. A moins de truffer le code de volatile dédiés, GDB va vous aider à debugger les différents cas de figures un par un. A moins d'être très propre, très rigoureux et pas pressé par le temps, votre code (si il est imposant) ressemblera rapidement un un patchwork de verrues et de pansements. On reconnait le code des afficionados de GDB aux nombres de tests qu'il y a dans le code.
* GDB check, trace et valide le code. Il est totalement insensible au système et à l'environnement de la machine. Si votre programme plante suite à un appel système, GDB vous permettra de trouver ou dans le code il faut contourner l'appel système. Mais il ne sera d'aucune utilité sur le pourquoi, le comment et la méthode à adopter pour traiter/ignorer l'appel système.
En bref GDB c'est bien pour les petites applis monotache, mono-utilisateur, monoprocess qui n'ont pas besoin des fonctions systèmes ou d'appels complexes à des bibliothèques extérieures.
Pour le reste, utilisez votre cerveau.
[^] # Re: Of GDB considered Harmful
Posté par kadreg . Évalué à 1.
Il y a un autre debugger que gdb sous linux d'ailleurs ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Utilisation d'un débugger
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Quelqu'un aurait-il la gentillesse de mettre ici comment utiliser gdb et valgrind (enfin la sortie).
Parce que je connais :
gdb ./a.out_qui_segfault
(gdb) run
<stdout+stderr>
(gdb) bt
(gdb)
Mais pour le reste (afficher les variables, etc) j'ai jamais trouvé un tutoriel bien fait.
Et pour les fanas du RTFM, merci de vous le remballer, je vous demande pas une doc de merde comme j'en ai trouvé a la pelle inutilisable, mais une du niveau de http://fr.php.net/nom_fonction qui explique BIEN les choses et des exemples d'utilisation !
En fait c'est que j'aide au debugging de mandriva et que ça me soûle de pas pouvoir régler les problèmes moi-même faute d'arriver a retrouver le contexte de l'erreur (valeurs de variables, appel de fonction, etc...).
Merci d'avance.
[^] # Re: Utilisation d'un débugger
Posté par Nicolas Schoonbroodt . Évalué à 1.
Sur google en français, cherche :
gdb howto
gdb tutorial
[^] # Re: Utilisation d'un débugger
Posté par Colin Leroy (site web personnel) . Évalué à 4.
break function arrêtent l'exécution
delete X enlève le breakpoint X
cond X expr_booleenne n'arrête l'exécution du breakpoint X seulement si expr_booleenne est vérifiée
step continue un step
cont resume l'exécution
bt affiche la backtrace
frame N saute au point N de la backtrace
l affiche le code autour
print variable affiche la valeur de la variable (adresse en cas de pointeur)
print *variable affiche la "valeur du contenu du pointeur"
print struc->stuff affiche le champ stuff de la structure struc
set struc->stuff=0 affecte 0 à struc->stuff
handle SIGBLAH {stop,nostop,print,noprint,pass,nopass} permet de contrôler ce que GDB fait des signaux
et encore plein de trucs que je ne connais pas...
[^] # Re: Utilisation d'un débugger
Posté par Larry Cow . Évalué à 2.
Genre 'p' au lieu de 'print', 'c' au lieu de 'cont', etc...
[^] # Re: Utilisation d'un débugger
Posté par Mildred (site web personnel) . Évalué à 3.
Après, il faut un grand écran.
ddd affiche en plus une console gdb ... tu dois pouvoir apprendre les commandes comme ça.
http://www.kdbg.org/
http://www.gnu.org/software/ddd/
# printf, pour débutant ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
1) gdb : j'ai pas vu de debugger aussi inutilisable que gdb, aussi lourd, et aussi lent. Surtout sur des gros programmes (même si c'est sur une toute petite partie que tu veux debogger).
Et je ne parle pas de toutes ces commandes qu'il faut apprendre, des front-ends limités ou non ergonomique, et qui par nature, souffrent des mêmes défauts de gdb lui même..
Si il y a bien quelque chose à féliciter à MS, c'est le deboggeur de Visual Studio. Tout est quasi instantannée, interface nickelle. Vivement le jour où on pourra virer gdb sous linux et avoir un déboggeur aussi efficace que celui de VS.
2)
Mauvais éditeur, changer éditeur. Et changer pour un éditeur qui contient une véritable fonction de recherche multi fichier.
3) Gdb est inutilisable dans un programme qui travaille sur un volume de donnée conséquent. Exemple : j'ai réalisé un validateur xml, basé sur relaxng. J'avais des bugs lors du parsing du schema de docbook, qui contient des milliers de patterns. Trés franchement, il est inutile de tenter d'utiliser le deboggeur : pas envie de repasser 3500 fois dans la même méthode pour arriver jusqu'au 3500ieme pattern qui provoque le bug.
La seule solution : le printf pour se générer un log. C'est ce que je fais sur des traitements "moyens".
Sinon j'utilise comme tu dis "un système de logging permanent (dés)activable plus ou moins dynamiquement ". En particulier dans mes devs Mozilla. Mozilla possède un système de log trés sympa (PrLog), que tu peux activer ou désactiver via une variable d'environnement (avec plusieurs niveaux d'activation). (et n'est pas compilé pour la production d'une version optimisée de l'application).
Bref, chaque solution (printf, loggeurs évolués, deboggueur) est utile selon les cas.
[^] # Re: printf, pour débutant ?
Posté par Krunch (site web personnel) . Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: printf, pour débutant ?
Posté par Nicolas Schoonbroodt . Évalué à 4.
[^] # Re: printf, pour débutant ?
Posté par Anonyme . Évalué à 6.
[^] # Re: printf, pour débutant ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Aprés effectivement, si on arrive à determiner des conditions d'apparitions du bug, on peut passer au deboggeur avec des breakpoint conditionnels. Par contre je ne savais pas que ça se faisait, les breakpoints conditionnels (dans kdevelop apparement, il ne permet pas de specifier ce genre de truc, et la ligne de commande de gdb, je ne supporte pas)
[^] # Re: printf, pour débutant ?
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: printf, pour débutant ?
Posté par Thomas Douillard . Évalué à 5.
Après c'est parfois difficile de déterminer la condition dans des cas tordus, je suis pas sûr qu'il soit possible de mettre un appel de méthode dans la condition par exemple.
[^] # Re: printf, pour débutant ?
Posté par peau chat . Évalué à 4.
;)
[^] # Re: printf, pour débutant ?
Posté par tene . Évalué à 1.
Y'a du remote debugging avec gdb, j'image aussi?
[^] # Re: printf, pour débutant ?
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Euh, c'est un peu le mode par défaut ...
Mais bug != segfault.
Et par ailleurs, en général, l'endroit intéressant, il est quelques instructions avant le segfault (genre « Grmbl, comment ça il est nul mon pointeur, je viens de l'initialiser ? Ah, en fait, non ! »).
[^] # Re: printf, pour débutant ?
Posté par Erwan . Évalué à 3.
C'est pour ca que ce que je fais, c'est mettre des asserts partout pour stopper le processus des que quelque chose d'anormal arrive (genre au debut d'une fonction, les parametres d'entree ne respectent pas certains criteres). Ca aide a debugger, car sinon on se retrouve a planter plus loin.
Je met ca dans des #ifdef DEBUG, comme ca je desactive les asserts pour la version que je livre/publie. Si quelque chose va mal, il y aura peut-etre un comportement bizarre mais moins violent qu'un arret du processus pour l'utilisateur.
[^] # Re: printf, pour débutant ?
Posté par Mildred (site web personnel) . Évalué à 4.
DESCRIPTION Si la macro NDEBUG était définie lors de la dernière inclusion de <assert.h>, la macro assert() ne génère aucun code, et ne fait rien. Sinon, la macro assert() affiche un message d’erreur sur la sortie standard, et termine l’exécution du programme en cours en appelant abort() si l’expression est fausse (égale à zéro).Donc pas besoin de #ifdef DEBUG[^] # Re: printf, pour débutant ?
Posté par norbs . Évalué à 1.
> contient une véritable fonction de recherche multi fichier.
Serait-ce une attaque contre Emacs ???
# Heisenbug...
Posté par peau chat . Évalué à 3.
[aegir@dell ~]$ cat t.c
#include <stdio.h>
int main()
{
int a=10;
printf("%d %d\n",(int)(a*.3+a*.7),(int)(10*.7+10*.3));
}
[aegir@dell ~]$ gcc -O2 t.c ; ./a.out
10 10
[aegir@dell ~]$ gcc -g3 t.c ; ./a.out
9 10
[aegir@dell ~]$
À part ça, GNU/Linux est un système parfait ;)
[^] # Re: Heisenbug...
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
gcc -g3 t.c ; ./a.out
et
gcc t.c ; ./a.out
donc je pense plutôt que ça vient d'un problème dans l'optimiseur, et pas les effets d'ajout des informations de débuggages
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 2.
J'ai juste voulu illustrer que, si on supprime la classique optimisation -O2 pour faire du débogage, et bien on peut voir apparaître de nouveaux bugs.
Dans cet exemple, ce qui est "inattendu" et impévisible c'est :
1) Le faux résultat (9 au lieu de 10)
2) Que le faux résultat disparaisse avec l'option -O2.
En fait, dans cet exemple, le seul truc qui se comprte de façon préfisible c'est le printf() ;-)
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 3.
hl054353@ingvsx3j:/usr/include$ grep "FPU_DEFAULT" /usr/include/x86_64-linux/fpu_control.h
#define _FPU_DEFAULT 0x037f
Donc si tu transformes le code de la manière suivante :
void set_fpu(unsigned int mode)
{
asm ("fldcw %0" : : "m" (*&mode));
}
int main(int argc, char *argv[])
{
set_fpu (0x27F);
int a = 10;
printf("%d %d\n",
(int)( a*.3 + a*.7),
(int)(10*.3 + 10*.7));
return 0;
}
là tu auras bien les bons résultats, comme sur n'importe quel microprocesseur, ou n'importe quel autre un*x sur x86.
[^] # Re: Heisenbug...
Posté par Sebastien (site web personnel) . Évalué à 1.
$ uname -s ; gcc -O2 t.c ; ./a.out; gcc -g3 t.c; ./a.out
FreeBSD
10 10
10 10
Ou pas:
% uname -s ; gcc -O2 t.c ; ./a.out; gcc -g3 t.c; ./a.out
Linux
10 10
10 10
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 2.
[^] # Re: Heisenbug...
Posté par lasher . Évalué à 2.
J'ai testé sur une debian testing, avec gcc 4.0 et 4.1 : bug ;
Sur une red hat customisée : gcc 3.2.3, puis un gcc pré version 4 (gcc-ssa) : ça marche. Idem avec gcc 2.96.
En fait, avec gcc 4, il faut lancer l'optimisation pour que ça marche correctement .
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 2.
Normalement, dans tous les cas, ça doit afficher "10 10".
Ca n'affiche "9 10" que si :
1) Tu es sur cpu x86
2) Tu es sous un Linux compilé en 32 bits.
Sur un BSD sur x86 cela affichera toujours le résultat correct "10 10".
[^] # Re: Heisenbug...
Posté par Troy McClure (site web personnel) . Évalué à 0.
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 1.
Arrondir, ce n'est pas tronquer les décimales.
Enfin, en tout cas, d'après les normes IEEE ça ne devrait pas.
[^] # Re: Heisenbug...
Posté par Troy McClure (site web personnel) . Évalué à -2.
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 1.
Et heureusement !
int i = (int) (100 * 0.1);
peut contenir 9 ???
Ou alors encore mieux :
int a = (int) (100 *2); // donne 200
int b = (int) (100 *2.0); // donne 199
????
Heureusement que non, sinon il y aurait beaucoup plus de bugs ;)
D'après la norme IEEE754 :
"Unbiased which rounds to the nearest value, if the number falls midway it is rounded to the nearest value with an even (zero) least significant bit. This mode is required to be default."
[^] # Re: Heisenbug...
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Heisenbug...
Posté par peau chat . Évalué à 3.
C'est un problème que Linux d'initialise pas le FPU comme il faut. C'est connu depuis longtemps.
[^] # Re: Heisenbug...
Posté par Miod in the middle . Évalué à 1.
C'est au programmeur de paramétrer le mode d'arrondi dont il a besoin, s'il veut avoir des résultats reproductibles.
De façon portable, cela se fait avec fpsetround().
# Heisenbug
Posté par Duncan Idaho . Évalué à 6.
La solution que j'ai trouvé est simple : laisser la gestion de la mémoire, tâche fastidieuse et source de nombreuses erreurs, à un gestionnaire automatique, prévu pour ça. C'est-à-dire en gros, ne pas programmer en C. Je ne parle pas forcément de Java et de son garbage collector (que je n'aime pas pour d'autre raison) mais il est surprenant que, malgré de longues et brillantes recherches en théorie des langages, on se tape encore un langage aussi difficile à programmer que le C. Si l'on compare la programmation à la conduite sur route, le C est une voiture qui va partout même là ou il ne faut pas, alors qu'il existe des routes avec des garde-fous pour éviter de se viander dans les ravins, et même si l'on conduit bien, ça peut servir.
Alors vous allez me dire "ouais, mais le C c'est vachement bas niveau, on peut faire plein de truc avec", ce à quoi je vous répond : "certes, mais si tu ne fais pas de l'embarqué ou de la programmation système, le C c'est juste une grosse perte de temps".
Mon expérience m'a conduit à privilégier le Eiffel, langage brillant s'il en est (orienté objet bien sûr, contrats, pas de pointeurs à la con...) ou bien sûr de super langage de script comme python, bien que ma préférence aille plutôt vers le ruby, plus propre à mon goût.
Bref, la technologie permet depuis trèèès longtemps de s'affranchir de bizarreries comme les "Heisenbug", profitez-en.
[^] # Re: Heisenbug
Posté par Anonyme . Évalué à 3.
[^] # Re: Heisenbug
Posté par Ontologia (site web personnel) . Évalué à 1.
Eiffel a été et est toujours un des seuls compilateur objet à supprimer la liaison dynamique qui rend le code très lent à cause de l'impossibilité d'inliner le code ainsi que l'utilsation de VFT (Virtual Function Table, table de pointeurs sur fonctions) qui vide tous les caches du processeur.
Bon de toutes façon, en terme de performances, C n'en n'a plus pour longtemps.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Heisenbug
Posté par Anonyme . Évalué à 10.
C'est marrant mais j'ai eu une pensée aussi pour lissac en rédigeant mon commentaire.
Note a ceux qui n'ont pas tout suivit : ca ce passe ici http://isaacos.loria.fr/ , quand on en a entendu parlé, ca a l'air très bien, mais vous achèteriez, vous ? - bon j'ai l'air sarcastique, mais j'ai une profonde amertume de voir des gens conserver leur bijou jalousement pour en tirer des sous, mais être totalement incapable d'allécher correctement un éventuel investisseur. Autant faire du libre que de laisser le truc pourrir sur place.
Bref pour en revenir sur le sujet, des gens qui optimisent en assembleur (gardé par des directive de compilation et avec le code portable pour les autre plates formes), ca existe encore, et je dirais que c'est encore heureux, dans bien des cas ca évite de tout transformer en une immense charette (bon c'est pas vraiment le cas du libre, mais on en est pas au tout mutlimédia non plus : j'en prendrais mplayer en témoin.
Les langages haut niveau ne font pas tout, et il suffit de constater que quasiment toutes les applications destinées a un usage quotidien et rédigées en haut niveau n'ont que très peu de succès ... pas par hasard : lent, gouffre a mémoire.
Les language a haut niveau n'ont pour moi que deux application principales : les application que l'ont utilise une fois de temps en temps pour une tache précise, ou pour un serveur dynamique. Après pour les autres applications (celles que l'ont utilise 95% du temps), et les systèmes sous jacent (sans descendre jusqu'au noyau bien sûr), bref 99% du code exécuté sur un machine ... a moins de transformer le tout en charrette.
Bon et puisqu'on est dans le troll a plein dedans : Un des gros intérêts de l'objet est justement la liaison dynamique (vive les classes abstraites ! vive l'interface-peut-importe-l'implémentation !). Sans compter que 95% des développeurs ne veulent pas a apprendre de nouveau concepts (déjà passer du C++ vers Java/C#, houlala c'est dur, ca n'a rien a voir). Il y a le temps avant de détrôner le C/C++.
J'en remet une couche : bien des bug en haut niveau restent difficiles a détecter alors que ca se règle par un bon vieux segfault en C/C++ et c'est pas forcément si mal.
[^] # Re: Heisenbug
Posté par Duncan Idaho . Évalué à 3.
Ma mémoire est bonne : http://linuxfr.org/2006/04/06/20628.html
Bref, ton troll ne tient même pas la route.
Je ne rentre pas en détails sur tes conclusions douteuses quand au caractère lent des applications développé avec des langages de haut niveau : la rapidité d'un programme en informatique est une question tout à fait accessoire. C'est *très* important, mais beaucoup moins que le reste (fiabilité, stabilité, coût de développement, coût de maintenance...) et surtout, la performance dépend à peu près uniquement de la programmation, et certainement pas du langage utilisé.
Alors oui, il y a une différence de rapidité entre un programme Java qui tourne dans une VM pourrie et le même code en assembleur, mais dans la vie de tous les jours et pour des classes de langage comparable (langages compilés, interprétés, dans une VM), c'est un faux problème.
[^] # Re: Heisenbug
Posté par Anonyme . Évalué à 4.
Normal, il n'y en a aucun.
L'histoire c'est que Ontologia nous a beaucoup parlé de lisaac, comment c'était bien et pouvais être aussi rapide que le C ou le C++, et que donc il faut remplacer le C et le C++ par lissac. Donc quand je vois `Bon de toutes façon, en terme de performances, C n'en n'a plus pour longtemps.' je suis sûr que Ontologia ne pensait pas a Eiffel mais bien a lisaac en disant ca.
Sinon pour le reste, je dirait juste qu'une application n'est pas toujours le gros du boulot, et moi je pense beaucoup aux diverses bibliothèques graphiques et compagnie où quelque soit ton algorithme, comme ceux pour faire de l'imagerie (je compte les toolkits, les compositeurs bien a la mode la dedans) ou du multimédia qui ne demandent que de la rapidité de calcul brute. Si on pouvais atteindre des performances équivalente, ca se saurait - tout ca pour des histoires de copies mémoires et autre choses masquées quand on est trop haut. Or le multimédia est de plus en plus présent.
Dernier point, quand on mélange du haut et bas niveau, il faut faire des bindings. Faire cela correctement, sans bugs, et en tirant parti des propriétés du langage cible est un travail long (quantité de fonctions a gérer) et difficile (bien le penser, être rigoureux).
Désolé pour l'incompréhension.
[^] # Re: Heisenbug
Posté par Ontologia (site web personnel) . Évalué à 4.
Erreur, il y en a beaucoup.
Eiffel et Lisaac sont des langages permettant l'héritage multiple.
Ces deux langages utilisent aussi les types paramétriques.
Eiffel est certes un langage objet à classe et Lisaac un langage objet à prototype.
Les similarités entre SmartEiffel sont dus à leur développement. L'auteur de Lisaac a fait sa thèse dans le laboratoire de Dominique Colnet le créateur et mainteneur de SmartEiffel. C'est D. Colnet qui a fait découvrir à Benoit Sonntag (l'auteur de Lisaac) le langage Self qui a été le déclique. C'est parce qu'il travaillai dans ce laboratoire qui était en grande partie dédié à "comment compiler un langage objet avec de bonnes performances que Lisaac est né".
A noter que la librairie de SmartEiffel et de Lisaac sont les mêmes, puisque la première a été traduite pour le second langage.
D'ailleurs Colnet est co auteur de la plupart des publications qui ont été diffusées au début.
Effectivement, je pensais à Lisaac, car une nouvelle version du compilateur est en train d'être écrite qui semble très prometteuse. Lisaac 1 était 2% plus lent que C, reste à descendre en dessous.
Effectivement, je te rejins sur le reste. Plus je programme, plus je me rend compte que l'architecture et la structure de la lib, de l'OS, la qualité du compilateur, etc... sont déterminants.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Heisenbug
Posté par Anonyme . Évalué à 2.
Sinon merci pour ton commentaire positif (j'ai du mal a l'être :) ) qui m'a fait penser "chouette un thread assez frontal qui fini bien !".
[^] # Re: Heisenbug
Posté par beagf (site web personnel) . Évalué à 2.
Va le dire au développeurs ut utilisateurs de MLDonkey par exemple... (Ok, tu as dit "quasiment", mais tu as surtout mit "toutes" en gras) et il y en a pas d'autres.
Le problème c'est qu'il faut savoir ou utiliser chaque langages. L'assembleur n'est utile que dans des cas bien précis ou le compilateur n'est pas capable de générer du code optimal et ou les performances sont critiques. Cela inclut par exemple les boucle interne de décodage de flux video quand des instruction SIMD complexes sont disponibles.
Mais les compilateurs font d'énormes progrès et il y a de moins en moins de code pour lesquels une version assembleur apporte un gain vraiment interessant. Et c'est pour cela que les langage haut niveau ratrapent progressivement les langages bas niveau. Parce que pour pouvoir faire des optimisations aussi complexes, il faut disposer d'informations sémantiques qu'il est impossible de fournir au compilateur en C.
[^] # Re: Heisenbug
Posté par Anonyme . Évalué à 3.
J'ai eu une expérience extrêment douloureuse avec mldonkey, et, c'est vraiment pas pour me faire mousser, mais je le trouvais justement lent (surtout gourmand en mémoire) et bugué (il partait en boucle infinie ... plutôt ballot pour un démon).
Bon certes, c'était il y a presque 3 ans, ils ont sans doute fait des progrès.
Mais aMule qui était loin d'être mature a l'époque, était bien plus léger et réactif, et bien plus stable pour ma part. Et c'est codé en C++/wxWidgets. Et j'étais rempli de bonheur.
Enfin pour continuer sur mon expérience personnelle, aucune application que j'utilise quotidiennement sont codées en autre chose que du C ou du C++. J'ai essayé pourtant, mais a chaque fois je suis déçu : "autant de RAM pour ca" ou autre.
Un autre truc : l'avantage des applications C/C++ c'est que dans ma distribution, elles ne me cassent pas les pieds pour telle ou telle obscure dépendance, c'est un binaire dans un coin, pas de surprises, on est toujours chez soit.
[^] # Re: Heisenbug
Posté par Ontologia (site web personnel) . Évalué à 4.
Je suis totalement d'accord avec toi.
Mais l'Inria a semble t-il un statut batard : organisme publique avec des chercheurs voulant faire de la recherche pur (j'ai vu des chercheurs en venir quasiment aux mains avec un chargé des valorisations industrielles) et des bonhommes cherchant à faire du fric avec ce qui y est produit.
Ajoute à cela la lourdeur consternante qui sied à toute administration française, l'aveuglement avec.
Tu obtiens un sac de noeud improductif (à part dans le domaine de la recherche) et inconséquent.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Heisenbug
Posté par Guillaume D. . Évalué à 1.
[^] # Re: Heisenbug
Posté par lasher . Évalué à 10.
« La solution que j'ai trouvé est simple : laisser la gestion de la mémoire, tâche fastidieuse et source de nombreuses erreurs, à un gestionnaire automatique, prévu pour ça. C'est-à-dire en gros, ne pas programmer en C. »
Si si, c'est de la programmation en C. Utiliser un ramasse-miette externe n'est jamais une mauvaise idée si c'est la seule chose qui te gêne dans le langage.
« il est surprenant que, malgré de longues et brillantes recherches en théorie des langages, on se tape encore un langage aussi difficile à programmer que le C. »
Le C n'est pas un langage « difficile ». Sa syntaxe est l'une des plus simples qui existe, je trouve : il y a peu de concepts à retenir, et le plus difficile d'entre eux, le pointeur, est une notion qu'il est nécessaire de connaître si on veut faire de l'informatique professionnellement - enfin je trouve.
Par contre, pour paraphraser certains grands intervenants de fr.comp.lang.c : « C n'est pas un langage de débutant », et « C is a sharp tool ».
Là où par contre je suis tout à fait d'accord : utiliser le langage C est la plupart du temps inutile, car d'autres langages permettent de faire la même chose plus rapidement, avec beaucoup moins de bugs.
Le C est un langage à destination des programmeurs qui savent ce qu'ils font. Il est très important d'en avoir déjà fait à mon avis pour savoir ce qui peut clocher dans des langages de plus haut niveau, mais pour autant, à moins de programmer pour de la haute performance ou du « bas-niveau », utiliser le langage C dans les programmes de tous les jours relève souvent du masochisme.
[^] # Re: Heisenbug
Posté par Duncan Idaho . Évalué à 3.
mais aussi d'un certain élitisme. J'ai l'impression que faire du C, c'est coule, que ça donne une grosse quéquette parce que c'est dur à faire. Je pense que beaucoup programme en C juste pour le plaisir de se mesurer à des stars du code.
En conséquence de quoi, le C reste utilisé en production (là où il est adapté bien sûr, mais aussi à plein d'endroit où il n'est qu'une source d'erreurs et de retards...) parce que personne n'ose dire qu'il n'y a que 2000 personnes dans le monde capables de faire du C proprement et qu'aucune ne travaille dans l'entreprise concernée :)
[^] # Re: Heisenbug
Posté par pasBill pasGates . Évalué à 2.
Alors maintenant oui, C ca demande plus de connaissances sur les concepts de bases que d'autres langages et ca induit certains risques niveau erreurs de programmation, mais c'est un langage _extremement_ utile. C# et Java c'est sympa, mais ca peut pas repondre a tout loin de la.
Enfin bon, de mon point de vue, le top c'est quand meme C++, les avantages de l'objet allies a la vitesse et flexibilite de C (et voila, c'est comme ca qu'on lance un troll sur les langages !)
# Principe d'incertitude
Posté par boris . Évalué à 1.
Quote Wikipedia :
# Would you like to know more?
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Would you like to know more?
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.