lasher a écrit 2732 commentaires

Sauf que ce que je ne pige pas dans tout ça, c'est qu'au bout d'un moment, tout le monde finit par développer (ou réutiliser) un ensemble de fonctions utilitaires qui justement enrobent les fonctions utiles (donc malloc, free, avec une fonction genre fatal ou crash qui logge un message d'erreur et sort…).

Si ton soft n'est pas critique, il suffit de les utiliser pour que ça plante « proprement ». Sinon, de toute manière il faudra développer ou réutiliser du code plus robuste. Je pense que ce qu'Étienne veut faire passer comme message, c'est qu'il n'est quand même pas sorcier de faire des fonctions « wrapper » pour ce qui est utilisé souvent, et ainsi faire une gestion minimale des erreurs.

J'ai raté quelque chose ?

En l'occurrence, pour le « deux poids, deux mesures », j'avais rajouté des balises <zenitram> et </zenitram> autour, mais elles ne sont pas passées…

J'ai pertinenté, mais juste pour abuser un peu des mouches : il existe UN cas parfaitement justifié pour utiliser malloc/realloc/free : lorsque tu surcharges operator new… :)

Et pourquoi une source secondaire à ton avis?

J'en sais rien, mais visiblement d’après l'article du journal, le mec de Wikipedia qui a répondu n'avait aucun mal à croire qu'il avait bien P.Roth comme interlocuteur.

Parce qu'elle ne souffre pas des problèmes d'identification, de subjectivité supposée et de l'aspect potentiellement inédit d'un travail.

Bon, comparons. Dans un cas, on a Wikipedia qui rapporte l'avis de critiques (NY times,etc.), qui pensent avoir trouvé l'origine de l'inspiration du bouquin. Ils pensent, mais ils n'en ont aucune preuve. De l'autre, on a l'auteur du fichu bouquin, qui dit "tout faux".

Je pense que P.Roth a eu tort de vouloir supprimer purement et simplement le passage en question. Il aurait du tenter de mettre en exergue le fait que ces critiques étaient fausses. Bref, le faire d'une manière qui serait sans équivoque. Et dans BEAUCOUP de publications sérieuses, on peut rajouter une note du genre "conversation privée avec l'auteur". Les gens de Wikipedia auraient même pu demander a Roth s'il était d'accord pour qu'on publie qq part la correspondance (wikisource ?). La, ils ont demande des "sources secondaires".

Parce qu'elle ne souffre pas des problèmes d'identification, de subjectivité supposée et de l'aspect potentiellement inédit d'un travail.

Donc si je résume :

1. J’écris un bouquin, je ne révèle pas comment j'en suis arrivé là.
2. Des critiques disent que j'en suis sans doute arrivé là a cause de telle chose.
3. Tout le monde croit les critiques.
4. Je dis que c'est faux.
5. On m'explique que je manque de crédibilité.
6. WTF?!

Roth a bien d'autres moyens de faire valoir son avis plutôt que d'écrire une diatribe sur un projet dont il n'a pas cherché à comprendre les règles avant d'y intervenir et de s'y voir révoqué (lui ou son assistant…)

Roth a tenté de jouer le jeu en éditant l'article et en supprimant la partie qu'il considérait comme incorrecte. Cependant, comme il a sans doute mal compris la façon de procéder, il s'est fait taper sur les doigts, ce qui était normal. Ensuite, justement parce qu'il ne connaissait pas les règles de Wikipedia, il a contacté quelqu'un la-bas, pour expliquer son problème. Vraiment, quel sale luser ce mec. La-dessus, on lui rétorque que bien que l'auteur soit sans doute le mieux placé pour expliquer l'origine de son œuvre, il faut plus de sources secondaires. Bon ben voila, on a une source secondaire : le New Yorker. Je ne vois pas en quoi c'est illogique. Puisque sa parole n'est pas suffisante, il va voir d'autres gens qui lui font confiance pour se faire entendre.

Roth a bien d'autres moyens de faire valoir son avis plutôt que d'écrire une diatribe sur un projet dont il n'a pas cherché à comprendre les règles avant d'y intervenir et de s'y voir révoqué (lui ou son assistant…). Il aurait certainement économisé du temps en cherchant à comprendre ces règles et le moyen de les utiliser à bon escient, plutôt que de se fendre d'un tel article.

Alors. As-tu lu l'article ? Parce qu'en gros il passe peut-être 10-15% de celui-ci sur son interaction avec Wikipedia. Le reste ? Il donne une sorte de rapport sourcé et circonstancié sur la relation entre le personnage principal de son bouquin et la personne qui l'a inspiré. Bref si les gens de Wikipedia voulaient une source secondaire solide, ben ça y est.

Comme le sais-tu ? Peut-être que l'auteur considère ça comme une remise en cause de sa morale parce qu'il se serait inspirer d'un autre livre (que ce soit vrai ou pas).

Je te propose de lire l'article qu'il a publié dans le NewYorker et te rendre compte par toi-même qu'à aucun moment P.Roth ne se sent atteint dans sa dignité. Il raconte simplement dans l'article comment il en est arrivé à écrire son bouquin.

Mais un jeu commercial et distribué yadda yadda, pas de problème ? Deux poids, deux mesures ?

Bon je ne comprends pas vraiment là. Chez tout plein de gens, il est naturel de fournir des versions static inline un peu de cette façon-là:

/* from some_util_file.h */
/* #includes omitted */

static inline void fatal(const char *msg) {
    perror(msg);
    exit(errno);
}   

/* ... */


static inline void * s_malloc(size_t sz) {
    void *p = malloc(sz);
    if (!p) fatal("Couldn't allocate memory");
    return p;
}

/* ... */

Bref, de proposer des versions « configurables » (car par ex là, ça va forcément toujours planter alors que parfois il existe des moyens de moyenner). Est-ce que ce ne serait tout simplement pas plus simple de toujours faire ainsi ? Comme ça au moins, on sait que quelqu'un, quelque part prend en charge ce genre de trucs, et le code du « vrai » programme n'a pas besoin d'être encombré de vérifications en tous genres…

Laisse Perl tranquille ! Il t'a rien fait ! :-(

Voilà, exactement. D'un côté on a Red Hat qui paie des gens (a priori pas mauvais techniquement) pour developper systemd, de l'autre on a un nombre indéterminé de gens (sans doute en majorité des admins plutôt que des devs), et c'est évident que maintenir l'init façon SysV ou BSD va se faire naturellement, en dehors de leurs heures de travail…

