Clément V a écrit 90 commentaires

Perso je l'utilise par exemple suivant si l'utilisateur veut une version Unicode ou pas de ma lib, utile à une époque même si moins de nos jours, je ne vois pas comment proposer ça simplement avec les modules, à part faire comme Java par avoir les 2 interfaces pour tous et limiter la taille du bousin est un truc que j'aime en C++ justement).

Si j'ai bien compris, tu as toujours le droit d'utiliser des #ifdef, mais les defines sont limités au module qui en a besoin. Plus besoin d'ajouter un -DZENITRAM_UNICODE pour la compilation de tous les fichiers qui pourraient inclure directement ou indirectement tes headers. Le revers c'est que les modules ne peuvent plus exporter de macros.

Une fonctionnalité nécessaire pour devenir le meilleur éditeur de texte (aussi appelé vim).

Plus précisément, une façon très pratique de sélectionner des bouts de textes.

Non, Perl (source : https://xkcd.com/224/).

Je ne savais que la règle avait changé. C'est quand même étrange de voir = comme un point de séquence.

Mais là -std=c++11 est passé au deux compilateurs, donc on est bien dans un cas où l'ordre est indéfini, non ?

m[1] = m.size();

L'ordre entre m[1] et m.size() n'est pas déterminé. operator= est exécuté en dernier mais ce n'est pas lui qui ajoute l'élément, c'est m[1].

En effet, l'intérêt est limité. Mais il faut aussi se poser la question dans l'autre sens : quels sont les désavantages des fonctions curryfiées et quels sont les avantages des fonctions prenant un tuple de tous les arguments en même temps ?

J'en vois assez peu. Le principal, comme le montre l'existence de ce fil, c'est que ça perturbe ceux qui ne connaissent pas. Donc dans la plupart des langages, les fonctions curryfiées sont à éviter sauf quand c'est vraiment utile. Mais dans les langages dans lesquels c'est idiomatique (comme le Haskell ou d'autres langages fonctionnels), ça ne coûte rien de curryfier par défaut et de n'utiliser les tuples seulement quand c'est vraiment nécessaire.

Je rappelle aussi qu'en maths, une fonction associe à chaque élément d'un domaine un élément du codomaine. Si on veut passer plusieurs paramètres, le domaine est un ensemble produit et on doit créer un tuple pour passer les paramètres. Dans beaucoup de langages ce n'est pas un problème, mais j'imagine que pour un langage très matheux comme Haskell c'est une source de complexité supplémentaire (en pratique on devra écrire add (a,b) au lieu de add a b, c'est un peu plus lourd mais ça reste acceptable, la principale raison reste idiomatique).

Avec une syntaxe assez simple, il serait possible de faire la même chose: si _ est un argument a remplir plus tard, il est possible de faire f(x, _ , y).

Il y a des langages qui proposent ce genre de syntaxe ? Est-ce que c'est vraiment plus clair qu'une syntaxe du genre z => f(x, z, y).

Je ne comprends pas pourquoi les formes curryfiées seraient nécessaires pour avoir des fonctions pures. Une fonction de type A × B → C peut tout autant être pure que A → B → C.

Pour moi, l'intérêt des fonctions curryfiées était avant tout l'application partielle.

---

Pour la lecture, une fois qu'on me l'a expliqué, ça ne m'a jamais dérangé. Le prérequis important me semble de savoir dans quel ordre les flèches doivent être lues (elles ne sont pas associatives).
A → B → C est A → (B → C) et non (A → B) → C. Le type du retour est donc derrière la dernière flèche, les autres flèches séparent les arguments dans l'ordre dans lequel on doit les donner. Si on veut retourner plusieurs objets, on est obligé d'utiliser un produit : A → B × C.

Le vrai mathématicien: 1 faux, c'est donc absolument faux.

J'avais bien compris ça, mais c'est étrange comme nom quand on y pense. Yoda dirait plutôt "valeur" mavar == ("À valeur ma variable est égale"), non ?

En lisant quelques commentaires au hasard sur le post reddit. J'y ai vu quelques arguments en faveur de la simplicité plus convaincant que le nombre de transistors. Je retiens surtout (bien que je n'ai pas les connaissances techniques pour les confirmer) :

• Les transistors plus petits des CPUs modernes ont une durée de vie limitée. Quelques décennies après la fin de la fabrication, ils cesseront de fonctionner.
• Les circuits autour des CPUs anciens sont plus simples. Il y donc plus facile de trouver et remplacer les composants défectueux ou de les modifier pour changer l'utilisation de l'appareil.

Ça veut dire qu'on se place dans un scénario où on est incapable de produire de l'électronique complexe pendant une très longue période, tout en continuant à produire des composants plus simples pour créer ou réparer des cartes autour de ces z80/6502 increvables. J'ai du mal à y croire : au bout d'un moment, soit tu arrêtes l'électronique, soit tu relances l'usine de circuits intégrés.

Mais ça reste des questions intéressantes sur la durée de vie de l'électronique et sa réutilisation.

J'ai du mal avec l'argument de la simplicité : 9000 transistors, c'est peu mais ça reste quelque chose que j'imagine mal fabriquer avec mes petites mains. Donc ce qui compte c'est ce qui est le plus répandu. Est-ce que l'ARM ne battrait pas le Z80 avec l’inondation de smart-phones autre périphériques « intelligents » ?

Si on prends les valeurs à la source, ça marche. La faute est dans la valeur de x du journal (8 866 128 9 8 5 287 528).

x=int("8866128975287528")
y=int("-8778405442862239")
z=int("-2736111468807040")
pow(x,3)+pow(y,3)+pow(z,3)

donne 33.

Ceux qui jouent à DF ne devraient pas installer ce mods parce que ça risque de leur dévoiler une partie des surprises.

