Je t’invite à aller lire les nombreuses explications de Me Eolas sur le « pourquoi il faut garder le silence ».
La réalité, c’est qu’au moment où les flics font la perquisition, tu ne sais absolument pas ce qu’ils cherchent. Et si ça se trouve, ils trouveront des trucs qui leur laisseront penser que tu es coupable de X, quand bien même ce n’est pas le cas. Bon courage pour te démerder ensuite avec ça.
Et pour les charges supplémentaires, laisse moi rigoler. « M. le juge, je suis bien désolé, j’ai oublié mon mot de passe ». À part lire dans ton cerveau pour prouver que c’est faux, le juge aura bien du mal à te condamner pour quoi que ce soit, et certainement pas pour entrave.
Après, une fois que tu t’es concerté avec ton avocat, si effectivement il n’y a rien de compromettant sur le disque, et que c’est un moyen de prouver ton innocence, oui, tu pourras donner la clé. Mais si tu es effectivement coupable, que le disque est compromettant (ie, il contient tous les épisodes de la série X qu’on te reproche d’avoir téléchargé), la réalité est que tu as tout intérêt à ne pas donner la clé : on ne pourra pas te condamner pour ça (et trouve moi une jurisprudence si tu veux affirmer le contraire, j’ai expliqué pourquoi l’article de loi ne pouvait s’appliquer), et les preuves ne pourront être retenues contre toi puisqu’elles n’existeront pas.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Sauf qu’on ne peut pas t’obliger à fournir des preuves contre toi-même. C’est un droit fondamental de la défense, celui de garder le silence.
Ton article s’appliquera en revanche si la justice a besoin des informations contre un tiers (ce qui est une bonne raison de ne pas faire confiance à un système tiers qui détiendrait la clé de chiffrement).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Bref si les gc ne sont pas aussi performants que la RAII et qu'ils ne s'appliquent qu'à la gestion de la mémoire
Deux problèmes (vécus) des GCs :
- la latence : l’exécution du GC freeze le programme, dans certains contextes ce n’est pas acceptable
- l’occupation mémoire et la cohabitation avec du code non garbage collecté. Certains GC ont une fâcheuse tendance à ne libérer la mémoire que quand il n’y en a plus, ce qui pose problème dans le cas d’un environnement hybride (typiquement, asp.net avec appel de code non managé) --> si le malloc qui échoue est dans le code managé, le GC se lance, s’il est dans le code non-managé, le GC ne se lance pas, et le code non managé n’aura jamais accès à la mémoire qui lui manque. Après, ce problème pourrait se résoudre par l’utilisation de process séparés, comme tu le préconises, mais cela a un coût. Dans un contexte serveur, le coût d’exécution, c’est de l’argent.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Il y a plein de bouts dans les jeux vidéos qui sont faits dans des langages garbage collectés (c#, python, scripts divers), sur des parties non critiques.
Bien sûr, ça ne concerne généralement pas le moteur graphique quand on veut de la perf à tout prix.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Il y a utilisation de l’opérateur d’incrémentation postfixé à chaque itération de la boucle, donc une copie en plus. Certes, ça fait que 8 octets l’itérateur, mais c’est une copie en plus à chaque itération de la boucle. Tout ça pour virer 1 test --> FAIL.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Me semble avoir vu un papier sur l'utilisation de la fonction C sort, contre je ne sais plus quel algo générique C++ ou le C++ était effectivement supérieur. Mais supérieur à mon avis uniquement à l'implémentation standard C.
En fait, la différence est dans la manière dont se fait l’appel à la fonction de comparaison. Avec qsort() en C, on passe par un pointeur de fonction. Avec std::sort, le compilateur va générer l’ensemble du code de tri, spécialisé pour la fonction de tri donnée. L’empreinte mémoire sera un peu plus grosse, mais en revanche on se passe du pointeur de fonction, l’appel au comparateur est plus rapide, au final on est gagnant.
Et C n’offre pas d’alternative autre que de réécrire l’algo spécialisé pour le type en question pour avoir les mêmes perfs. En C++, c’est le compilateru qui le fait pour toi.
De la même manière, une bibliothèque comme ublas (calcul matriciel) met une branlée à toute bibliothèque C pour toutes les opérations non spécialisées dans les libs C, grâce à l’utilisation d’expression templates.
J’avais lu un comparatif assez intéressant, je crois fait par les devs de scala au départ, sur les perfs entre C++, Scala, Java (je crois qu’il y avait un autre langage mais je ne me souvient plus lequel, peut-être go). La conclusion qui en ressortait était que le programme « naïf » écrit en C++ était plus lent que celui écrit naïvement en scala, et qu’après optimisations ils étaient à peu près équivalent. Ensuite, ils ont donné le programme à un gourou C++ (un vrai), qui a fait de vraies optimisations de gourou, et là les perfs étaient quelque chose comme 20% meilleures, quelque chose qu’ils n’ont jamais pu atteindre en scala. Par contre les optimisations en question étaient très loin d’être à la portée du dev moyen.
D'ailleurs, ce if, il ne sera pas optimisé par le compilateur en débogage, je me trompe? C'est peut-être une micro optim, c'est vrai, mais est-elle illisible? Et si ce n'est pas le cas, pourquoi ne pas l'utiliser?
Quelques raisons :
- la liste vide pas gérée, et c’est pas précisé (un connard va copier/coller le code et l’utiliser ailleurs)
- le goto est un nid à emmerdes, j’aime pouvoir faire un "grep goto *" et que ça soit vide
- tu optimises au mauvais endroit. Tu supprimes un test, alors que la première chose à faire, c’est d’optimiser l’allocation mémoire au moyen d’un reserve()
- dans le même genre, je fais mal aux mouches mais tu concatènes avec ";" alors qu’il serait plus efficace de concaténer ';'
Donc en gros, tu micro-optimises, mais mal, et donc tu complexifies la lecture du code pour un gain négligeable. Je préfère largement voir dans le code :
qui prend une ligne à écrire, et fait ce que tu veux de manière largement assez efficace (c’est à dire, vraisemblablement autant que ta version « optimisée ») partout où ce n’est pas nécessaire de faire mieux.
Cela dit, si le sujet de la micro-optimisation en C++ t’intéresse, je t’invite à regarder les conf’ d’Alexandrescu, c’est hyper technique et hyper intéressant de ce point de vue.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Pas un mot sur l’ABI, alors qu’on parle de rétrocompatibilité, c’est un gros lol.
Il est au courant, le monsieur, qu’on peut :
- casser l’API sans casser l’ABI
- casser l’ABI sans casser l’API
- casser les deux à la fois
- préserver les deux à la fois
Bon courage pour faire un schéma de versioning qui fasse la différence (car elle est ultra-importante) avec seulement 3 chiffres…
Et sinon, +1 à tous ceux qui ont déclaré que c’était déjà majoritairement utilisé dans les projets qui ne différencient pas ABI/API. Rien de bien nouveau.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
De manière générale, sous windows il vaut mieux utiliser les APIs W chaque fois qu’il y a le choix, et travailler en wchar_t (LPCWSTR si mes souvenirs sont bons). Attention toutefois à ne pas confondre deux choses dans le cas présent :
- les APIs unicodes (finissant en W)
- les « long path », commençant par \?.
Le deuxième n’est effectivement utilisable qu’avec les APIs unicode, mais utiliser les APIs unicode avec des chemins « standard » n’affranchit pas de la limite à MAX_PATH caractères.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Le case insensitives ne devrait pas être géré au niveau du système de fichier, comme la traduction des dossiers ou les fichiers cachés. Le faire au niveau du système de fichier ça pose des problèmes complexes à résoudre dans un tas de logiciel notamment pour les gestionnaires de versions (il faut vraiment faire gaffe avec svn pour renommer un fichier en changeant uniquement la casse de sont nom).
Ça tombe bien, NTFS est case-sensitive. C’est l’api windows qui s’occupe de faire la traduction (de même pour les noms de fichier 8.3, etc). Et c’est très possible de passer outre, en utilisant les APIs adaptées.
Je crois que FAT32 sous linux peut l’être aussi (case-sensitive). D’ailleurs, fondamentalement, un chemin n’est pas vraiment une « chaîne de caractères », c’est plutôt une suite d’octets sans signification particulière, et surtout sans notion d’encodage (donc fatalement, ça ne peut pas être insensible à la casse, notion qui n’existe pas à son niveau). Ça pose notamment plein de problèmes amusants quand cette suite d’octet est invalide dans l’encodage par défaut du système (ceux qui ont migré une machine du latin1 vers l’utf-8 doivent savoir de quoi je parle).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je ne connais pas LightZone. En revanche, je connais pas trop mal Darktable, pour l’utiliser régulièrement.
Peux-tu détailler un peu les points qui te font dire que Lightzone est beaucoup plus simple à utiliser que Darktable ?
J’ai l’impression que c’est principalement quelques détails d’interface qui feraient la différence, mais le diable se cache effectivement dans les détails.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Abusivement, on parle de « négatif » pour le fichier RAW (c’est à dire le fichier « brut de capteur », sans aucun post-traitement).
Darktable est un outil dédié au traitement de ces fichiers raw.
Sinon, pour répondre au commentaire du dessus, darktable est « non-destructif », dans le sens où il ne modifie pas le fichier d’origine. Il n’y a pas de bouton « sauvegarder », mais il y a un bouton « exporter en jpeg ».
C’est un super logiciel de part ses capacités, mais il n’est pas « tout public ». Malgré sa relative simplicité d’utilisation, c’est un logiciel qui s’adresse avant tout à un public qui souhaite passer du temps à traiter ses photos pour en tirer le meilleur. La courbe d’apprentissage peut rebuter les moins motivés.
Il y a quand même de supers tutos dispos sur le net.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je ne suis pas d'accord avec toi. Systemd impose de lourds changements chez tout le monde… à commencer par ceux qui n'ont rien demandé : les BSD. Est-ce normal pour toi qu'ils doivent rajouter des API de compatibilité ? Alors qu'ils n'ont strictement rien à voir. Il y a des modifs dans le kernels, système d'authentification (gnome)… etc.
Raté, c’est pas systemd qui impose quoique ce soit, c’est gnome (et d’autres).
Les dev de gnome ont estimé que c’était plus simple pour eux d’utiliser les APIs de systemd plutôt que de se carrer la gestion de n systèmes différents, que ça réduisait leur quantité de code à maintenir, et qu’en plus, c’était plus modulaire car ça permettait à tous les systèmes d’être compatibles (du moins, dès qu’ils peuvent faire tourner dbus, ce qui est le cas de tous les systèmes sur lesquels gnome tourne), via des APIs de compatibilité, et pas seulement ceux que eux (gnome) maintenaient.
Au final, grâce à systemd, gnome devient théoriquement portable sur plus de systèmes :trollface:
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Le propos, c’est que les outils de développement BeOS (api, etc) t’incitent très fortement (quasiment, forcent ?) à utiliser une architecture multithread, là où les outils de développement gtk / qt / win32 t’incitent plutôt à tout faire dans la mainloop du thread de la gui.
Et effectivement, régulièrement, des applis freezent, sous windows comme sous linux. Tu peux blâmer les développeurs, dire que ce sont des incompétents et qu’il y a tous les outils dont ils ont besoin. Ça te fera peut-être du bien, mais ça ne changera pas grand chose au final…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
C’est amusant. Tu préfères un opérateur ternaire et un single return à une structure if/then/else à return multiple. Là je dois avouer qu’à part une histoire de goût personnel, je ne vois vraiment rien qui favorise l’un ou l’autre (personnellement je préfère le return multiple, même avec ton indentation je ne suis vraiment pas fan du ternaire).
Sinon, le single return, en C, vient souvent avec la nécessité du nettoyage, qu’on ne veut pas dupliquer. C’est vilain et pas beau, heureusement C++ nous permet de nous en passer.
Dans tous les cas, comme tu l’as dit ailleurs, ce qui est le plus important, c’est avant tout de limiter la taille des fonctions.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Oué, faut pas déconner quand même.
C'est pas trivial vu le nombre de dev c++ qui ne comprennent pas les lambda, et c'est pas concis non plus.
Amusant que tu répondes ça. Pour moi ce code est aussi trivial que l’est la forme ruby que tu as donnée pour toi. Et la syntaxe des lambdas se comprend en deux minutes…
Et c'est pas aussi expressif (even? l'est beaucoup plus)
Cf la réponse de michel à propos de nommer le prédicat. Mais quitte à nommer, je préfère nommer la ligne entière : la lisibilité est nettement meilleure, pour tout le monde.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Cette structure est triviale en C++. Et elle se comprend très bien telle qu’elle (au moins aussi bien que ta structure ruby), et est concise.
Maintenant, replace la dans un contexte, à savoir, au milieu d’autres structure du même type, peut-être dans une boucle, bref. J’estime être pas mauvais en C++, je travaille avec quotidiennement, j’ai l’habitude d’en lire, et pourtant, quand j’écris du code, j’évite ce genre de trucs. Au final, la forme que je vais utiliser, c’est beaucoup plus :
copy_even_numbers(v2, v1); // là, je vois tout de suite ce que ça fait, et je suis sûr que tout le monde comprend
Et pour l’implémentation de copy_even_numbers, qu’elle fasse une ligne ou 4 ne change finalement pas grand chose. Si j’opte au final pour la forme du std::copy_if, c’est parce que je sais qu’elle est plus efficace qu’une boucle naïve.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je comprends pas un mot de russe, pourtant les russes le parlent depuis leur plus tendre enfance.
S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.
"Les identifiants sélectionnés sont, parmis les identifiants, ceux qui sont paires". Je ne vois pas ce qui perturbe. Le { | | … } quand tu viens d'un autre langage ça surprend si tu découvre et après 2h c'est assimilé, soit tu ne découvre pas.
J’ai trop vu cet argument appliqué à perl pour y accorder la moindre crédibilité. Le problème est que oui, une structure, ça s’assimile assez vite, mais souvent elle n’est pas seule. Et qu’à force, on se retrouve avec des choses qui sont peut-être lisibles pour un spécialiste, mais :
- je ne suis pas convaincu que ce soit plus lisible qu’une forme moins concise, même pour le spécialiste en question
- c’est clairement moins lisible pour un non-spécialiste
Pourtant tu interdit certaines boucles et certaines autres constructions pour des raisons de lisibilité. On est loin, très loin, de parties du C++ comme la programmation par template.
Encore une fois, tu vas largement au-delà de ce que j’ai dit. Je dis qu’une construction qui n’apporte que de la concision (on est donc à des années lumières de ce qu’apportent les templates en C++ ou la métaprogrammation) n’apporte pas forcément de la lisibilité. Que
for(auto item : maliste) // super
réussit à être à la fois plus lisible et plus concis en toute circonstance, mais que
int a = mafonction(b,c)?4:mafonction2(b+c);
est en général inférieur en lisibilité à
int a;
if(mafonction(b,c)) {
a = 4;
}
else {
a = mafonction2(b + c);
}
En clair, je dis qu’utiliser des fonctions du langage super cool là où ça ne sert à rien relève du pédantisme plus que d’autre chose (là encore, cf perl pour voir à quoi ça mène). Après, chacun est libre de s’exprimer comme il veut, et chaque langage fait les choix qu’il veut. Et encore une fois, il faut faire preuve de mesure : l’excès, dans un sens ou dans un autre, n’est jamais bon.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Oui mais là on parle d'une construction de base du langage. Pas d'une forme trop littéraire. A comparer c'est plus proche du participe passé que d'une allitération.
Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas. Après, les goûts et les couleurs…
Donc tu écris ton code pour quelqu'un qui ne connaît pas le langage.
Tu tires des conclusions un peu trop rapides et va largement au-delà de ce que j’ai dit. Je dis qu’une construction, fut-elle « de base » dans le langage, plus concise mais dont la lecture n’est pas intuitive, ne fait pas forcément gagner en lisibilité au programme. L’exemple déjà donné de l’opérateur ternaire est assez pertinent, aussi.
Comme toujours sur un sujet subjectif comme la « lisibilité », je crois que c’est surtout vouloir établir une règle unique ou d’être trop rigide sur des principes qui pose problème. Beaucoup relève au final du contexte.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Quand tu écris français cherche-tu a limiter ton vocabulaire et à utiliser des phrases courtes et simples pour faciliter la vie des non-francophones ?
Disons que j’évite l’emploi de formes trop littéraires (par analogie, trop spécifiques au langage) si je suis en train de rédiger une doc technique. Au final, je trouve ta comparaison très pertinente, même si on n’y voit pas la même chose :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Les choses ont pas mal évoluées depuis les dernières fois où j’avais regardé, mais :
pour les typedef vers les valeurs entières, je crois que ce n’est pas possible et que l’idée est de passer par un struct qui contiendra ta valeur uniquement (la question restante est alors de savoir si le compilo génèrera un code optimal, rust est plutôt pas mauvais à ça).
pour les types avec modulo, même remarque
les types très strictement définis, je ne sais pas ce que c’est (mon ada date un peu)
pour la définition précise de la structure de données, il y a des choses, principalement pour la compatibilité avec l’ABI C, mais rien d’aussi riche que ce qu’Ada propose.
De toute façon, il y a avant tout l’aspect Ada est certifié, approuvé, Rust non.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
En fait on ne parle pas forcément de la même chose.
Je suis parfaitement d’accord que des constructions plus simple, comme :
for(auto v : maListe) {
...
}
sont nettement plus lisibles que :
for(std::list<int>::const_iterator it = maListe.begin(); it != maListe.end(); ++it) {
...
}
Qui sont inutilement trop lourdes. Néanmoins, je n’ai jamais été convaincu par les raccourcis « artificiels », comme memcpy, substr, ou l’utilisation d’opérateurs dans tous les sens pour gagner 3 caractères.
Est peut-être clair pour toi qui connaît bien ruby, est indiscutablement plus concise, mais pour moi c’est incompréhensible au premier abord. J’ai besoin de réfléchir pour comprendre ce que ça fait, alors que la première forme que tu donnes est directement compréhensible.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Posté par whity .
En réponse à la dépêche Meteor 1.0.
Évalué à 1.
Je vois ça comme un inconvénient l’aspect « plateforme ». AngularJS me plaît car il me laisse utiliser ce que je veux pour ma partie serveur (et donc, réutiliser une bonne partie de mon existant).
Après, tout est évidemment question de contexte. Mais de manière générale, l’aspect tout intégré est un frein à la réutilisation de composants.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Point sécurité.
Posté par whity . En réponse à la dépêche Se passer de Dropbox en montant son coffre-fort numérique à la maison. Évalué à 3.
Je t’invite à aller lire les nombreuses explications de Me Eolas sur le « pourquoi il faut garder le silence ».
La réalité, c’est qu’au moment où les flics font la perquisition, tu ne sais absolument pas ce qu’ils cherchent. Et si ça se trouve, ils trouveront des trucs qui leur laisseront penser que tu es coupable de X, quand bien même ce n’est pas le cas. Bon courage pour te démerder ensuite avec ça.
Et pour les charges supplémentaires, laisse moi rigoler. « M. le juge, je suis bien désolé, j’ai oublié mon mot de passe ». À part lire dans ton cerveau pour prouver que c’est faux, le juge aura bien du mal à te condamner pour quoi que ce soit, et certainement pas pour entrave.
Après, une fois que tu t’es concerté avec ton avocat, si effectivement il n’y a rien de compromettant sur le disque, et que c’est un moyen de prouver ton innocence, oui, tu pourras donner la clé. Mais si tu es effectivement coupable, que le disque est compromettant (ie, il contient tous les épisodes de la série X qu’on te reproche d’avoir téléchargé), la réalité est que tu as tout intérêt à ne pas donner la clé : on ne pourra pas te condamner pour ça (et trouve moi une jurisprudence si tu veux affirmer le contraire, j’ai expliqué pourquoi l’article de loi ne pouvait s’appliquer), et les preuves ne pourront être retenues contre toi puisqu’elles n’existeront pas.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Point sécurité.
Posté par whity . En réponse à la dépêche Se passer de Dropbox en montant son coffre-fort numérique à la maison. Évalué à 3.
Sauf qu’on ne peut pas t’obliger à fournir des preuves contre toi-même. C’est un droit fondamental de la défense, celui de garder le silence.
Ton article s’appliquera en revanche si la justice a besoin des informations contre un tiers (ce qui est une bonne raison de ne pas faire confiance à un système tiers qui détiendrait la clé de chiffrement).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Point sécurité.
Posté par whity . En réponse à la dépêche Se passer de Dropbox en montant son coffre-fort numérique à la maison. Évalué à 1.
Tu as le droit de refuser de la lui donner. Le juge pourra te le reprocher, mais pas te condamner pour ça.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un langage complexe ?
Posté par whity . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 1.
Deux problèmes (vécus) des GCs :
- la latence : l’exécution du GC freeze le programme, dans certains contextes ce n’est pas acceptable
- l’occupation mémoire et la cohabitation avec du code non garbage collecté. Certains GC ont une fâcheuse tendance à ne libérer la mémoire que quand il n’y en a plus, ce qui pose problème dans le cas d’un environnement hybride (typiquement, asp.net avec appel de code non managé) --> si le malloc qui échoue est dans le code managé, le GC se lance, s’il est dans le code non-managé, le GC ne se lance pas, et le code non managé n’aura jamais accès à la mémoire qui lui manque. Après, ce problème pourrait se résoudre par l’utilisation de process séparés, comme tu le préconises, mais cela a un coût. Dans un contexte serveur, le coût d’exécution, c’est de l’argent.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un langage complexe ?
Posté par whity . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Il y a plein de bouts dans les jeux vidéos qui sont faits dans des langages garbage collectés (c#, python, scripts divers), sur des parties non critiques.
Bien sûr, ça ne concerne généralement pas le moteur graphique quand on veut de la perf à tout prix.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par whity . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 0.
Sauf qu’en fait, non.
Il y a utilisation de l’opérateur d’incrémentation postfixé à chaque itération de la boucle, donc une copie en plus. Certes, ça fait que 8 octets l’itérateur, mais c’est une copie en plus à chaque itération de la boucle. Tout ça pour virer 1 test --> FAIL.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par whity . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 4.
En fait, la différence est dans la manière dont se fait l’appel à la fonction de comparaison. Avec qsort() en C, on passe par un pointeur de fonction. Avec std::sort, le compilateur va générer l’ensemble du code de tri, spécialisé pour la fonction de tri donnée. L’empreinte mémoire sera un peu plus grosse, mais en revanche on se passe du pointeur de fonction, l’appel au comparateur est plus rapide, au final on est gagnant.
Et C n’offre pas d’alternative autre que de réécrire l’algo spécialisé pour le type en question pour avoir les mêmes perfs. En C++, c’est le compilateru qui le fait pour toi.
De la même manière, une bibliothèque comme ublas (calcul matriciel) met une branlée à toute bibliothèque C pour toutes les opérations non spécialisées dans les libs C, grâce à l’utilisation d’expression templates.
J’avais lu un comparatif assez intéressant, je crois fait par les devs de scala au départ, sur les perfs entre C++, Scala, Java (je crois qu’il y avait un autre langage mais je ne me souvient plus lequel, peut-être go). La conclusion qui en ressortait était que le programme « naïf » écrit en C++ était plus lent que celui écrit naïvement en scala, et qu’après optimisations ils étaient à peu près équivalent. Ensuite, ils ont donné le programme à un gourou C++ (un vrai), qui a fait de vraies optimisations de gourou, et là les perfs étaient quelque chose comme 20% meilleures, quelque chose qu’ils n’ont jamais pu atteindre en scala. Par contre les optimisations en question étaient très loin d’être à la portée du dev moyen.
Quelques raisons :
- la liste vide pas gérée, et c’est pas précisé (un connard va copier/coller le code et l’utiliser ailleurs)
- le goto est un nid à emmerdes, j’aime pouvoir faire un "grep goto *" et que ça soit vide
- tu optimises au mauvais endroit. Tu supprimes un test, alors que la première chose à faire, c’est d’optimiser l’allocation mémoire au moyen d’un reserve()
- dans le même genre, je fais mal aux mouches mais tu concatènes avec ";" alors qu’il serait plus efficace de concaténer ';'
Donc en gros, tu micro-optimises, mais mal, et donc tu complexifies la lecture du code pour un gain négligeable. Je préfère largement voir dans le code :
std::string foo = boost::algorithm::join(bar, ";");
qui prend une ligne à écrire, et fait ce que tu veux de manière largement assez efficace (c’est à dire, vraisemblablement autant que ta version « optimisée ») partout où ce n’est pas nécessaire de faire mieux.
Cela dit, si le sujet de la micro-optimisation en C++ t’intéresse, je t’invite à regarder les conf’ d’Alexandrescu, c’est hyper technique et hyper intéressant de ce point de vue.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
# Et l’ABI, c’est du poulet ?
Posté par whity . En réponse à la dépêche Gestion sémantique de version. Évalué à 4.
Pas un mot sur l’ABI, alors qu’on parle de rétrocompatibilité, c’est un gros lol.
Il est au courant, le monsieur, qu’on peut :
- casser l’API sans casser l’ABI
- casser l’ABI sans casser l’API
- casser les deux à la fois
- préserver les deux à la fois
Bon courage pour faire un schéma de versioning qui fasse la différence (car elle est ultra-importante) avec seulement 3 chiffres…
Et sinon, +1 à tous ceux qui ont déclaré que c’était déjà majoritairement utilisé dans les projets qui ne différencient pas ABI/API. Rien de bien nouveau.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Linux power!
Posté par whity . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 2.
De manière générale, sous windows il vaut mieux utiliser les APIs W chaque fois qu’il y a le choix, et travailler en wchar_t (LPCWSTR si mes souvenirs sont bons). Attention toutefois à ne pas confondre deux choses dans le cas présent :
- les APIs unicodes (finissant en W)
- les « long path », commençant par \?.
Le deuxième n’est effectivement utilisable qu’avec les APIs unicode, mais utiliser les APIs unicode avec des chemins « standard » n’affranchit pas de la limite à MAX_PATH caractères.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Linux power!
Posté par whity . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 6.
Ça tombe bien, NTFS est case-sensitive. C’est l’api windows qui s’occupe de faire la traduction (de même pour les noms de fichier 8.3, etc). Et c’est très possible de passer outre, en utilisant les APIs adaptées.
Je crois que FAT32 sous linux peut l’être aussi (case-sensitive). D’ailleurs, fondamentalement, un chemin n’est pas vraiment une « chaîne de caractères », c’est plutôt une suite d’octets sans signification particulière, et surtout sans notion d’encodage (donc fatalement, ça ne peut pas être insensible à la casse, notion qui n’existe pas à son niveau). Ça pose notamment plein de problèmes amusants quand cette suite d’octet est invalide dans l’encodage par défaut du système (ceux qui ont migré une machine du latin1 vers l’utf-8 doivent savoir de quoi je parle).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: LightZone
Posté par whity . En réponse à la dépêche Darktable : entrevue avec Johannes Hanika. Évalué à 1.
Je ne connais pas LightZone. En revanche, je connais pas trop mal Darktable, pour l’utiliser régulièrement.
Peux-tu détailler un peu les points qui te font dire que Lightzone est beaucoup plus simple à utiliser que Darktable ?
J’ai l’impression que c’est principalement quelques détails d’interface qui feraient la différence, mais le diable se cache effectivement dans les détails.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: négatif numérique
Posté par whity . En réponse à la dépêche Darktable : entrevue avec Johannes Hanika. Évalué à 9.
Abusivement, on parle de « négatif » pour le fichier RAW (c’est à dire le fichier « brut de capteur », sans aucun post-traitement).
Darktable est un outil dédié au traitement de ces fichiers raw.
Sinon, pour répondre au commentaire du dessus, darktable est « non-destructif », dans le sens où il ne modifie pas le fichier d’origine. Il n’y a pas de bouton « sauvegarder », mais il y a un bouton « exporter en jpeg ».
C’est un super logiciel de part ses capacités, mais il n’est pas « tout public ». Malgré sa relative simplicité d’utilisation, c’est un logiciel qui s’adresse avant tout à un public qui souhaite passer du temps à traiter ses photos pour en tirer le meilleur. La courbe d’apprentissage peut rebuter les moins motivés.
Il y a quand même de supers tutos dispos sur le net.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Une résistance, mais pas de combat.
Posté par whity . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
Raté, c’est pas systemd qui impose quoique ce soit, c’est gnome (et d’autres).
Les dev de gnome ont estimé que c’était plus simple pour eux d’utiliser les APIs de systemd plutôt que de se carrer la gestion de n systèmes différents, que ça réduisait leur quantité de code à maintenir, et qu’en plus, c’était plus modulaire car ça permettait à tous les systèmes d’être compatibles (du moins, dès qu’ils peuvent faire tourner dbus, ce qui est le cas de tous les systèmes sur lesquels gnome tourne), via des APIs de compatibilité, et pas seulement ceux que eux (gnome) maintenaient.
Au final, grâce à systemd, gnome devient théoriquement portable sur plus de systèmes :trollface:
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Eh ben...
Posté par whity . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Je crois que tu es passé à côté du propos.
Le propos, c’est que les outils de développement BeOS (api, etc) t’incitent très fortement (quasiment, forcent ?) à utiliser une architecture multithread, là où les outils de développement gtk / qt / win32 t’incitent plutôt à tout faire dans la mainloop du thread de la gui.
Et effectivement, régulièrement, des applis freezent, sous windows comme sous linux. Tu peux blâmer les développeurs, dire que ce sont des incompétents et qu’il y a tous les outils dont ils ont besoin. Ça te fera peut-être du bien, mais ça ne changera pas grand chose au final…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
C’est amusant. Tu préfères un opérateur ternaire et un single return à une structure if/then/else à return multiple. Là je dois avouer qu’à part une histoire de goût personnel, je ne vois vraiment rien qui favorise l’un ou l’autre (personnellement je préfère le return multiple, même avec ton indentation je ne suis vraiment pas fan du ternaire).
Sinon, le single return, en C, vient souvent avec la nécessité du nettoyage, qu’on ne veut pas dupliquer. C’est vilain et pas beau, heureusement C++ nous permet de nous en passer.
Dans tous les cas, comme tu l’as dit ailleurs, ce qui est le plus important, c’est avant tout de limiter la taille des fonctions.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 0.
Amusant que tu répondes ça. Pour moi ce code est aussi trivial que l’est la forme ruby que tu as donnée pour toi. Et la syntaxe des lambdas se comprend en deux minutes…
Cf la réponse de michel à propos de nommer le prédicat. Mais quitte à nommer, je préfère nommer la ligne entière : la lisibilité est nettement meilleure, pour tout le monde.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
Comme quoi, sur ce point au moins on est parfaitement d’accord.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 3.
Je vais te retourner la question. Que penses-tu de :
Cette structure est triviale en C++. Et elle se comprend très bien telle qu’elle (au moins aussi bien que ta structure ruby), et est concise.
Maintenant, replace la dans un contexte, à savoir, au milieu d’autres structure du même type, peut-être dans une boucle, bref. J’estime être pas mauvais en C++, je travaille avec quotidiennement, j’ai l’habitude d’en lire, et pourtant, quand j’écris du code, j’évite ce genre de trucs. Au final, la forme que je vais utiliser, c’est beaucoup plus :
Et pour l’implémentation de copy_even_numbers, qu’elle fasse une ligne ou 4 ne change finalement pas grand chose. Si j’opte au final pour la forme du std::copy_if, c’est parce que je sais qu’elle est plus efficace qu’une boucle naïve.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
Pour le coup, je préfère encore l’opérateur ternaire :). perl permet aussi ce genre de truc, et j’ai toujours trouvé ça affreux.
Après, il est clair que le langage qu’on a appris en premier (C dans mon cas) influe sur sa perception des choses.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.
J’ai trop vu cet argument appliqué à perl pour y accorder la moindre crédibilité. Le problème est que oui, une structure, ça s’assimile assez vite, mais souvent elle n’est pas seule. Et qu’à force, on se retrouve avec des choses qui sont peut-être lisibles pour un spécialiste, mais :
- je ne suis pas convaincu que ce soit plus lisible qu’une forme moins concise, même pour le spécialiste en question
- c’est clairement moins lisible pour un non-spécialiste
Encore une fois, tu vas largement au-delà de ce que j’ai dit. Je dis qu’une construction qui n’apporte que de la concision (on est donc à des années lumières de ce qu’apportent les templates en C++ ou la métaprogrammation) n’apporte pas forcément de la lisibilité. Que
réussit à être à la fois plus lisible et plus concis en toute circonstance, mais que
est en général inférieur en lisibilité à
En clair, je dis qu’utiliser des fonctions du langage super cool là où ça ne sert à rien relève du pédantisme plus que d’autre chose (là encore, cf perl pour voir à quoi ça mène). Après, chacun est libre de s’exprimer comme il veut, et chaque langage fait les choix qu’il veut. Et encore une fois, il faut faire preuve de mesure : l’excès, dans un sens ou dans un autre, n’est jamais bon.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 0.
Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas. Après, les goûts et les couleurs…
Tu tires des conclusions un peu trop rapides et va largement au-delà de ce que j’ai dit. Je dis qu’une construction, fut-elle « de base » dans le langage, plus concise mais dont la lecture n’est pas intuitive, ne fait pas forcément gagner en lisibilité au programme. L’exemple déjà donné de l’opérateur ternaire est assez pertinent, aussi.
Comme toujours sur un sujet subjectif comme la « lisibilité », je crois que c’est surtout vouloir établir une règle unique ou d’être trop rigide sur des principes qui pose problème. Beaucoup relève au final du contexte.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
Disons que j’évite l’emploi de formes trop littéraires (par analogie, trop spécifiques au langage) si je suis en train de rédiger une doc technique. Au final, je trouve ta comparaison très pertinente, même si on n’y voit pas la même chose :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 1.
Les choses ont pas mal évoluées depuis les dernières fois où j’avais regardé, mais :
De toute façon, il y a avant tout l’aspect Ada est certifié, approuvé, Rust non.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 3.
En fait on ne parle pas forcément de la même chose.
Je suis parfaitement d’accord que des constructions plus simple, comme :
sont nettement plus lisibles que :
Qui sont inutilement trop lourdes. Néanmoins, je n’ai jamais été convaincu par les raccourcis « artificiels », comme memcpy, substr, ou l’utilisation d’opérateurs dans tous les sens pour gagner 3 caractères.
Pour reprendre ton exemple :
Est peut-être clair pour toi qui connaît bien ruby, est indiscutablement plus concise, mais pour moi c’est incompréhensible au premier abord. J’ai besoin de réfléchir pour comprendre ce que ça fait, alors que la première forme que tu donnes est directement compréhensible.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: vendredi tout est permis
Posté par whity . En réponse à la dépêche Meteor 1.0. Évalué à 1.
Je vois ça comme un inconvénient l’aspect « plateforme ». AngularJS me plaît car il me laisse utiliser ce que je veux pour ma partie serveur (et donc, réutiliser une bonne partie de mon existant).
Après, tout est évidemment question de contexte. Mais de manière générale, l’aspect tout intégré est un frein à la réutilisation de composants.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0