Alors voilà l'idée générale : faire une sorte de recueil de jeux en C++ entièrement en console pour augmenter la facilité à lire le code, composé de plusieurs jeux (4 pour l'instant), dont le code serait facilement lisible par un débutant, qui serait une sorte "d'exemple de code" sur lequel s'appuyer.
En plus de cela, ce recueil me permettrait d'être "jugé" par des personnes expérimentées en C++, ne pas prendre de mauvaises habitudes, etc.
Si je poste ici, c'est avant tout afin d'augmenter la liste de jeux jouables. La seule condition : ces nouveaux jeux doivent être codable sans librairie externe (pas en fenêtre donc.)
Merci d'avance pour vos idées (moi je commence à être à cours) !
- Edité par Durza42 13 janvier 2021 à 15:04:26
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Je laisse à d'autre le soin de te taquiner avec using (dans un .cpp, je n'y prête pas attention personnellement), ou sur le fait que la génération de nombres aléatoires a changé en C++11 et elle est appelée à remplacer entièrement les approches traditionnelles.
J'ai mis à jour les fichiers selon une partie des conseils.
J'ai cependant quelques questions, doncvoici un compte rendu point par point :
- manque les includes
J'ai bien mis les includes dans recueil.cpp (lignes 17, 18, 19 et 20)
- utiliser using namespace std; est discutable
Pourquoi ? D'ailleurs, que fait exactement ce code ?
- pourquoi passer les paramètres par référence non constant ?
- pourquoi const dans les autres fonctions ?
J'ai changé ces deux choses (en ajoutant des const).
- "program" (anglais) ou "programme" (francais), mais pas "programe"
où ?
- plus generalement, le franglais, c'est bof. Je prefere tout en anglais
Si il doit être lu par des débutants, qui passent par ce topic, ce sont des français. Même si je suis d'accord avec toi, dans mes autres codes je met les commentaires en anglais.
- initialisation des variables avec des parenthèses, c'est une mauvaise pratique
Pourquoi ce cour demande de le faire dans ce cas ?
- utiliser srand/rand, c'est bof
J'ai changé aussi.
- ne déclare pas les variables a l'avance, mais que quand tu en as besoin
J'ai changé toutes celles que j'avais vu, mais j'en ai peut-être oublié.
- "+= 1" -> "++"
Je trouve += 1 plus clair, ++ est moche...
- pas de fonction main ?
Si, dans recueil.cpp (ligne 24)
- beaucoup de lignes vides, ca ne sert a rien de passer plusieurs lignes entre chaque fonction
Supprimées.
- netoit_ecran n'existe pas
Si : la fonction est à la ligne 102 de recueil.cpp, son propotype ligne 13 du même fichier.
- "unsigned int i" -> "std:size_t i" pour les indices des tableaux
Pourquoi ?
- beaucoup de tes boucles for pourraient peut être être remplacée par des algo standards
Que sont des "algos standards" ?
Merci beaucoup à tous les deux, n'hésitez pas à être violent et intransigeants avec mon code !
- Edité par Durza42 17 janvier 2021 à 14:35:36
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Le cours sur Zeste de Savoir est de bien meilleurs qualité ou le C++ Primer 5th edition. De Lippmann.
> Je trouve += 1 plus clair, ++ est moche...
C'est pourtant l'opérateur qui dédié à l'incrémentation. += ne fonctionne pas toujours non plus, par exemple les itérateurs sur les conteneurs associatifs ou les listes possèdent ++ et --, mais ni +=, ni -=.
> - netoit_ecran n'existe pas
> Si : la fonction est à la ligne 102 de recueil.cpp, son propotype ligne 13 du même fichier.
Même problème que dans le premier point. Les .h doivent contenir les prototypes pour que les .cpp puissent en avoir connaissance.
> - "unsigned int i" -> "std:size_t i" pour les indices des tableaux
> Pourquoi ?
Parce que c'est le type retourner par les fonctions size() des conteneurs de la stl.
> beaucoup de tes boucles for pourraient peut être être remplacée par des algo standards
> Que sont des "algos standards" ?
Merci beaucoup pour tes liens jo_link_noir, ils sont très clair.
Les using namespace std; ont étés supprimés.
Les variables sont initialisées avec =.
+= 1 a été remplacé par ++ (je croyais que les deux revenaient exactement au même).
unsigned int i a été remplacé par std::size_t
Par contre, il y a un point que je ne comprends pas : pourquoi ne faut-il pas inclure de .cpp ? Comment fait-on dans ce cas pour un fichier de 17 012 645 145 lignes ? Un seul fichier cpp serait un peut lourd... J'attendrai donc ta réponse pour modifier les includes
Les algos standards attendront cependant quelques jours (probablement jusqu'à mercredi), faute de temps...
Merci encore !
- Edité par Durza42 17 janvier 2021 à 16:39:22
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
>- initialisation des variables avec des parenthèses, c'est une mauvaise pratique
Je ne suis pas d'accord avec cette recommandation. Cela fait suite à une évolution du C++11 qui part d'une bonne intention mais qui reste un échec. Certes cela corrige un problème pour employer des constructions par défaut, mais les deux écritures restent nécessaires et non interchangeables dans certains cas: à commencer avec les conteneurs.
Tu coup je continue avec l'écriture (), et tend à réserver l'écriture {} quand intuitivement que je construis avec des séquences ou des agrégats.
> - "+= 1" -> "++" > Je trouve += 1 plus clair, ++ est moche...
Question d'habitude. Perso, je trouve '+= 1' plus lourd et plus risqué (un 1 peut vite devenir un 2 ou un 0 avec une mauvaise transformation du code source). Il y a aussi les limitations exprimées par jo_link_noir.
Mais plus important: quand je vois '++', je subvocalise 'passe au suivant', alors qu'avec '+= 1', je subvocalise 'augmente de 1'. Sémantiquement cela ne revient pas au même.
PS: le langage que l'on manipule ici est le C++, pas le C+=1. Une vieille boutade est qu'il aurait été plus juste de l'appeler ++C vu que c'est la forme à préférer sur les itérateurs. Mais vu que c'est bien un nouveau langage, la forme post-fix est plus juste
En C++20, il n'y a presque plus de différence entre () et {}, les 2 sont interchangeable dans la majorité des cas, même les agrégats !
Les différences qu'il reste:
MVP
Paramètre nommé pour les agrégats avec {} (c++20)
les conversions avec perte ne sont pas vérifiées avec ()
Priorisation de std::initializer_list (de mon point de vue, c'est lui qui contribue à l'échec de {})
Pas de construction implicite avec () (foo({1,2}) vs foo((1,2)))
> Par contre, il y a un point que je ne comprends pas : pourquoi ne faut-il pas inclure de .cpp ? Comment fait-on dans ce cas pour un fichier de 17 012 645 145 lignes ? Un seul fichier cpp serait un peut lourd... J'attendrai donc ta réponse pour modifier les includes
On compile les .cpp séparément et on link les .o ensemble.
Si il doit être lu par des débutants, qui passent par ce topic, ce sont des français. Même si je suis d'accord avec toi, dans mes autres codes je met les commentaires en anglais.
C'est mal barré car l'informatique C'EST en Anglais. La syntaxe du langage, la plupart des ressources officielles, les noms de fonctions, objets, classes dans les APIs, bref tôt où tard si on est pas bon en Anglais il faudra s'y mettre si possible avant de développer alors autant écrire en anglais tout le temps (code + commentaires + commit log SCM).
Moi je rajouterais quelques notes :
Passer des primitifs en constant en argument de fonction c'est sujet à discussion, pour ma part j'ai un peu du mal avec ce concept car parfois ça peut être utile de manipuler directement une variable en entrée pour ne pas en déclarer d'autre. C'est assez peu commun de prendre des primitif ou variables par valeur const.
mastermind.cpp, tu peux largement ruser ce gros switch avec juste une petite soustraction de la table ASCII.
C'est quoi cette horreur de variable en dur ? Si tu veux piocher un mot au hasard dans un fichier rangé par ligne, tu charges tout dans un vector (avec std::getline) puis tu retourne un mot du tableau entre 0 et size() - 1. Le dico.close() est inutile aussi.
- Edité par markand 17 janvier 2021 à 19:37:50
git is great because Linus did it, mercurial is better because he didn't.
> On compile les .cpp séparément et on link les .o ensemble.
Comment faire dans ce cas si un fichier cpp à besoin d'une fonction écrite dans un autre fichier cpp (typiquement avec les class, où l'on a un fichier .cpp par class) ? Il ne compilera pas, si ?
D'ailleurs, tu as répondu au comment, mais je n'ai toujours pas compris pourquoi.
Je vais changer prochainement les fichiers comme indiqué par markland (il y a du travail...)
- Edité par Durza42 18 janvier 2021 à 18:47:56
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
> C'est assez peu commun de prendre des primitif ou variables par valeur const.
Je définis de plus en plus souvent des variables comme non modifiables. Pour un paramètre formel, au niveau dans la définition de fonction, c'est pareil.
> On compile les .cpp séparément et on link les .o ensemble.
Comment faire dans ce cas si un fichier cpp à besoin d'une fonction écrite dans un autre fichier cpp (typiquement avec les class, où l'on a un fichier .cpp par class) ? Il ne compilera pas, si ?
C'est exactement là qu'intervient la différence entre compiler et l'édition des liens. Quand tu compiles juste un fichier .c; cela le traduit en code objet machine, s'il y a des références externes elles ne sont pas encore prises en compte il faut juste que le code soit valide et donc à minima avoir des déclarations. C'est au moment de créer l'exécutable final que le linker va résoudre tous les symbols externes.
git is great because Linus did it, mercurial is better because he didn't.
J'ai changé le switch indiqué par une simple soustraction de la table ascii.
Je suis là maintenant tout de suite en train de corriger la "variable en dur" et les includes.
--------------------
Edit : c'est fait (mais vous trouverez sans aucun doute quelque chose à redire )
- Edité par Durza42 21 janvier 2021 à 14:06:09
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Je redemande des précisions sur les includes : pourquoi est-il déconseillé d'inclure une fichier .cpp ? Est-ce pareil avec les .c ?
Bref, je pense qu'il est maintenant raisonnable de demander des idées de jeux !
- Edité par Durza42 23 janvier 2021 à 17:35:23
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Parce que ce n'est pas le rôle des .cpp d'être inclu.
Ce n'est pas une obligation absolue, mais dans le processus de comment les codes C++ (et C) sont compilés, il y a le code qui doit être compilé (= transformé en binaire exécutable) et le code qui doit être simplement utilisé par d'autres codes.
Par convention, on met le code à compiler dans les .c ou .cpp et les code a inclure dans les .h et .hpp.
Tu pourrais en théorie tout mettre dans des .txt ou ce que tu veux, mais ça serait la pire idée du monde.
Cela fait partie de l'apprentissage du C++ d'apprendre a décomposer son code entre la partie a compiler ou non (organisation logique du code) et dans quels fichiers tu mets ces codes (organisation physique du code).
La grande majorité des devs sérieux vont considérer que c'est un bug de ton code si tu ne respectes pas les usages d'un langage sans raison.
Il me semble que tu es débutant, et qu'il te manque une subtilité dans la philosophie du développement informatique. (Si c'est pas le cas, ne lit pas !)
Durza 42 a écrit:
Je redemande des précisions sur les includes : pourquoi est-il déconseillé d'inclure une fichier .cpp ? Est-ce pareil avec les .c ?
Quand tu veux faire un logiciel de taille raisonnable (C’est-à-dire "un gros logiciel", qui fait plein de chose avec une superbe GUI, et tout et tout), tu n'as pas le choix : tu ne peux pas tout faire de façon monolithique, en une seule fois, dans un seul fichier, il faut couper en plusieurs morceaux ! ("Diviser pour mieux régner !")
Donc, tu fais plein de petit fichier en C++ (ou en d'autre langage : C, ...). Avec ton compilateur, tu transformes tous tes fichiers en fichier "objet", et ensuite avec ton éditeur de lien (ou Linker) tu regroupes tous ces fichiers en un exécutable : Hop, tu peux l'utiliser ! (C'est un peu plus compliqué que ça, mais c'est une première approche.)
Cependant, "tous tes petits fichiers", il faut qu'ils se comprennent ! Si un fichier met à disposition un service, il faut que ceux qui vont utiliser ce service sachent quel est la syntax à appliquer pour pouvoir l'utiliser ! C'est le but des "déclarations" ! Avant de pouvoir utiliser une procédure ou un objet, il faut le déclarer, c'est à dire définir sa syntaxe. C'est le but des fichiers "header" (c'est à dire, "en tête", les fichiers *.H ou *.HPP). On déclare dans le fichier "header" associé, la syntaxe de tous les services rendus dans un fichier CPP (ou C), et on inclut ce fichier "header" dans chaque fichier CPP (ou C) qui utilise ce service.
Les fichiers de "header" ne sont utilisés que par le compilateur, pour synchroniser les fichiers CPP ou C. (C'est un peu plus compliquer que ça, mais c'est la premièer approche!)
Une fois que tu as tout compilé, le Linker remet ensemble tous les fichiers objets, et donne les vrais adresses à chaque service (procédures, Objets, ...) à la fois pour les appelants que pour les appelés.
Quand on à dit ça, on revient à ta question: Pourquoi on n'inclus pas les CPP ?
L'instruction "#include <nom de fichier>" permet au compilateur de reconstistuer un "gros fichier" en concaténant tous les fichiers inclus avant de les traiter. Quand tu inclues quelques fichiers HPP ou H, tu fais grossir la taille du "gros fichier" qui sera avaler par le compilateur. Mais comme tu le sais sûrement, c'est un procéssus récursif (les fichiers qui sont inclus peuvent inclure des fichiers, et ainsi de suite), et suivant ces fichiers (en particulier, ceux des librairie), ce "gros fichier" est véritablement ... Gros, ENORME ! Plus tu rajoutes d'Include, plus il grossit ! (Il y a quelques années, on pouvait même arriver aux limites du compilateur et se son ordinateur !)
Donc l'objectif, c'est de ne compiler qu'un fichier CPP (ou C) à la fois, mais de laisser, à la fin, au linker le travail de remettre tout ensemble.
Si tu fais des "#include <Fichier>.CPP", tu vas mettre à la suite plusieurs fichier CPP pour les faire avaler par le compilateur, en une seule fois ! Ca revient à demander au compilateur de concaténer dans un seul fichier objet le résultat de plusieurs fichiers CPP, donc de commencer à faire le travail du linker !
Il en découle :
Risque de saturation du compilateur (voir ci dessus)
Tu n'est plus libre de choisir le source du service appelé (c'est forcément celui du fichier CPP qui est inclus)
Risque de duplication du même composant dans 2 fichiers objets (si tu a inclus un même fichier dans deux fichiers qui seront compilés), et là, le liker il sort une erreur, il ne sait pas résoudre les addresses de deux composant qui on le même nom.
Grosse dificulté pour faire des tests unitaires et d'intégrations
...
J'espère qu je suis clair, si c'est pas le cas, n'hesite pas à demander des explications.
- pourquoi passer les paramètres par référence non constant ? pourquoi const dans les autres fonctions ?
La cohérence a été rétablie
- "program" (anglais) ou "programme" (francais), mais pas "programe". Plus generalement, le franglais, c'est bof. Je prefere tout en anglais
La traduction est encore en cours...
- initialisation des variables avec des parenthèses, c'est une mauvaise pratique
Changé.
- utiliser srand/rand, c'est bof
Changé.
- ne déclare pas les variables a l'avance, mais que quand tu en as besoin
Je crois l'avoir correctement fait.
- "+= 1" -> "++"
Changé.
- pas de fonction main ?
Dans recueil.cpp (au départ j'avais mis un fichier "prélinké" (sans faire exprès), c'était forcément un peu brouillon).
- beaucoup de lignes vides, ca ne sert a rien de passer plusieurs lignes entre chaque fonction
Enlevées
- netoit_ecran n'existe pas
Dans recueil.cpp (au départ j'avais mis un fichier "prélinké" (sans faire exprès), c'était forcément un peu brouillon).
- "unsigned int i" -> "std:size_t i" pour les indices des tableaux
C'est fait, mais j'aurais cependant quand même une question là dessus : à quoi correspond exactement le type size_t ? est-ce celui utilisé dans tous les indices de tableaux, ou seulement celui renvoyé par string.size () ?
- beaucoup de tes boucles for pourraient peut être être remplacée par des algo standards
Cela par contre est encore à voir. Il faut que je prenne mon courage à deux main et que je m'y mette.
Pour un dernier mot sur les includes, je pensait que les .h avaient besoin d'un .cpp pour les prototypes, et que sinon on m'afficherait une erreur comme "undefine referance to..." car il ne trouverait pas la fonction. Mais quand on y réfléchit, sinon les .h auraient tout à fait pu être des .cpp !
Merci encore à tous !
PS : auriez-vous d''autres idées de jeu ?
- Edité par Durza42 24 janvier 2021 à 15:57:24
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Pour un dernier mot sur les includes, je pensait que les .h avaient besoin d'un .cpp pour les prototypes, et que sinon on m'afficherait une erreur comme "undefine referance to..." car il ne trouverait pas la fonction. Mais quand on y réfléchit, sinon les .h auraient tout à fait pu être des .cpp !
J'ai quelques difficultés à comprendre ce que tu veux dire :
Les fonctions/objets sont codés dans les fichiers CPP. Leur prototypes se trouvent dans les fichiers "header" (H ou HPP). Généralement ont fait un fichier de header par fichier CPP (mais c'est pas du tout une obligation). [tu semble dire le contraire]
Maintenant, quand dans un fichier CPP, il est utilisé une procédure, un objet (ou un type) qui n'est pas codé dans ce fichier, il faut inclure le fichier "header" qui le déclare. Si on ne le fait pas, on a une erreur comme "undefine referance to...", car en effet, le compilateur ne connait pas la syntaxe de cette procédure/objet.
J'ai beau réfléchir, mais non, les fichiers H ne peuvent pas être des CPP, c'est pas la même chose ! [De façon simplifié, c'est pas toujours le cas] Quand le compilateur "passe" sur un fichier "header", il retient des syntaxe, des types, ... mais il ne génére pas de code. Inversement, quand le compilateur passe sur le fichier CPP, c'est là qu'il génére le code. [C'est pas rigouresement exacte, mais c'est l'idée]. Donc, on ne peut pas les inverser! il n'ont pas le même but!
- "unsigned int i" -> "std:size_t i" pour les indices des tableaux
C'est fait, mais j'aurais cependant quand même une question là dessus : à quoi correspond exactement le type size_t ? est-ce celui utilisé dans tous les indices de tableaux, ou seulement celui renvoyé par string.size () ?
En fait, size_t est littéralement l'abréviation de size (merci, ce mot est entier :D) et de _type. c'est à dire, n'importe quelle taille susceptible d'être représentée sur ton système.
On sait que ce sera de toutes manières un entier (int, long ou long long) parce qu'il est impossible d'avoir une taille avec une décimale (ex:1.5) et qu'il sera -- a priori -- non signé, car une taille négative n'a absolument aucun sens.
On peut raisonnablement partir du principe que toutes les fonctions membre size() vont renvoyer le même type pour size_t (qu'elles vont, systématiquement utiliser un alias de type basé sur std::size_t).
Mais, en fait, on s'en fout royalement, car, maintenant que l'on a le moyen de déterminer automatiquement le type d'une donnée (grâce au mot clé auto), les type renvoyé par les différentes fonctions membres size() pourraient tout aussi bien être différents, cela ne changerait plus rien pour nous (vu que l'on n'a plus à fournir le type réel pour que cela fonctionne)
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
@dedeun Ce que je voulais dire, c'est que tu peux en soit copier-coller le contenu du .h en du .cpp, comme par exemple :
#include <iostream>
int triple (int value);
int main () {
std::cout << triple () std::endl;
return 0;
}
int triple (int value) {
return value * 3;
}
où
int triple (int value);
Pourrais être dans un autre .cpp sans ce que vous avez expliqué dans vos précédents posts, en ajoutant #include "ficher.cpp". Pour moi, les deux revenaient exactement au même (un peu comme ++ et +=1). Mais j'avais tord, et j'ai compris grâce à vous.
- Edité par Durza42 27 janvier 2021 à 14:49:46
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
recueil de code C++
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Discord NaN. Mon site.
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
git is great because Linus did it, mercurial is better because he didn't.
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
git is great because Linus did it, mercurial is better because he didn't.
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
git is great because Linus did it, mercurial is better because he didn't.
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
Discord NaN. Mon site.
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".
La gentillesse est le langage qu'un sourd peut entendre et qu'un aveugle peut voir.
Il n'y a qu'un seul monde et il est faux, cruel, contradictoire, séduisant et dépourvu de sens. Un monde ainsi constitué est le monde réel. Nous avons besoin de mensonges pour conquérir cette réalité, cette "vérité".