Christie Poutrelle a écrit 382 commentaires

Si je pouvais m'auto supprimer le message précédent je le ferais, j'ai dit des conneries.

Je m'auto répond, mais en fait j'avais pas tenu compte du fait que shr_a et shr_b sont déjà boxées, donc l'appel à aux fonctions, en tout cas dans le code ASM, ne montre finalement pas de différence avec les deux appels précédents, mais j'imagine qu'après lors de l'utilisation de la variable shared il y a un unboxing couteux. J'en sais vraiment rien en fait, je suis très nul en c++.

Au vu du code ASM généré, j'aurais tendance à dire que finalement le shared_ptr à l'air d'être une zero-cost-abstraction, je me trompe ? C'est gcc qui compile ça comme ça ?

Même au niveau d'optimisation -Og les appels sont éliminés, en désactivant les optimisations, j'ai bien tout. À première vue et sans trop être sûr, je dirais que f(ptr_a), f(ptr_b) sont les plus rapides et g(shr_a) un peu plus lent, et g(shr_b) encore un peu plus lent, mais encore une fois, sans aller plus loin que juste regarder à quoi ressemble l'ASM non optimisé généré.

EDIT: Attention j'ai modifié ma réponse. Dans tous les cas le code généré est quasi identique, juste un mov est remplacé par un lea entre f(a) et g(a), et un lea est ajouté en plus pour g(b).

Ah mais je viens de comprendre un truc, f et g sont des signatures de fonction mais n'ont pas d'implémentation, forcément ça ne peut pas marcher.

Je ne fais pas de C++, par contre je sais comment regarder l'output du code assembleur généré, mais ne connaissant pas le C++, je n'arrive pas à compiler ce bout de code correctement, il manque les includes qui vont bien je pense.

Voici ce qui m'arrive:

 $ g++ truc.cpp -Og  -o truc
/usr/bin/ld: /tmp/ccmx3foX.o: in function `main':
truc.cpp:(.text+0xdf): undefined reference to `f(A*)'
/usr/bin/ld: truc.cpp:(.text+0xf0): undefined reference to `f(A*)'
/usr/bin/ld: truc.cpp:(.text+0xfa): undefined reference to `g(std::shared_ptr<A> const&)'
/usr/bin/ld: truc.cpp:(.text+0x12f): undefined reference to `g(std::shared_ptr<A> const&)'
collect2: error: ld a retourné le statut de sortie 1

Pour info j'ai rajouté en haut du fichier (suggéré par g++ lors de mon premier essai):

#include <memory>

Mon ordinateur principal ne m'a coûté que 500€, mais l'écran seul coûte plus de 500€, car j'apporte énormément d'importance au confort visuel, mais peu à la puissance de la machine.

De plus, je ne compte pas les disques durs et l'équipement réseau, on monte assez vite à plus de 1500€.

J'aimerais ajouter que de plus, cet ordinateur n'est plus mon ordinateur principal, mais plus le serveur dédié de la maison, car ne vivant plus seul, ce dernier n'a plus la chance de trôner au milieu du salon, et par effet de bord, mon ordinateur principal est maintenant celui de mon travail, qui est portable, et ce dernier est plus cher que ce que j'ai exposé ci-dessus.

Donc ce sondage est relativement biaisé, car il ne précise pas comment on défini un ordinateur principal, notion qui à mon avis est maintenant relativement obsolète pour des informaticiens de métier à l'ère du tout connecté, mais aussi parce qu'il ne précise pas si on doit considérer tous les périphériques.

De plus, un ordinateur tour de bureau ce n'est pas comme un portable, ce n'est pas du tout ou rien, c'est souvent un outil qu'on améliore avec le temps, en changeant des pièces, jusqu'au jour où il est complètement obsolète et qu'on change sa carte mère et son processeur, mais pas forcément le reste, et à cause de ça, estimer le coût est très difficile.

Ce qu'il faudrait évaluer dans le contexte du dernier paragraphe, c'est le montant mensuel ou annuel qu'on accorde à sa maintenance ou sa mise à jour, et ceci varierait énormément selon le type d'utilisation du matériel, entre machine de stockage, machine de bureautique, machine de développeur ou machine de joueur, on varie du simple au décuple en terme de prix, et aux antipodes en terme de matériel.

Comment vous en sortez vous quand vous devez lire du code hors de l'éditeur ?

D'où l'importance d'expliciter les this ou self, ce qui enlève toute ambiguïté à la lecture, et de plus rend aussi la lecture naturelle, car le fait que les membres soient des membres est alors à la fois explicite et dans l'ordre de lecture.

D'où l'importance de donner des noms qui soit sémantiquement liés à ce que fait et à quoi sert réellement le membre ou la variable, comme ça, plus d’ambiguïté du tout. Joel Spolsky a tout à fait raison de ce point de vue là: peu importe les normes de nommages, peu importe le langage: une personne qui ne connaît ni l'un ni l'autre doit comprendre ce que le code fait.

De toute évidence, lire du code sans un bon éditeur n'est que faire une revue très partielle de ce dernier, impossible d'aller en profondeur sans utiliser un outil qui en donne une (de profondeur) par la navigation dans le code, la navigation cyclique dans les références, et les avertissements sémantiques tel que la non utilisation d'une variable ou la détection de code mort, et toute ces autres informations utiles que seule la lecture ne peut pas donner.

Je suis contre les préfixes avec _ (cf. mon commentaire d'au dessus). Ceci dit, excellent point, les éditeurs savent mettre en valeur les variables en fonction de leur portée ou de leur origine, et c'est ça le bon outil à utiliser!

De plus, le conflit de nom avec les paramètres, c'est pas tous les jours, et dans le cas où ça arrive, utiliser le this. pour désambiguer est à la fois légitime, et probablement plus explicite pour le lecteur.

Je recommande la lecture (complète) de https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ et le passage sur l'infameuse "hungarian notation". Je ne recommande à personne de préfixer des variables selon le type, la portée, ou n'importe quelle autre raison qui ne soit pas la sémantique pure du code et de ce qu'il fait. De la même façon, utiliser le tiret du bas en préfixe est relativement stupide: un bon éditeur saura faire du surlignage de différentes couleurs selon la portée de la variable, et proposer une autocomplétion de code intelligente qui met en premier les variables dont la portée est la plus proche.

Génial!

Alors ils sont un peu en retard.

Cet article est assez ancien maintenant, mais je recommande chaudement sa lecture attentive, et jusqu'au bout https://crackstation.net/hashing-security.htm

Il y a des tas d'autres ressources pour ça, la réponse ici est aussi très intéressante: https://stackoverflow.com/questions/11624372/best-practice-for-hashing-passwords-sha256-or-sha512

SHA256 and SHA512 are message digests, they were never meant to be password-hashing (or key-derivation) functions. (Although a message digest could be used a building block for a KDF, such as in PBKDF2 with HMAC-SHA1.)

D'ailleurs, tu remarqueras qu'aucun outil libre orienté web n'utilise SHA depuis bien longtemps pour le password hashing.

Tu n'envoie jamais de courriel à un service tiers tel que spotify, netflix, airbnb etc… Et je peux utiliser mes alias pour envoyer les mails, j'ai donc mon adresse administrative et mon adresse perso qui sont toutes les deux configurées sur mon client mail, avec une signature différente, et mon client est assez intelligent pour pas mettre n'importe quoi dans les headers du mail, et il en va de même pour mon smtp. Donc le nom original du compte reste toujours bien au chaud caché de tous.

D'où l'importance du salt pour créer un hash du mot de passe. Avec un salt au niveau global, ça évite uniquement l'attaque par rainbow table, car il y a peu de chances que ton hash salté corresponde à d'autres déjà craqués et disponibles dans le jean-cloude, mais par contre n'a n'évite pas l'attaque brute force sur la base complète, qui à terme te permet en théorie de trouver l'intégralité des mots de passe de la base. Pour ça, il faut un salt différent par mot de passe de ta base (si le salt est stocké en clair, c'est pas grave), car dans ce contexte, même avec la base de donnée, pour retrouver l'ensemble des mots de passe il te faut temps potentiellement infini, car il faut mener une attaque très longue multiplié par le nombre de mots de passe dans la base, vu qu'ils ont tous un salt différent.

Personnellement, sur mon serveur perso, tout mes mdps sont hashés en sha256

Et saltés, avec un salt unique par utilisateur, salt unique qui est regénéré à chaque modification du mot de passe, j'espère. Et d'ailleurs y'a d'autres algos de hash bien mieux que sha256 à ce que j'ai lu.

Je suis contre la magie, telle que le catch all, au moins je suis sûr que rien n'arrive par hasard, personne ne peut m'envoyer de mail en nimportequoi@mondomaine. Je maîtrise les alias, et je sais exactement à qui j'ai donné chaque adresse.

Perso, j'ai opté pour un mode plus bourrin, j'ai mon propre nom de domaine, qui n'est ni un pseudo, ni un nom de famille, juste un mot en .org que j'aimais bien. J'ai une adresse prenom.nom@domaine.tld pour tout ce qui est étatique, administratif et travail. Un prenom@ et pseudo@ pour famille, amis et autres (toujours le même nom de domaine, bien entendu). Ensuite, j'ai un alias mail par prestataire, genre spotify@domaine, airfrance@domaine, etc… Tout pointe sur la même boite mail à la fin, ce ne sont que des alias.

Dans l'absolu, je ne suis pas contre payer pour ses études, car le fait de payer implique le consommateur du service. Psychologiquement, payer même une somme dérisoire, même 1€, c'est un cap à franchir qui responsabilise et implique le sujet.

Ceci étant dit, ce que j'aime⋅ais en France, c'est que payer oui, mais pas cher, car ça doit être accessible à tous, et j'aimerais que ça le reste, accessible à tous. 2000€ pour une année d'école, pour un étudiant, c'est beaucoup trop.

À la limite, avoir un prix proportionnel aux moyens des parents, ça me semblerait plutôt une bonne chose, tant qu'il n'y a pas d'effet de seuil tel que mentionné dans un autre commentaire. Beaucoup de gens crieraient au scandale "si je travaille dur, mon argent est mérité, du coup j'aurais le même pouvoir d'achat que quelqu'un qui n'a rien, au scandale ! On me tue on me vole !" etc…, mais dans l'absolu, tes enfants ne font pas des études toute leur vie, donc cet argument est stupide.

Avec ton desktop tu aurais au moins aussi les écrans ! Par contre j'ai aucune idée de ce que peut consommer une docking station.

Au cas où, ma réplique était, bien entendu, sarcastique.

En même temps, si on s'assure que seuls ceux dont les parents ont les moyens vont dans les études supérieures, on augmente les chances qu'ils réussissent, vu qu'ils ont eu une meilleure éducation. CQFD.

Vu que je ne conduis pas quotidiennement, que je vais au boulot en vélo, finalement ma journée de travail pollue beaucoup moins que n'importe quelle personne qui devrait prendre sa voiture pour aller au travail (je pense que la distance moyenne habitation-lieu de travail doit être beaucoup plus élevée que 5 km en France).

On peut rajouter à ça que je travaille avec un ordinateur portable qui consomme peu (beaucoup moins qu'une station de travail desktop classique).

Certes, mais ça semble quand même assez dangereux. On vit dans un État de droit, on ne peut pas, en théorie, te condamner pour des faits qui ne correspondent pas à la réalité. Si Google fraude le fisc, alors il devrait être condamné pour fraude fiscale, et pas pour entrave à la concurrence.

Et bien, le problème c'est qu'ils ne font pas forcément quelque chose d'illégal, car la fiscalité n'est pas harmonisée en Europe, c'est aussi un moyen de contourner le fait que certains pays refuse de normaliser leur fiscalité de peur de perdre les grands groupes installés chez eux (Irlande, Luxembourg, autre ?). Du coup c'est le bronx, et tout le monde fait n'importe quoi. Mais dans l'absolu, ça semble résolument transitoire comme situation, parce que si (un si bien théorique) l'Europe arrive à rationaliser la fiscalité dans l'ensemble des pays membres, ces grand groupes n'auront plus aucun échappatoire.

De plus ça semble encore plus improbable que l'ensemble des pays du monde accepte de se mettre d'accord sur rendre les différents moyens légaux de fuite fiscale illégaux, trop de pays perdraient trop d'argent.

Dans les faits, magouiller sur les raisons d'une amende reste le meilleur moyen pour que l'appel soit couronné de succès et l'amende levée, ce qui n'est pas le but de la commisssion.

En même temps, ils semblent avoir trouvé un vrai point de blocage sur Android et la situation de monopole, ça peut marcher.

Je suis d'accord avec ton analyse sauf sur un point, le pourquoi la commission s'attaque à Google. Au vu que c'est une entreprise qui brasse plus d'argent que certains états, et qu'en prime elle s'amuse à tout faire pour ne payer aucun impôt en Europe, Android n'est probablement pas le fond du sujet, mais un moyen comme n'importe quel autre de récupérer l'argent que Google ne paie pas. L'Europe de très près voit un acteur économique majeur s'enfiler max de tunes sans jamais en reverser un centime, alors qu'elle le gagne de manière évidente sur le dos de nous les gentils européens qui utilisons ses outils ses pubs.