Quelles surprises ? Celles que les joueurs de DF connaissent déjà ? Rien ne sera dévoiler dans ce cas. Je ne comprends pas cet avertissement.

En fait, ça doit être mieux comme ça :

for (auto &[k, v]: d)
    std::swap(v.first, v.second);

Et en python, on ne peut pas modifier directement la paire ?

d[it.first]

Tu fais une recherche dans la map à chaque itération. C'est inutilement complexe. Tu devrais utiliser l'itérateur directement.

En C++ moderne, c'est :

for (auto &[k, v]: d)
    v = {v.second, v.first};

Bradley Kuhn (SFC) ne semble pas très enthousiaste. Les conditions pour qu'un brevet soit concerné par l'OIN semblent trop stricts. Il cite l'exemple de l'exFAT qui ne serait pas à l'abri d'attaques tant que Microsoft ne l'aura pas intégré à Linux.

Par exemple si j'écris 2 fois la ligne

memoized<prime_sieve, uint64_t, 0,1,2,3,4,5,6,7,8,90> ps1;
memoized<prime_sieve, uint64_t, 0,1,2,3,4,5,6,7,8,90> ps2;

Est-ce qu'il va stocker 2 fois les résultats? Si ces lignes sont dans 2 librairies différentes, que ce passe t-il? (bien sûr qu'il va stocker 2 fois les résultats… )

Le cache est statique, c'est donc la même variable partagée par tous les appels à une même fonction. Dans le cas où les types memoized sont identiques, le cache n'est pas recalculé. Mais si les types sont différents, les fonctions sont différentes, et donc, même avec des valeurs communes, le cache est complètement recalculé :

memoized<prime_sieve, uint64_t, 0,1,2,3,4,5,6,7,8,90> ps1;
memoized<prime_sieve, uint64_t, 0,1,2,3,4,5,6,7,8,90,91> ps2;

ne partagent pas le même cache.

Pour garder un exemple dans le style du journal, mais où on sait ce que font les fonctions : https://gcc.godbolt.org/z/2llMlg

C::f et C::g garde toutes les deux une copie du pointeur, mais f prend par référence et g par valeur. C::h prend possession du pointeur passé par référence de rvalue.

• c.f(ptr_A) : le pointeur passé par référence puis copié dans la fonction -> 1 copie.
• c.f(ptr_B) : le pointeur est converti, puis le temporaire est passé par référence, copié et détruit -> 2 copies, 1 destruction.
• c.g(ptr_A) : le paramètre est crée par le constructeur de copie puis est déplacé par la fonction -> 1 copie, 1 déplacement, 1 destruction d'un pointeur nul (moins cher).
• c.g(ptr_B) : pareil que le précédent sauf que le constructeur de copie est remplacé par la conversion.
• c.h(std::move(ptr_A)) : passage par référence, puis affectation -> 1 déplacement.
• c.h(std::move(ptr_B)) : conversion, passage par référence, puis affectation -> 2 déplacement, 1 destruction d'un pointeur nul.

J'espère que c'est plus clair. Le passage par référence nécessite une copie supplémentaire pour la conversion, alors que le passage par valeur permet de limiter à une seule copie dans tous les cas.

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

Mais une référence de type A dans ce cas, la référence vers un shared_ptr ne garantie pas que le pointeur lui-même est déréférençable.

Les trois premiers appels se contentent de passer un pointeur (une référence c'est pointeur caché) et sont donc aussi rapides l'un que l'autre. g(shr_b) a besoin de créer un temporaire de type shared_ptr<A> et une copie de shared_ptr est coûteuse à cause de l'état partagé.

En pratique, si g n'a pas besoin de posséder la ressource, il faut mieux utiliser pointeur nu ou un weak_ptr. Si g a besoin de la posséder, il faut mieux passer le shared_ptr par valeur: il y a une copie au moment de l'appel dans tous les cas, mais on peut le déplacer par le suite si besoin.

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.

Ce qui m'arrive le plus souvent c'est les conflits entre membre et accesseur, et là, le this-> ne résout rien. Il faut donc un préfixe/suffixe soit pour le membre, soit pour l'accesseur (e.g. utiliser get_membre). Je préfère garder un joli nom pour l'accesseur et mettre un préfixe à mon membre privé.

Mais nullptr et adresse 0 à ne sont ils pas différents ? L'implémentation peut utiliser la valeur qu'elle veut pour nullptr. Si je fais de la programmation bas niveau et que j'ai besoin d’accéder à des adresses particulières, je dois m'assurer que celle-ci n'est pas la valeur choisie pour nullptr ? Dans mes souvenirs de programmation sur ma calculatrice, on trouvait le vecteur d'interruption à cette adresse, et on pouvait le réécrire vu qu'il n'y avait pas de protection mémoire.

clang refuse d'appeler l'adresse 0 même avec

int main() {
  return reinterpret_cast<Function>(0)();
}

Il y a quelque chose dans le standard qui interdit l'adresse 0 ? Ou c'est la plateforme x86_64 pour laquelle c'est toujours invalide qui permet l'optimisation ?

Ça semble être celle-ci : http://www.news.va/en/news/pope-francis-mercy-friday-visit-to-ostia-housing-p d'après une rapide recherche du titre. Mais c'est vrai que ça aurait été mieux de mettre le lien dans l'article.

À voir comment cela fonctionnerais sur une tablette (la description sur GitHub indique que ça peu fonctionner hors ligne.

J'ai un forfait données minimal et je préférerais aussi pouvoir l'utiliser hors-ligne mais ce n'est pas très clair dans les préférences. Je ne vois qu'un réglage de la taille du cache. Comment être sûr que la zone qui m'intéresse est en cache ?