fearan a écrit 7241 commentaires

  • [^] # Re: Un temporaire en plus

    Posté par  . En réponse au journal Le quiz c++ de l'été. Évalué à 2.

    Mais une référence de type A

    Oui évidemment, c'était clair dans mon esprit, mais peut être mal retranscrit. Le passage d'un shared_ptr ne doit se faire que lorsqu'il y a un partage sur la possession d'un pointeur et uniquement dans ce cas, ce qui normalement est assez rare.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Un temporaire en plus

    Posté par  . En réponse au journal Le quiz c++ de l'été. Évalué à 3. Dernière modification le 23 août 2018 à 16:44.

    Je dirais plutôt :

    si g n'a pas besoin de posséder la variable ET qu'elle peut être nulle, alors un pointeur nu fait l'affaire
    si g n'a pas besoin de posséder la variable ET qu'elle est forcément définie alors un passage par référence est largement préférable

    Ne pas oublier de mettre des const lorsque c'est possible.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

    Posté par  . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 1.

    La gestion de la mémoire en C++ est dangereuse particulièrement car l'utilisation correcte du RIAA est à la charge du développeur

    Oh trop dur faut trouver un développeur qui réfléchit… Même java se rends compte que l'absence de cette fonctionnalité est gênante et se mette à avoir du try with ( Closable… )

    Mais merde quoi, faut que les gens soient un minimum formés; et quand on fait une liste pour stocker les messages entrant, il faut à un moment se poser la question de fréquence, taille et nombre qu'on stock. C'est une problématique qui n'est pas nouvelle; mais j'ai l'impression qu'avec la grande quantité de RAM à pas cher on omet de contrôler ce détail.

    En c++ tu écrivais un new, il fallait nécessairement se poser la question du delete, et ça pouvait vite tourner au cauchemar pour peu que la suite pouvait péter des exceptions en cour de route, et encore… un dev avisé pouvait se servir d'auto_ptr

    maintenant c'est encore plus simple avec uniq_ptr.

    La RAII, c'est un peu fermer ta connexion quand tu n'en a plus besoin (coucou les finally, closable maintenant), et merci aux ftp limités à 5 connexions, c'est aussi ces même mécanisme qui te permettent d'avoir un logger sax qui va pas te laisser un xml invalide (ou faux) parce que tu as pété là où tu ne le pensais pas.

    Et c'est loin d'être les seuls exemples, mais un mauvais codeur trouvera toujours le moyen de faire de la merde; et s'il ne se pose déjà pas les bonnes questions faut peut être en changer ;)
    Par contre effectivement avoir un Warning : you used new operator, this is so old school, serait pas mal

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Conclusion?

    Posté par  . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 5.

    Bof on est pas obligé de se farcir toute la complexité du langage du premier coup aussi hein ;)

    On peut se limiter à un sous ensemble, et agrandir ce sous ensemble avec le temps et la pratique; cependant certains reflexes sont difficile à perdre ou à prendre; le pire étant de prendre un langage à syntaxe proche, mais fondamentalement différent.

    J'ai vu beaucoup trop de codeur venir de java et faire du c++ comme s'ils étaient en java.

    • Et que je te met un new à la place d'une variable locale
    • et que je ne fait que du shared_ptr parce que c'est trop compliqué de réfléchir un minimum
    • et que je t'écris un singleton qui te renvoie un putain de shared_ptr
    • et que je fais un find suivit d'un insert dans une map pour ajouter s'il n'est pas déjà la…
    • et que je ne te met pas les const sur les getter ou const ref ou…
    • et que je te réécris la même fonction avec un je de paramètres différent parce que j'ai pas pensé aux paramètres par défaut…

    Et j'en passe

    Et j'ai parlé de la gestion des const?

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Détail

    Posté par  . En réponse au journal Google + Commission Européenne = KABOUM. Évalué à 4.

    c'est marrant ça me rappelle le fonctionnement de Microsoft à la grande époque; pour la pré-installation de Windows.

    Pour le point 1, si je me souviens bien, sur mon GS2, c'était le navigateur moisi de samsung qui était fourni par défaut. Je comprends parfaitement que dans ces conditions ils imposent un navigateur potable, c'est une question d'image (par contre ils auraient pu faire un choix au démarrage, comme MS l'a fait pendant un temps) ; par contre y a un paquet de services qui n'ont pas à être imposés (tous les google play).

    Les points 2 & 3 sont inadmissible

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # je demande au grand méchant

    Posté par  . En réponse au journal Recherche sur DLFP. Évalué à 10.

    avec une précision : "site:linuxfr.org"

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: whaou

    Posté par  . En réponse au message Problème de script SHELL. Évalué à 2.

    le soucis c'est que lorsque tu chope un espace la variable ne récupère rien ;)

    tu peux donc tester

    while read -n1 character; do
    echo "[$character]"
    if [ -z "$character" ]
    then
     echo "Espace"
    else
     echo autre
    fi
    done

    j'ai toujours tendance à 'encadrer' mes variable dans mes trace de debug dans ce cas précis tu aurais de suite vu le soucis

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # whaou

    Posté par  . En réponse au message Problème de script SHELL. Évalué à 7.

    1er problème :

    Tester des script en tant que root. JAMAIS!!!

    2eme problème :

    il faut rajouter un espace entre tes [[ et le "$character" sinon tu cherches à appeler la commande "[[4" qui n'existe pas.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable

    Posté par  . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2. Dernière modification le 28 mai 2018 à 09:10.

    Et aupassage je rappelle que la license GPL oblige à mettre les code sources à disposition pendant 10 ans quand on distribue un programme. Donc si tu es contributeur à un projet sous GPL tu es déjà obligé d'assurer de la perrenité…

    La disponibilité des sources n'a rien à voire avec la pérénité d'une adresse mail, tu peux très bien filer le code source en même temps que le programme. Hop, plus besoin de conserver un quelconque serveur pendant 10 ans. Tu peux aussi distribuer ton code uniquement et laisser les utilisateurs le compiler;
    Bref c'est un problème orthogonal à l'impossibilité de changer une adresse mail.

    C'est sympa d'expliquer le pourquoi, mais ça ne règle pas le problème.

    En revanche Nud explique l'existence du .malmap qui permet de palier à ce problème; je n'ai donc plus d'objection.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable

    Posté par  . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 1.

    absolument rien n’empêche de mette "blabla blabla@example.com".

    Super pratique pour être contacté… Sans oublier ceux qui font ça avec leur adresse pro, changement de boite => changement compte.

    tu peux associer une adresse email "virtuelle" à un compte, et voila.
    Ca serait parfois plus pratique (genre on change d'adresse)

    Je serai curieux de savoir quel est la proportion de gens ici à savoir le faire, et s'ils sont capable d'en assurer la pérennité sur plus de 15 ans.

    C'est un choix, oui, reste à savoir si on a envie de changer ça, ou si l'actuel ne convient finalement pas mieux, c'est un débat, mais qui n'est pas lié au RGPD à mon avis.

    Le fait de mettre comme partie intégrante des données des informations à caractère personnel, et se cacher derrière une impossibilité technique pour refuser tout changement/suppression me parait non seulement douteux, mais aussi dangereux. Il suffirait qu'un procès décrète qu'il faut obligatoirement supprimer ces référence et c'est le repo qui va perdre en cohérence.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable

    Posté par  . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 4.

    sans avoir besoin de passer par un annuaire centralisé.

    L'annuaire pourrait être fournis en même temps que le repos git; comme le code, et l'association se faire par le client.

    Si je prends comme exemple ma première adresse mail c'était en IUT; puis très vite caramail, ma troisième un truc sur hotmail pour msn. Aucune des deux première n'est active aujourd'hui, quant à la troisième j'y retourne moins d'une fois par an.
    J'en ai eu 2 autre à l'université.

    J'ai aussi une adresse sur un serveur perso, mais j'utilise plus vraiment.

    J'ai aussi une adresse datant d'avant le rachat de ma boite, perdu encore une fois.

    J'en ai eu une associé à mon compte yahoo, perdu aussi.

    Bref la seule qui a traversé les ans c'est celle de gmail, et j'essaye de limiter son emprise.

    Une adresse de courriel c'est un peu comme ton adresse postale, ça change…

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable

    Posté par  . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2.

    GitLab ne fait que mettre noir sur blanc le principe d'historique fiable.

    que le nom de l'auteur et son adresse de courriel fasse parti du commit me semble superflu; ce serait mieux si c'était un identifiant, et que cet identifiant soit rattaché aux informations personnelles; en cas de demande de suppression de compte, on supprime les données personnelles et on garde l'identifiant.

    Ça permet même de mettre ces données à jours ; dingue ça.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # j'ai plus simpe ;

    Posté par  . En réponse au journal Défragmenter une partition FAT32 sous Linux …. Évalué à 4.

    copie
    suppression (ou reformatage)
    déplacement ;)

    Bon cela nécessite d'avoir de l'espace disponible, mais c'est simple :P

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Gag

    Posté par  . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 2.

    rm avec l’option '-i' par défaut n’incite qu’à acquérir le réflexe d’ajouter '-f' automatiquement

    pour toi peut être, chez moi non. si je veux court-circuiter le -i je fait \rm, et la mécanique de devoir préciser -f ou \ incite fortement à relire deux fois la commande, quitte à faire [ctrl]-[c] [flèche haut] [ctrl]-[a] [\] [return]

    Je recommande d'ailleurs le \ cela évite justement ton cas de figure.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Gag

    Posté par  . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 3.

    Une des raisons pour lesquelles je peste contre les distribs qui ne mettent pas rm -i en alias de base à rm. ça n'évite pas toujours les conneries mais ça aide pas mal.

    Pour cette même raison j'ai tendance à faire un rm d'un ficher nouvellement crée pour vérifier la présence de la question lorsque je sur en distant où une machine que je ne connais pas (oui un alias rm fonctionne aussi, mais un mauvais réflexe est dur à perdre ;)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Blame the victim

    Posté par  . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 2.

    utiliser rmdir à la place de rm -rf pour un dossier vide ;P

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

    Posté par  . En réponse au journal Le filtrage à la source. Évalué à 4.

    En fait le problème il est là.

    Tu sors l'exemple d'un morceau que tu juges digne d'être protégé, et tu l'étends à la totalité du code produit.

    Si tu veux voire jusqu'où les dérive du droit d'auteur va voir ici

    https://pitchfork.com/news/57774-jay-zs-run-this-town-copyright-infringement-lawsuit-thrown-out/

    Par ailleurs ton postula que deux codes sont fatalement différent est faux, j'ai des exemples sous mes yeux dans mon projet, et l'un des morceau est une fonction antérieur à la seconde portion de code, si la deuxième personne avait eu connaissance de la fonction, il l'aurait utilisé (on est pas payé à la ligne). L'exemple sur std::swap est assez parlant, la différence est du à une nouveauté du langage, qui est la move sémantic datant de c++11.

    Moi ce que je crains de ces conneries c'est le risque de la fin du code libre et de l'entraide entre les développeurs, le début de code avec des noms de variables à rallonge pour éviter une éventuelle détection.

    "Ah mais si on ne peut plus recopier du code c'est la fin du monde

    Non, c'est on ne peut plus coder, prends l'exemple que j'ai donné sur le for, cherche dans google, avec les guillemets, regarde le nombre de résultat à l'espace près, et après tu va prétendre que tous le monde à copié les uns sur les autres? Réfléchit un minimum à ce que ton automate de détection de copie soit capable de faire pour être un minimum pertinent.

    par exemple la séquence

    b.addActionListener( 
         new ActionListener() {    
           @Override 
           public void actionPerformed(ActionEvent e) {

    est très fréquente, selon les styles automatique tu peux l'avoir entre 2 et 4 lignes.

    Avec les dérive de la détection auto de youtube (chant d'oiseau ou bruit blanc par exemple), désolé de ne pas applaudir, quelque chose qui va prétendre que mon code, ma production est celle d'un autre.

    Toujours dans les exemple de 3/4 lignes qui vont faire tilter ton détecteur, encore java, un GridBagLayout, ou plus globalement tout ce qui se fait à coup de builder, tous les import (java/python) / include (c/c++)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

    Posté par  . En réponse au journal Le filtrage à la source. Évalué à 4.

    Pas de bol, ça n'est pas l'implémentation de std::swap, qui utilise std::move

    Oups désolé de faire du C++ pré C++11, un manque de pratique :P;

    Ces filtres servent à empêcher l'upload de matériel protégé par le droit d'auteur

    justement soit il font plus que de la bête comparaison et ils sont inutiles si je copie comme un vandale du code le réarranger est trivial, un peu comme inverser une vidéo sur youtube ou la ralentir, c'est encore plus facile (shift-f6->refactor->rename)

    Prends ta souris, rajoute une trompe, grossis 1000 fois, et tu as un éléphant, donc une souris ressemble vachement à un éléphant.

    Si je prends Harry Potter, et que je renomme tous les personnages/lieux, ça reste Harry Potter.

    Les implémentations de patron de conception, sont toutes proche voire identique au renommage près.

    mais pourquoi tu lui inventes des contraintes;

    c'est pas une contrainte c'est le minimum pour que ça serve à quelque chose.

    Ensuite pour une raison de dérive usuelle des droit d'auteur je suis contre ce genre d'approche, déjà qu'on doit déjà se battre contre les troll de brevets, si on doit en plus se farcir les trolls de snipet de code, on est pas sorti de l'auberge; des chants d'oiseau se sont fait dégommer par youtube par exemple.

    Après, il y a peut-être quelques copieurs-colleurs fous qui mouillent un peu ;

    Je connais très peu de dev qui ne posent aucune question à google, les forum d'entraide entre développeur sont une ressource essentielle; si demain le gars qui vient de répondre sur SO se fait jeter son commit parce-que le gars qu'il vient d'aider a fait son commit avant, il réfléchira à deux fois avant d'aider.

    Et contrairement à toi, je ne pense pas qu'un calcul de somme, de moyenne, un tri ou autre brique élémentaire de code ne doive être monopolisé.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

    Posté par  . En réponse au journal Le filtrage à la source. Évalué à 5.

    tiens j'ai fait un essai : "for ( int i = 0 ; i < size ; i++)", dans google j'ai un bon paquet de résultats, change ton R_xlen_t en int tu as deux autre résultats.

    Tu as volontairement pris un exemple avec une faible occurrence, pour prouver ton propos.

    Le problème c'est que tu as une vision très étriqué de ce qu'est le code. Si il suffit de renommer les variables pour être hors d'eau, ton système n'a aucun sens car ce n'est pas ce que l'on cherche à protéger. Si il faut que ton détecteur soit capable de détecter le renommage, tu vas avoir des millions de faux positifs.

    Aucun auteur, aujourd'hui ne construit sur rien, il s'inspire de ceux qui l'ont précédé; utilise des 'patrons' plus ou moins usuels pour constituer son histoire, et c'est cet agencement qui est protégé par le droit d'auteur. On ne demande pas à un auteur d'être concis, on leur demande même d'avoir un vocabulaire riche, là ou le développeur doit aller au plus vite, et où les variables ne changent pas de dénomination en route.

    par exemple pour échanger deux valeurs a et b, on peut écrire

    template<typename T> void swap(T &a, T &b)
    {
       T c=a;
       a=b;
       b=c;
    }
    
    // ou 
    
    std::swap(a,b);

    voila j'ai fait le tour de ce qu'on peut faire en c++ pour un développeur normal;
    note bien j'ai aussi la variation pour les long/int/short

    a+=b;
    b=a-b;
    a=a-b;

    et on peut encore inverser a et b. ou replace a+=b par a = a + b, ou utiliser auto à la place de T;

    Voila, j'ai donné des variations voila, maintenant trouves une autre solution susceptible d'être écrite par un développeur, le renommage ne compte pas, et le formatage non plus.

    Toujours si on veut aller ver la protection du code, il faut que ton analyse soit capable de repérer des inversions de lignes, virer le code 'mort', Bref maitriser les techniques de dissimulations, il faut que ton outil soit suffisamment fiable pour ne pas se planter tous les deux commits.

    J'ajouterai que protéger du code comme on protège la littérature va être folklorique avec un blocage jusqu'à 70 ans après la mort de l'auteur ;) La programmer deviendra vraiment de l'art ;) Je plains les nouvelle génération qui devront faire un "Hello world", en s'assurant de n'avoir pas de prior act ;)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

    Posté par  . En réponse au journal Le filtrage à la source. Évalué à 8.

    Je pense que c'est exactement la même chose pour le code. Trois ou quatre lignes identiques, ça ne peut pas être du hasard.

    Euh… Comment dire… C'est juste fréquent, très fréquent même; j'aurais même tendance à dire que c'est 4 lignes de codes puis autre 4 lignes de code, pis encore d'autre qui forment la majorité des programmes.

    Fait un "Hello world" en C, sur 1000 personnes tu vas avoir plusieurs programme exactement identique.

    Quand on fait du code, on part pas dans le lyrique, on va au plus efficace, les variable de boucle ont tendance à s'appeler i,j,k,l, une classe à un nom explicite et concis, un itérateur it (ou itClasse)

    Je ne parle même pas de java avant les lambda (java 8), où les mêmes morceaux de codes étaient répétés, ad nauseam. Comme les IDE formatent ton code réordonnent les include/import selon des règles pré établies, les convention grandement partagées la mise en forme est l’œuvre d'un automate.

    Les même problèmes ont les même solutions, les algo sont pour la plupart connus, et c'est la mise en œuvre qui échoie aux développeurs.

    Je ne parle même plus de l'entraide aux développeur (fait un tour sur stackoverflow , où des gens posent des questions, et d'autre gens répondent avec du code généralement fonctionnel, ce code qui va se retrouver dans le programme, légèrement adapté )

    La grammaire d'un langage de programmation est rigide et limite énormément ce que tu peux écrire, et on s'embarrasse pas de fioritures;

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # solution simple

    Posté par  . En réponse au message Vos techniques pour refroidir les serveurs sans clim. Évalué à 10.

    pour refroidir les serveurs
    une commande :
    $> halt (ou sudo halt, ou shutdown -h -NOW)

    pour refroidir les opérateurs une autre commande :
    un billet sncf pour la Bretagne ou la manche en bord de mer ;)

    sinon, sans arrêter les machines, mettre les commerciaux d'un coté, les architectes de l'autre et la salle machine en plein milieu, en plein courant d'air ;)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: Ou presque ?

    Posté par  . En réponse au journal [HS ou presque] Réduire le chômage ?. Évalué à 3.

    en fait j'ai plusieurs justification (ou presque) de la présence de ces deux mots :

    • le débat politique c'est un peu une seconde nature de linuxfr,
    • l'auteur a considéré que le gain de productivité grâce à l'informatisation aurait du mettre sur le devant l'évidence de la nécessité de partager le travail.
    • cela a été posté un trolldi, aucun journal n'est HS un trolldi, sauf peut être une biographie sur un chanteur canadien récent.
    • la réponse D

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: refus

    Posté par  . En réponse au message Piratage compte amazon. Évalué à 2.

    Il est évident que ce n'est pas un vol ni une usurpation d'identité,

    Hum, je n'en serai pas si certain, le pirate s'est fait passer pour quelqu'un d'autre auprès du site.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: moi j'adore

    Posté par  . En réponse au journal Bookmark : Interview d'Emmanuel Macron sur l'IA dans Wired. Évalué à 2.

    Bref, le problème n'est pas politique, mais le peuple (comme souvent), et c'est long à convaincre un peuple :(.

    Ah si les gains de productivité avaient profité au peuple on en serait pas là… Certes on en profite un peu, mais largement moins que ce que ce gain de productivité à permis.

    Mais l'homme est un éternel insatisfait, jaloux de ce qu'ont les autres, et rangé dans une norme, et gare à celui qui s'en écarte, suffit de voir la tête de la RH, ou de mon ex-patron lorsque je parle de passer au 4/5e.

    les suisses ont dit merde à plus de congés

    Et ils ont aussi beaucoup plus de temps partiel qu'en France, ce qui fait qu'en moyenne ils bossent moins.

    Donc Je vais préciser ma position :

    a) Si l'ia augmente la productivité, on produit plus, je suis pour qu'on augmente les salaires, c'est logique.
    b) Si on réduit le temps de travail, il est normal que le salaire baisse, c'est tout aussi logique.

    En fonction des gains et de la réduction tu pourrais même travailler moins pour produire plus, ou réduire encore plus drastiquement, et gagner moins.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # moi j'adore

    Posté par  . En réponse au journal Bookmark : Interview d'Emmanuel Macron sur l'IA dans Wired. Évalué à 8.

    Il oppose une vision de court terme (l'IA détruira des emplois à court terme) et de long terme (l'IA permettra, via des gains de productivité, de créer plus d'emplois qu'elle en a détruit). C'est intéressant, parce qu'en général, on oppose ces deux visions sans voir qu'elles sont sur des échelles de temps (et s'appliquent à des personnes) différentes.

    Non il ne créera pas plus d'emploi à long terme; c'est bien beau de vouloir rassurer sur le long terme, mais un gain de productivité ne va pas créer des emplois. Ce que permet un gain de productivité c'est de produire plus avec moins.

    Avec le chômage que l'on a, tout ce qu'on va faire c'est l'augmenter. Par contre on pourrait réduire généralement le temps de travail, mais vu qu'on ne le fait déjà pas…

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent