sauf que sprintf a pour 1er argument un buffer, si tu utilise un buffer static avec un taille fix (et donc snprintf), tu peu pas savoir si ton buffer seras assez gros, si tu fait des malloc, c'est plus lourd et tu doit free, sinon tu fait des sizeof, t'a ton buffer qui a la bonne taille, et pas besoins du 'n' dans sprintf, puisque ton buffer auras la bonne taille.
ok, remplace le printf par un open, SDL_LoadBMP, Mix_LoadMUS…
genre t'a un dossier avec des assets, ou tu suit des pattern de nommages.
l’intérêt c'est comment j'utilise memcpy (plus opti que strcpy BTW)
Crée un buffer dans la mémoire automatique qui auras la taille exact de plusieurs strings.
pouvoir modifier la taille des strings dans mes defines sans avoir peur d'overflow.
int main(void)
{
return sizeof "wololo, ayoyoyo2";
}
program return 17
On va pas refaire le débats sur sizeof, ça marche dans certains cas, pas d'autres, et ça dépend de t'a définition de "c'est quoi la taille d'une string ?"
on voie que en go, si tu fait un '==' entre 2 chaine unicode, qui représente le même character, mais on des octet différent(ici "\u{00e9}" et "\u{0065}\u{0301}"), go retourne true.
ce qui veut dire que le '==' de go, est plus complex qu'un comparaison octet à octet.
C'est surement très pratique dans plein d’application, mais si tu cherche de la perf, c'est moins performent.
Rien de tout ca dans un langage a runtime bloaté, évidemment
Et est-ce que t'a vraiment envie d'avoir une conversions de string par default, a chaque comparaison, quand tu recode un compilateur, qui auras 10M lignes de code à recompiler le plus rapidement possible ?
que tu recode git et manipule des repository de plusieurs Millions de commits ?
que t'est sur de l'embarqué et que chaque instruction compte ?
En terme de perf, ça doit être magique.
Tout ça pour en revenir à mon assertion de base: Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo, et tu viens de m'expliquer que C est mieux que go.
Bien sur, si tu choisie ton langages de programmation en ne fessant pas cette assertion, C n'est pas forcement mieux que go, mais qui ferais ça ?
Nope, nope, nope.
Ta methode te permet de connaitre la longueur d'une chaine ascii, et uniquement une chaine ascii. "Une string" n'est pas une chaine ascii.
Oui, mais une chaine ASCII est une string :p
Pour arréter le troll, c'est plutôt bien l'esprit de C, si t'a une string literal, tu utilise sizeof, si t'a chaine ascii(void UTF-8 dans certains cas) tu prend strlen, et si t'a de l'unicode, voila wcslen.
Et si tu veut un méthode qui gère tout, tu va galérer, mais si t'est bien avec ton programme qui a tout en static (un genre de sl (le train)?), bah tes sizeof seront très bien, et pas besoins de plus.
J'ai il me semble, pas parler de sécurité, ou de la complexité à éviter les bugs en C, j'ai juste parlé du standard C, pour être un petit con qui a raison, mais si j'ai raison dans des cas qui sont en pratique peu utilisable.
mais bon vu que tu passe de "strlen marche pas sur unicode" à "les terminaux sont en UTF-8" sur lesquels strlen marche donc ASCII, UTF-8 font pas grande différence vu que ls, curl, cat… eux utilise les function de la lib standard, je crois pas être le seul à avoir des arguments un peu bidon, limite malhonnête.
pretendre que sizeof permet de calculer la taille d'une chaine de caractère (ca ne marche QUE sur les chaines littérales dans le scope local, on peut pas vraiment dire que ca soit super utile)
Bah oui, tu a dit qu'il n'y a aucun moyen de calculer a temps constant de calculer la longueur d'une string, c'est factuellement faux, bien que la technique ne marche pas tout le temps.
passer sous silence le fait que si ton \0 manque (peut être parce que t'as utilise strlen et oublié de rajouter 1, par exemple), paf le buffer overflow
Effectivement j'ai pas parler de l'offset de 1, mais les 2 manières permettes de connaitre la longueur d'une string, chacune à leur avantages dans certaines conditions.
ne pas remarquer que strlen ne marche pas sorti de l'ascii
Bah oui, parce-que t'a pas beaucoup de programmes qui ont besoins de sortir de l'ASCII. (moi qui ne connais que le terminal n'en ai pas besoins)
passer sous silence le fait que si ton \0 manque (peut être parce que t'as utilise strlen et oublié de rajouter 1, par exemple), paf le buffer overflow
sauf que si t'a pas de \0, t'a pas une string au sens C du terme, donc c'est HS. (si tu fait un memset dans t'a std::string en C++, peu être que ça va pas bien marcher non plus).
Après j'ai jamais dit que C est un langage sécure, j'ai dit que la seul choses qui permet de noter la qualité d'un langage, c'est la capacité de ces développeur à recoder un compilateur.
Ce sur quoi:
la capacité à calculer la longueur de tes string est au final assez dérisoire.
Donc oui, sizeof retourne la taille d'une array, mais ça retourne aussi la taille d'une string, et c'est calculé a la compilation.
Et strlen("ma chaine de character"); c'est juste un code pas optimisée pour 0 raison.
Bien sur si on utilise des variable on doit utiliser strlen, mais si on utilise des variable et que la calcule de la longueur est important, autant utiliser une struct qui contiens la longueur de la string.
Aussi, rien qu'évoquer Rust est toxique maintenant ?
Vous êtes aisément vexés. Va falloir se calmer.
C'est vrais que je suis un peu partie vite, âpres, avoir quelqu'un qui viens te dire, "fait du Rust" dans chaque conversation qui parle de C, c'est une peu lourd.
Une peu comme si a chaque fois que tu évoque C# quelqu'un te tombe dessus parce-que "Grenieunieu Microsoft c'est mal".
Ou comme si dans caques conversation qui parle de Distro (GNU ?)Linux, y'a un con qui viens te parler d'Arch (GNU ?)Linux.
Dalleur, est ce que vous saviez que j'utilise Arch (GNU ?)Linux, et que ça marche vraiment très bien ?
ok, j'ai pas la blague, mais je voie vraiment pas le rapport avec les voyelles (tu veut dire accent ) ?
sizeof permet de connaître la taille d'une string à temps constant, ce que tu peu pas connaître en C, c'est la taille d'un char *(et "hello" est un char [6]).
ceci dit sizeof c'est du C, pas une partie de la libc.
Après il n'y a aucun langages "haut niveau"(C inclue) qui permet de connaître le temps d'accès à n'importe quel variable non plus. (vu que ton int peu être dans ton cache L1,L2, t'a ram, ton disk dur si t'a du swap, pas allouée du tout vu que Linux alloue de la mémoire sur les page fault par default sur x86…)
Donc l'argument de "tu peu pas faire un opération pas optimisée sur une structure de donnée pas optimisée", bon…
Ou utilise Rust/autre langage moderne de son choix, et arrêter avec…
C'est exactement a cause de ce genre de commentaire que j’apprends pas le Rust.
Le langage a l'air cool, mais les fan de Rust son tellement toxic…
Bon en vrais j'ai vraiment l'intention de me mettre plus sérieusement au Rust un de ces 4, mais me faire imposer un compilateur trop gros, avec une lib standard tout aussi bloated, ça me donne pas très envie.
Alors qu'en C, je peu faire des tcc -run cool_program.c et je peu même allers modifier le code du compilo si je veux, puisque un bon langages, ne se définit uniquement par la capacité de ces développeurs à recoder un compilo pour leur propre langages.
Moi je dirai : Il ne faut pas rabaisser le libre à un mouvement dogmatique, politique ou religieux.
Exactement, c'est même pour ça que j'utilise Arch Linux.
Arch Linux m'a permit d'apprendre le libre avec la licence, la solidaritee avec l'AUR, l'amour, avec ILoveCandy.
Quand que je fait a mangée, que je code je me demande, si je suis la philosophie d'Arch Linux.
Caques matin je regarde m'a Arch linux, et je suis heureux, de savoir que ma Arch Linux est la pour moi.
Tous les dimanches matin je fait ma Mise a Jour de ma Arch Linux, et cette communion avec mon ordinateur, m'offre un joie immense.
Arch Linux, m'a vraiment apprit ce qu'est le libre !
Arch Linux m'a apprit que le libre est tellement plus qu'une religieux, politique ou mouvement dogmatique.
J'aurais détourner ton journal en inversant toutes les valeurs. (bon puis faire un journal pour défendre l’inverse de mes valeur, même sarcastiquement, ça reste dur a faire)
Mais autant Stallman est clairement de gauche, autant, y'a énormément de libriste crypto-fachiste (Lunduke, Luke Smith …), donc le rapprochement librisme == gauche, pas vraiment.
Alors oui, l’avis de Tim Sweeney ne représente pas celui de tout les acteurs du marchés.
par contre avoir le CEO de EAC(Easy Anty-Cheat) qui dit publiquement sur Twitter que son truck marche mal soue Linux, ça fait très mauvaise presse pour essayer de convaincre les jeux soue EAC d'activer le support Linux.
Sinon c'est assez rigollot d'utiliser l’excuse du kernel qui est open source, alors que Fotnite est disponible soue Android.
Bon une nouvelle implem de lua, en C++ (donc lib standard C++ imposé), et qui n'est pas forcément bien distribué, ça me semble être un projet qui va tomber à … luau.
Effectivement, ceci dit si j'ai poster ce lien, c'est car Ethan Lee a aussi ça propre mauvais expérience avec la partie "open source" de Microsoft qui est mauvaise, et peu lier à Hot Reload. (dont il ne parle pas dans ça thread).
Edit: enfin il a fait ça thread en réponse à l'article de the Verge.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 2.
sauf que sprintf a pour 1er argument un buffer, si tu utilise un buffer static avec un taille fix (et donc snprintf), tu peu pas savoir si ton buffer seras assez gros, si tu fait des malloc, c'est plus lourd et tu doit free, sinon tu fait des sizeof, t'a ton buffer qui a la bonne taille, et pas besoins du 'n' dans sprintf, puisque ton buffer auras la bonne taille.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 0. Dernière modification le 03 mars 2022 à 11:38.
ok, remplace le printf par un open, SDL_LoadBMP, Mix_LoadMUS…
genre t'a un dossier avec des assets, ou tu suit des pattern de nommages.
l’intérêt c'est comment j'utilise memcpy (plus opti que strcpy BTW)
Crée un buffer dans la mémoire automatique qui auras la taille exact de plusieurs strings.
pouvoir modifier la taille des strings dans mes defines sans avoir peur d'overflow.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -1.
https://godbolt.org/z/1rqGvn8sv
Ça permet de faire de la manipulation de string, sans passer par de l'allocation dynamique.
mais je doute pas qu'un compilo aurais pu remplacer des malloc par du code static, Oh wait, tu sais comment marche un compilo ?
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -3.
https://godbolt.org/z/c6hnG31YM
On va pas refaire le débats sur sizeof, ça marche dans certains cas, pas d'autres, et ça dépend de t'a définition de "c'est quoi la taille d'une string ?"
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 2.
Bah l’exemple avec grep:
on voie que en go, si tu fait un '==' entre 2 chaine unicode, qui représente le même character, mais on des octet différent(ici "\u{00e9}" et "\u{0065}\u{0301}"), go retourne true.
ce qui veut dire que le '==' de go, est plus complex qu'un comparaison octet à octet.
C'est surement très pratique dans plein d’application, mais si tu cherche de la perf, c'est moins performent.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 0.
tu veut dire, est ce que PHP6 a étais abandonné, car tout le monde s'en fout du support de Unicode ?
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -1.
Et est-ce que t'a vraiment envie d'avoir une conversions de string par default, a chaque comparaison, quand tu recode un compilateur, qui auras 10M lignes de code à recompiler le plus rapidement possible ?
que tu recode git et manipule des repository de plusieurs Millions de commits ?
que t'est sur de l'embarqué et que chaque instruction compte ?
En terme de perf, ça doit être magique.
Tout ça pour en revenir à mon assertion de base: Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo, et tu viens de m'expliquer que C est mieux que go.
Bien sur, si tu choisie ton langages de programmation en ne fessant pas cette assertion, C n'est pas forcement mieux que go, mais qui ferais ça ?
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 0.
/me aurais du s’arrêter…
Mais j'ai regarder la: https://github.com/NetBSD/src/blob/trunk/usr.bin/grep/grep.c, et bah: des char, des strcasecmp, et des strlen.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -2. Dernière modification le 02 mars 2022 à 23:40.
Oui, mais une chaine ASCII est une string :p
Pour arréter le troll, c'est plutôt bien l'esprit de C, si t'a une string literal, tu utilise sizeof, si t'a chaine ascii(void UTF-8 dans certains cas) tu prend strlen, et si t'a de l'unicode, voila wcslen.
Et si tu veut un méthode qui gère tout, tu va galérer, mais si t'est bien avec ton programme qui a tout en static (un genre de sl (le train)?), bah tes sizeof seront très bien, et pas besoins de plus.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -3.
non, m'a position c'est ça: https://nitter.eu/id_aa_carmack/status/1078092777429311488?lang=en
J'ai il me semble, pas parler de sécurité, ou de la complexité à éviter les bugs en C, j'ai juste parlé du standard C, pour être un petit con qui a raison, mais si j'ai raison dans des cas qui sont en pratique peu utilisable.
mais bon vu que tu passe de "strlen marche pas sur unicode" à "les terminaux sont en UTF-8" sur lesquels strlen marche donc ASCII, UTF-8 font pas grande différence vu que ls, curl, cat… eux utilise les function de la lib standard, je crois pas être le seul à avoir des arguments un peu bidon, limite malhonnête.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -5. Dernière modification le 02 mars 2022 à 22:21.
Bah oui, tu a dit qu'il n'y a aucun moyen de calculer a temps constant de calculer la longueur d'une string, c'est factuellement faux, bien que la technique ne marche pas tout le temps.
Effectivement j'ai pas parler de l'offset de 1, mais les 2 manières permettes de connaitre la longueur d'une string, chacune à leur avantages dans certaines conditions.
Bah oui, parce-que t'a pas beaucoup de programmes qui ont besoins de sortir de l'ASCII. (moi qui ne connais que le terminal n'en ai pas besoins)
sauf que si t'a pas de \0, t'a pas une string au sens C du terme, donc c'est HS. (si tu fait un memset dans t'a std::string en C++, peu être que ça va pas bien marcher non plus).
Après j'ai jamais dit que C est un langage sécure, j'ai dit que la seul choses qui permet de noter la qualité d'un langage, c'est la capacité de ces développeur à recoder un compilateur.
Ce sur quoi:
# Canard et Couvert ?
Posté par uso (site web personnel) . En réponse au lien "En cas de crise ou de guerre" : version française du livret édité en 2018 par la Suède. Évalué à -3. Dernière modification le 02 mars 2022 à 19:51.
à l’instar d'un Duck and Cover, j'ai du mal à pas voir ce genre de lien comme une manière de propagander de la peur.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
bah la définition d'une string literal c'est
et les string literal sont des array. (source: https://www.iso-9899.info/n1570.html#6.4.5)
Donc oui, sizeof retourne la taille d'une array, mais ça retourne aussi la taille d'une string, et c'est calculé a la compilation.
Et strlen("ma chaine de character"); c'est juste un code pas optimisée pour 0 raison.
Bien sur si on utilise des variable on doit utiliser strlen, mais si on utilise des variable et que la calcule de la longueur est important, autant utiliser une struct qui contiens la longueur de la string.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 3.
non le standard C, dit que char c'est toujours 1,
donc sizeof char, est inutile.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 3.
C'est vrais que je suis un peu partie vite, âpres, avoir quelqu'un qui viens te dire, "fait du Rust" dans chaque conversation qui parle de C, c'est une peu lourd.
Une peu comme si a chaque fois que tu évoque C# quelqu'un te tombe dessus parce-que "Grenieunieu Microsoft c'est mal".
Ou comme si dans caques conversation qui parle de Distro (GNU ?)Linux, y'a un con qui viens te parler d'Arch (GNU ?)Linux.
Dalleur, est ce que vous saviez que j'utilise Arch (GNU ?)Linux, et que ça marche vraiment très bien ?
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 3.
C'est vrais, âpres dire "c'est pas dans la lib standard" alors que c'est dans le langage, c'est pas ouf comme argument.
Ok, j'avais vraiment rater la blague, merci pour l'explication.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -5.
ok, j'ai pas la blague, mais je voie vraiment pas le rapport avec les voyelles (tu veut dire accent ) ?
sizeof permet de connaître la taille d'une string à temps constant, ce que tu peu pas connaître en C, c'est la taille d'un char *(et "hello" est un char [6]).
ceci dit sizeof c'est du C, pas une partie de la libc.
Après il n'y a aucun langages "haut niveau"(C inclue) qui permet de connaître le temps d'accès à n'importe quel variable non plus. (vu que ton int peu être dans ton cache L1,L2, t'a ram, ton disk dur si t'a du swap, pas allouée du tout vu que Linux alloue de la mémoire sur les page fault par default sur x86…)
Donc l'argument de "tu peu pas faire un opération pas optimisée sur une structure de donnée pas optimisée", bon…
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -8.
Va falloir des sources pour cette affirmation, après OSEF, les voyelles sont dans ASCII.
sizeof "non ?"
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 5.
C'est exactement a cause de ce genre de commentaire que j’apprends pas le Rust.
Le langage a l'air cool, mais les fan de Rust son tellement toxic…
Bon en vrais j'ai vraiment l'intention de me mettre plus sérieusement au Rust un de ces 4, mais me faire imposer un compilateur trop gros, avec une lib standard tout aussi bloated, ça me donne pas très envie.
Alors qu'en C, je peu faire des
tcc -run cool_program.cet je peu même allers modifier le code du compilo si je veux, puisque un bon langages, ne se définit uniquement par la capacité de ces développeurs à recoder un compilo pour leur propre langages.# Ça me rappelle ça
Posté par uso (site web personnel) . En réponse au lien Tas d'idées reçues : "Open Source : pourquoi le mythe du logiciel libre est une illusion dangereuse". Évalué à 2. Dernière modification le 27 février 2022 à 18:32.
Pareil mais en plus vieux, avec plus d'argent
[^] # Re: Tu es prêt pour... Etre déçu par le libre
Posté par uso (site web personnel) . En réponse au journal Le mouvement du logiciel libre est un mouvement politique et social. Évalué à 5. Dernière modification le 18 février 2022 à 20:50.
Exactement, c'est même pour ça que j'utilise Arch Linux.
Arch Linux m'a permit d'apprendre le libre avec la licence, la solidaritee avec l'AUR, l'amour, avec ILoveCandy.
Quand que je fait a mangée, que je code je me demande, si je suis la philosophie d'Arch Linux.
Caques matin je regarde m'a Arch linux, et je suis heureux, de savoir que ma Arch Linux est la pour moi.
Tous les dimanches matin je fait ma Mise a Jour de ma Arch Linux, et cette communion avec mon ordinateur, m'offre un joie immense.
Arch Linux, m'a vraiment apprit ce qu'est le libre !
Arch Linux m'a apprit que le libre est tellement plus qu'une religieux, politique ou mouvement dogmatique.
I Use Arch BTW !
# J'aurais pas eu la flemme...
Posté par uso (site web personnel) . En réponse au journal Le mouvement du logiciel libre est un mouvement politique et social. Évalué à 6.
J'aurais détourner ton journal en inversant toutes les valeurs. (bon puis faire un journal pour défendre l’inverse de mes valeur, même sarcastiquement, ça reste dur a faire)
Mais autant Stallman est clairement de gauche, autant, y'a énormément de libriste crypto-fachiste (Lunduke, Luke Smith …), donc le rapprochement librisme == gauche, pas vraiment.
Surtout que le cancel de RMS, des personnes voyais ça comme un "complot" des entreprisse qui font de l'open source pour le remplacer, par une personne plus business compatible: https://ultralux97.medium.com/stallman-must-be-removed-a3061b09fb22
https://web.archive.org/web/20210331115624/https://libreboot.org/news/rms.html
Donc utiliser cette événement pour justifier que le libre c'est de gauche, je trouve ça pas top (sauf si pour toi macron est de gauche)
[^] # Re: Ok Tim
Posté par uso (site web personnel) . En réponse au lien Pourquoi il n'y aura pas plein de jeux ni pour Arch Linux ni pour GNU/Steam Deck.. Évalué à 4. Dernière modification le 10 février 2022 à 15:30.
Alors oui, l’avis de Tim Sweeney ne représente pas celui de tout les acteurs du marchés.
par contre avoir le CEO de EAC(Easy Anty-Cheat) qui dit publiquement sur Twitter que son truck marche mal soue Linux, ça fait très mauvaise presse pour essayer de convaincre les jeux soue EAC d'activer le support Linux.
Sinon c'est assez rigollot d'utiliser l’excuse du kernel qui est open source, alors que Fotnite est disponible soue Android.
# c'est dans le nom ?
Posté par uso (site web personnel) . En réponse au lien luau : une variante du langage lua. Évalué à 3.
Bon une nouvelle implem de lua, en C++ (donc lib standard C++ imposé), et qui n'est pas forcément bien distribué, ça me semble être un projet qui va tomber à … luau.
[^] # Re: Microsoft met en colère la communauté open source .NET avec une décision controversée
Posté par uso (site web personnel) . En réponse au lien Récapitulative de Microsoft <3 Open Source Par Ethan Lee (Lead Dev de FNA) . Évalué à 1. Dernière modification le 08 novembre 2021 à 17:52.
Effectivement, ceci dit si j'ai poster ce lien, c'est car Ethan Lee a aussi ça propre mauvais expérience avec la partie "open source" de Microsoft qui est mauvaise, et peu lier à Hot Reload. (dont il ne parle pas dans ça thread).
Edit: enfin il a fait ça thread en réponse à l'article de the Verge.