uso a écrit 289 commentaires

eh, sauf que c'est pas exactement ce que fait le '==' en swift.

La perte de perf dont je parle, est du à la normalisation pour faire en sorte que "\u{00e9}" == "\u{0065}\u{0301}" en swift.
et vu que grep a l'air d'utiliser des comparaison octée a octée (avec netbsd, mais surement pareil sous GNU), bah grep devrais être plus rapide que le code swift de groumly.
Mais de la comparaison octée a octée peu étre utiliser pour de l'UTF8.
"\u{00e9}" == "\u{00e9}" va marché, mais pas "\u{00e9}" == "\u{0065}\u{0301}".

Parce-que tu peu gérer les emoji et autre dans un compilo en gérant UTF-8 avec peu de perte de perf, le problème c'est si t'essaye de faire en sorte de gérer tout les encodage d'unicode.
En gros groumly dit que un languages devrais avoir dans ça lib standard des super string, et je dit qu'en C on veut des string réaliste.
Bref tu préfère Goldorak ou Gundam quoi ? (parceque Goldorak super Robots, et Gundam Real Robots (et bien sur la bonne réponse c'est Ideon))

j'ai fini par faire une AppImage: ça marchouille mais ça revient à se mettre complètement hors de la distrib.

Effectivement j'ai pas prit en compte l'intégration a la distro du tout, et oui y'a encore du travaille a faire, pour ça je regarderas plutôt du coté Flatpak que Appimage(et encore, y'en a qui essaye).

Et comme tu la dit y'a encore des bizarrerie avec Flatpak, par contre avec steam deck, silverblue qui l'utilise par default, et la majorité des distro qui l'intégre, je trouve que le projet évolue très vite dernièrement.

Par curiosité ça date de quand ton test Flatpak ?

Après pour java il me semble que Minecraft étais pendant packagé en mode "prend le jar et démerde toi", et ça embêtais pas grand monde.

Sauf que ce que dit torval (vu qu'il me semble que c'est de ça qu'on parle)
c'est "moi ce que je veut, c'est compiler mon programme, et que ça marche, et OSEF de l'intégration à la distro", et il se peint des ABI qui casse.
Et pour ça Appimage marche, glibc est backward compatible, et un Appimage crée sur une distro stable, est généralement portable.

Tu parle d'intégration aux distro, et c'est exactement ce dont torval ne parle pas, et c'est aussi l'une des choses les moins importante pour les dev d'application, le but c'est qu'on puisse DL, et exécuté l’application. (comme le ferais un utilisateur windows avec son exe)

L'intégration distro, c'est aux distro de la faire. (et reste la meilleur manière d'installer une app)

Aucun n'a pour le moment changé véritablement la donne. Aujourd'hui le packaging de distribution est toujours extrêmement majoritaire et les distributions qui tentent de s'appuyer quasi exclusivement sur ces packaging sont tout à fait expérimental.

Steam Deck qui s’appuie sur flathub pour son store te donne raison.

Mais sinon on pourrais parler de RPCS3, Krita et tout plein de packets auquel je pense pas qui sont packagé en Appimage et marche très bien.
Surtout que RPCS3/krita, c'est surement l'enfer en terme de dépendances.

La majeur différence avec 2014, c'est que aujourd'hui seul ceux qui on pas essayer, croie que le packaging reste compliquée soue linux.

2007 et appimage depuis 2004.

wayland/Python3/Rust/IPv6 existe depuis 2008/2010/1995 pourtant ça fait pas depuis si longtemps qu'on en voie vraiment.

sous Windows et Mac ça marche

Dalleur, je sais pas t'a eu l’occasion de lancer Steam sous macos récemment,
mais y'a un truck bizarre, la majorité des jeux qui marchais y'a 2 versions de l'OS ne sont plus supporté et ne se lance même plus.

Un truck à propos de 32 "bit", mais moi qui n'y rien en ordinateur, je comprend pas bien le message.

https://youtu.be/Pzl1B7nB9Kc

sauf que depuis on a eu, Flatpak, appimage, snapy…

Surtout que si faire du Dynamic Static te conviens, c'est pas trop compliquer, suffit de faire ça: https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf89d1502de88. (qui est en soie très similaire a un Appimage)

Vraiment pas sur que Torval est le même avi aujourd'hui.

C’est moi, ou tu viens de sortir php dans une discussion sur les bons langages de programmation?

Exactement !

PHP 6 avais pour but de rajouter le support unicode dans le langages (exemples):

$わたし　= "je";

mais a était complétement abandonné parce-que:

• trop compliqué a implémenté
• personne ne voulais vraiment la feature.

Mais si ça a bien montrée une choses, c'est que même pour les langage les plus populaire, (et qui on le plus tendance a avoir du code en pas anglais)
bah avoir un gestion correct de unicode dans t'a VM/compilateur/interpréter est assez OSEF-tier.

Donc quand tu recode un compilo, avoir le '==' de swift est pas forcement un avantage.

Sur internet le 2nd dégrée marche mal, car il est compliquée de comprendre l’expression de gents a l'écrit.
Mais vu que le 3éme c'est l'inverse, le 3éme dégrée marche extrêmement bien, pour l'univers entier (sauf les personnes qui ont plusser ton explication 1er degrée)

1er dégrée: le C est effectivement difficile dans plein de cas, mais ça simplicité lui donne certain avantages dans tout ce qui est bas niveaux et a besoins de performances.

2éme dégrée: Oui le C, c'est trop bien, ca permet de coder cowsay en ascii sur arduino, LOL ooops segfault.

3éme dégrée: Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo. (avec un essaye d'explication pour donner les vrais avantage de C, tout en ayant l'air 2nd dégrée).

Enfin c'est mon explication des dégrée de paroles, qui est donc universellement vrais (toutes personne en désaccord a tord, et n'utilise pas Arch Linux)

Effectivement, je voulais dire, tu peu pas savoir si snprintf va fail(avant de l'appeler).

le truck, c'est que si tu met une taille impartial à ton buffer(genre 1024), même avec des donnée en entrée que tu maitrises(genre des strings literal), t'est pas a l'écart qu'un gent modifie t'a string, et dépasse ton buffer.

Pour gérer ça que sizeof sur une string littéral, peu être bien pratique de temps à autre.

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.

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 ?

https://godbolt.org/z/c6hnG31YM

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 ?"

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.

tu veut dire, est ce que PHP6 a étais abandonné, car tout le monde s'en fout du support de Unicode ?

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 ?

/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.

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.

"Vu que C est parfait, tout probleme est 100% imputable a un idiot de programmeur qui sait pas écrire du code, donc C est parfait"

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.

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.
• seul l'ASCII compte.
• Avoir un langage compliquée n'aide pas du tout.

à 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.

bah la définition d'une string literal c'est

A character string literal is a sequence of zero or more multibyte characters enclosed in double-quotes, as in "xyz".

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.

non le standard C, dit que char c'est toujours 1,
donc sizeof char, est inutile.

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 ?

Ben, on est sur un thread qui parle de ta remarque

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.

Dans strcpy, strchr, strpbrk, sqrt, mbstowc, tu as combien de voyelles ?

Ok, j'avais vraiment rater la blague, merci pour l'explication.