Tu rigoles j'espère ? La politique, ça commence au niveau zéro, celui de l'engagement militant. Si un truc ne te plaît pas, et que tu ne participes pas d'une manière ou d'une autre pour contribuer à ce qu'elle change, tu es aussi coupable qu'un admin qui (au hasard) ne saurait pas faire plus que scripter (parce que bon, le dév système et la prog en C, ça fait 10-20 ans qu'il en fait plus…).

Certes, mais dans ce cas précis, au moment de dire à Roth "il nous faut des sources secondaires", j'ai comme l'impression que son identité n’était plus en doute…

Oui. Plus exactement, c’étaient les spéculations de critiques littéraires. Maintenant comme le disait quelqu'un sur la page de commentaire de Wikipedia à ce sujet : "C'est un fait que des gens ont dit ceci. C'est aussi un fait qu'ils se sont trompés."

Plusieurs intervenants dans la discussion ont alors précisé que Wikipedia n'a pas l'obligation de dire "la vérité", mais bien de sourcer toutes leurs affirmations (j’exagère et je déforme sans doute). Ce que je trouve un peu grave, c'est que si une source qu'on ne peut taxer de "mineure" dit que quelque chose est fausse, ben…

Et oui, tu as raison, on peut toujours vouloir revenir sur ce qu'on a dit, etc. Sauf que dans ce cas précis, on a d'un coté "Machin pense que ce bouquin est inspire par …", et de l'autre l'auteur qui dit "Non, c'est pas inspire par … du tout."

Donc au final, il y aurait sans doute la place pour les deux informations (réception par la critique et réalité des faits), mais la remise en question de la crédibilité de l'auteur du bouquin dont l'article est question a fait monter le tout en épingle.

Pour répondre rapidement :

1. Roth est passée par un de ses collaborateurs pour faire l’édition de la page en question (apparemment, la page citait des critiques du NY times qui faisaient le rapprochement avec l'autre auteur).
2. Ca a été considéré comme du vandalisme, donc le texte original a été rétabli 2 fois je crois
3. Roth a ensuite écrit (on ne sait pas comment : lettre papier ? email ?) a Wikipedia pour qu'on modifie la page (et de ce que j'ai compris, il a demandé a ce qu'on retire la fausse information)
4. C'est la qu'on lui a explique qu'il fallait des sources secondaires (!)
5. Roth écrit dans un journal pour rajouter des sources secondaires…

Ensuite, on ne peut PAS exiger de tout le monde de connaitre par cœur la façon dont Wikipedia opéré, etc. Par là je veux dire qu'un mec de 70+ ans a autre chose à foutre que d'apprendre le protocole de communication avec les admins wikipedia, lorsqu'il a l'impression qu'on dit des choses fausses à son sujet.

Enfin, je ne vois pas pourquoi tu me donnes une définition du dictionnaire pour "allegedly" alors que j'avais déjà fait une traduction au tout début de mon journal…

Moi j'aurais plutôt dit que c'était une référence à « "Il" est revenu », l'adaptation de « Ça » de Stephen King.

Généralement il y a une notion de compensation dans ce cas-là.

Mac OS X permet de formater des volumes en UFS, je dirais depuis le premier jour (en tout cas dans 10.3 c'était déjà faisable).

J'oubliais : le « relativement vrai » s'applique au percevoir des « compagnons » vis à vis de l'autre personne dans le couple, bien entendu. :)

Bon, je vais tacher de trouver des copines "féministes" dans mon entourage et leur raconter/faire lire la blague. Bien que je pense avoir des opinions différentes des tiennes concernant les "limites" du sexisme, etc., je suis d'accord avec toi sur cette blague : il n'y a absolument rien de sexiste de mon point de vue dans cette blague.

Je n'ai pas lu les raisons qui pourraient faire croire ca cette dame que la blague est sexiste. Je suppose que ce sont les références au "silent treatment" et ce qu'une femme veut dire par "nothing's wrong". Bon d'une, je suis d'accord, c'est une généralisation sur le comportement féminin en couple. De deux, le phénomène s'est suffisamment produit dans mon entourage (et avec les copines que j'ai eues) pour que, sans aucune donnée statistiquement vérifiable, je puisse au moins considérer que ce comportement, s'il n'est pas forcement majoritaire, reste quand même SUPER courant. De trois, même si ce comportement est le produit d'une certaine forme de domination patriarcale instaurée par la société (ce dont je ne serais pas difficile à convaincre), ça ne change pas le fait que LA, MAINTENANT, ça reste relativement vrai. De quatre, ça ne veut pas dire que les hommes ne peuvent pas être comme ça non plus. :)

Il y a un DVD qui regroupe trois émissions du tribunal, dont celui de Le Pen. C'est d'ailleurs très intéressant à écouter. Il y dit des trucs qui font froid dans le dos. On y comprend aussi pourquoi Desproges dit "avec un 'H' comme dans HHHHalimi" (car mal prononcé par Le Pen pendant l’émission). Les émissions étaient aussi filmées (peut-être pas celles du début cependant). Du coup on peut aussi y voir la bouille des intervenants, notamment dans le cas Le Pen : un Luis Rego qui ricane en bon sale gosse décrivant la journée d'un fasciste, Le Pen mort de rire, et les rares prises de vue de Desproges, qui ne rit pas du tout. Tu peux trouver les vidéos sur YouTube.

Le coffret comprend aussi des interviews de Villers et Rego (entre autres). C'est la qu'il explique le vote dont j'ai parlé.

Pourtant, à l'occasion où il le dit (tribunal des flagrants délires), il fait pourtant de l'humour (et de très bonne qualité)… Il n'avait pas envie de rire en la presence du borgne, mais il faisait de l'humour quand meme ? Ou bien c'est toi qui veux qu'il l'ait dit dans ce sens là ?

1. Avant de faire cette émission, il y a eu de gros débats au sein de l’équipe du "tribunal" pour savoir s'il fallait inviter LePen. Desproges était contre.
2. Desproges, après avoir "perdu" le vote, a fait preuve de professionnalisme en faisant son boulot (et brillamment).
3. Quand Luis Rego prend la parole, tout le monde (y compris Le Pen) rit énormément. Pas Desproges. D'ailleurs, Desproges n'a quasiment pas souri pendant son propre réquisitoire.

Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça.

… Ou parce que même une fois que tu t'es exécuté, on peut finir par te le refuser. J'ai des témoignages dans le cas précis de Mozilla où des patches pour XulRunner ont au départ été refusés pour des questions de forme (coding style, etc.), puis refusés tout court. De ce que j'ai compris, il s'agissait de patches qui n'avaient pas d'impact « négatif » (au sens de changement lourd dans le comportement de XulRunner). Du coup les personnes en question¹ (qui développent un produit construit par-dessus XulRunner) font leurs propres patches, et ne tentent plus de remonter quoi que ce soit.

[1] Je ne veux pas parler en leur nom, vu que je n'ai jamais travaillé avec eux, et donc qu'il me manque sans doute des détails…

OK, mais là on parle de programmation en C++ pas d'un sous-ensemble de C++. Ta proposition de ne pas utiliser les classes est une façon parmi d'autres de choisir une stratégie pour répondre aux questions que je pose.

Pas d'accord. Pour paraphraser S.Meyers (« Effective C++ »), le C++ est en réalité 4 langages en un :

1. Le langage C
2. Le langage « C avec classes » (et potentiellement en 2b. C avec classes + exceptions + RTTI)
3. C + STL (c'est très, TRÈS utilisé dans pas mal de machins pour simulations numériques soit dit en passant)
4. Le système de templates (en incluant les possibilité de méta-programmation) + C

Tu peux prendre indépendamment n'importe lequel de ces langages, ou bien en faire une combinaison. Pour donner un exemple à la con : j'utilise C++ pour l'écriture d'un runtime. Nous utilisons le système OO, les templates, et nous avons utilisé la STL principalement pendant la phase de prototypage (nous essayons de remplacer les conteneurs STL par des structures de données qui s'adaptent mieux au contexte — à l'exception de std::string, bien pratique). Nous n'utilisons pas les exceptions. Jamais. Nous ne pouvons pas nous permettre de payer pour exceptions et potentiellement la RTTI qui va avec.

Ta fonction écrit sur stdout ou dans un fichier si c'est une valeur complexe ou renvoie un code de retour. Tu récupères la valeur avec '>' ou avec les backquotes pour les valeur complexes.

Ah bah forcément, si tu limites les fonctions du shell à ce qui t'arrange … :-) Mais oui, je suis bien d'accord, le shell n'est que le « squelette » (en gros : structures de contrôle et notion de « statement »). Que le reste soit fait à base d'utilisation de bc, seq, etc. ne me choque pas du tout dans le cadre de Bash. Ce que je dis, c'est que la notion de « fonction » en Bash est en réalité une notion de « procédure » (i.e. qui ne renvoie aucun résultat). Et si tu veux pouvoir communiquer ce résultat à d'autres fonctions dans ton script Bash, ou tout bêtement à l'appelant, tu te retrouve obligé de passer par des variables globales prédéfinies et connues de l'utilisateur de la fonction. Si toutes tes fonctions Bash sont purement autonomes je suis d'accord ça suffit. Si tu cherches à aller plus loin (je ne dis pas que c'est souhaitable), la notion de fonction en Bash est très limitée.

Le shell ne sert pas à manipuler ces valeurs, il sert à coordonner le travail de plusieurs processus (en leur passant les valeurs).

Ben plein de gens ne sont pas d'accord avec toi, sinon la notation $(()) pour faire de l'arithmétique entière n'existerait pas, par exemple (et je m'en suis servi plusieurs fois pour automatiser des benchmarks dont les binaires prenaient en paramètres des valeurs numériques …). Ou les fonctions « builtin », etc.

Cela dit, c'est justement parce que programmer en C/C++/ADA/blah est trop chiant pour ce qui concerne la « coordination de processus », mais que (ba)sh est trop limité dans beaucoup de cas (le script de coordination commence à dépasser la trentaine de lignes ;-)) que des langages comme Perl émergé.

[à propos du passage de paramètre en C/C++] La différence avec ce que j'ai écrit est que tu as supprimé l'opération de recopie. Si tu passes un pointeur avec transfert de propriété et que tu veux continuer à travailler sur la valeur, il faut la recopier. Quelle que soit la façon dont tu résous le problème, tu n'as pas le droit de le passer sous silence.

Donc en gros, tu m'expliques que si je fais des choses plus compliquées que Bash, alors j'ai plus de questions à me poser quant à la façon de concevoir mes fonctions en C++. Je dis que si tu veux rester au « même niveau » de fonctionnalités que Bash pour les appels de fonction, un moyen simple est de faire faire du « tout référence constante » pour le passage de paramètre, et « tout référence » (non-const) pour écrire le résultat de la fonction (ça marche aussi en passant un std::ostream).

Pour la copie, etc., j'aimerais bien que tu me donnes un exemple simple de ce que tu veux dire en utilisant Bash et C++. Les copies profondes ou superficielles ne sont un problème que si tu manipules des objets complexes. Dans le cas des appels de fonction en C++, je ne vois pas le rapport. Ta fonction se fout de la sémantique de copie. Elle prend des paramètres en entrée, et renvoie éventuellement un résultat, point.

a l'epoque, c'etait pas à moi que ca arrivait, mais j'avais déja assez de jugeote pour comprendre en quoi c'etait horrible, et que j'etais assez "bizzare" pour que, s'il n'y avait pas eu encore pire, ca aurait pu être moi le souffre douleur. Je me suis alors demandé ce que j'aurais pu faire pour aider le gars… Pas trouvé de réponse => C'est con pour lui. Tant mieux que ca soit pas moi.

Bah moi j'ai fini par comprendre : un mec qui se retrouve « isolé » et se fait emmerder, ça m'arrivait d'aller l'aider. Je ne le faisais pas systématiquement, mais m'étant moi-même fait agresser quand j'étais plus jeune, j'ai passé une salle période au collège. Quand j'ai changé d'environnement (déménagement des parents et du coup changement de lycée), quelque part j'étais dans un lycée « pire » que le précédent, mais le changement de voisinage m'a permis de m'affirmer un peu mieux. Et je suis petit, pas baraqué.

Maintenant je ne le faisais pas si souvent que ça, mais si tout le monde aidait les plus faibles de temps en temps, y'aurait moins de « bullying » je pense …

Pour commencer tu n'as pas déclaré les prototypes de tes fonctions.

Tu n'es pas obligé de déclarer les prototypes. La norme autorise à ne pas le faire car une définition fait aussi office de déclaration.

Comment passer mes arguments à ma fonction? J'ai le choix entre: par valeur immédiate, par référence, par pointeur sans transfert de propriété, par pointeur avec transfert de propriété, par recopie (si mon objet définit un constructeur de recopie, et que celui-ci n'est pas cassé… ah mais au fait, c'est une copie superficielle, etc.) Et encore j'évite les hypothèses de type pointeur sur void avec information adjascente pour récupérer le type (c'est parfois une option sérieuse).

Non. Tu fais ce que tu veux en C++. Tu n'es même pas obligé de passer par le système orienté objet si tu n'aimes pas. Tu peux parfaitement faire du « C en C++ » avec juste l'avantage d'avoir un typage plus fort et oui, des références à la place des pointeurs quand ça a du sens.

Comment récupérer la valeur de ma fonction? Dans un argument que j'aurais moi-même passé en argument (par référence ou par pointeur?) ou bien dans une valeur de retour, ou bien je renvoie une référence ou un pointeur sur un espace de stockage privé?

Alors qu'en Bash, c'est tellement mieux : tu es obligé de déclarer une variable extérieure à ta fonction, qui vit dans un espace de nommage « global » et donc risque d'entrer en conflit avec d'autres variables (bref, c'est de ta faute si deux fonctions utilisent la/les même(s) nom(s) de variable(s) de retour).

Ensuite, tu utilises tout un vocabulaire compliqué (« espace de stockage privé » ? Vraiment ?). Il y a deux solutions globalement : soit tu renvoies une valeur avec ta fonction, soit tu écris dans une variable passée par référence (que ce soit une référence de type « pointeur » ou « référence C++ », ça reste du passage par référence). Ensuite, n'importe quel codeur C (même pas C++) sait que dès que le type devient un peu complexe, il est préférable (le plus souvent, il y a toujours des exceptions bien entendu) de passer un paramètre par référence (donc par pointeur en C, pointeur ou de préférence référence en C++). Bref, tu as en gros trois choix pour le retour :

type f(paramètres...);               // par valeur, pour les toutes petites structures ou les types primitifs
void f(paramètres..., type& retour); // pour tout le reste en gros
void f(paramètres..., type* retour); // à utiliser en dernier recours, si on a besoin de manipuler le pointeur lui-même

Tout ce qui est qualification de type const, volatile, etc., rentre dans la notion de « type » dans ce contexte.
Je suis le même raisonnement général pour le passage de paramètres pour une fonction en C ou C++.

Comment signaler les erreurs?

Tu fais comme en C : tu utilises un entier/un enum pour le retour de ta fonction. Tu n'es pas obligé de passer par les exceptions. Tu n'es jamais obligé d'utiliser l'intégralité d'un langage, et c'est encore plus vrai en C++ où Stroustrup, Meyers, Sutter & co ne cessent de répéter qu'en C++ on ne paie que pour ce qu'on utilise. Rien ne t'oblige à faire de la méta-programmation à base de templates ou même de faire des fonctions templates si tu n'en as pas besoin. Rien ne t'oblige à faire du « C avec classes » si tu ne le veux pas. Et si tu le veux, rien ne t'empêche de jeter l'encapsulation par la fenêtre si tu veux juste un POD : déclare simplement des structures comme en C (avec l'avantage de pouvoir quand même définir des fonctions membres si tu veux faire un peu d'objet).

Évidemment, C++ est bien plus complexe que Bash, je ne le nie pas. Mais quand on me dit qu'en Bash il est bien plus simple de déclarer des fonctions qu'en C++, je suis très moyennement d'accord. Je me dis même qu'il suffirait de se donner une règle très simple pour « émuler » en partie la façon dont les fonctions Bash fonctionnent : toujours passer ses paramètres par référence constantes (types primitifs inclus), et si la fonction renvoie quelque chose, toujours fournir une/des variables passées elles aussi par référence.

Tu m'aurais dit « en Python/en Ruby, il est bien plus facile de déclarer des fonctions qu'en C++ », j'aurais déjà été plus d'accord. Ce qui me gêne dans les fonctions Bash, c'est l'absence de portée lexicale pour les valeurs de retour.

À la différence de C++ où il faut commencer une psychothérapie à chaque fois qu'on veut définir une fonction

Je sais que l’exagération est voulue, mais définir une fonction en C++ n'est pas plus difficile que définir une fonction en… C. Donc si ton idée est de dire que définir une fonction dans un langage de script quelconque est plus simple que pour les langages compilés classiques bon ben, nous sommes bien d'accord. Et encore, c'est discutable.

/* En C/C++ */
int sqr(int x) { return x*x; }

ou

(* en OCaml *)
let sqr x = x * x

me semblent plus sympa que

# En Bash
sqr()
{    
    sqr_result=$(($1*$1))
}
#do something about sqr_result