Unicode est très loin d’être simple à gérer. Ce qui est justement ce qui me fait hurler quand je lit les commentaires d’uso.
Si j'ai donnée l’impression de dire que en C c'est facil de lire de l'unicode, pardon, c’était pas le but. (et encore y'a les wchar_t)
Ce que j'ai essayé de dire, c'est quand tu travaille sur un projet qui a un vrais besoins de perf tel que tcc,git,grep,quickjs,linux… Mieux vaut un truck cassée qui marche la plupart du temps, que d'avoir un truck qui marche tout le temps, mais qui casse ton CPU de temps en temps.
Le Front-End, c'est ce qui convertie le Code C en SSA-Tree (LLVM-IR soue clang, GIMPLE soue GCC), c'est donc tout le parser.
Le Middle-end, qui utilise une SSA Tree form dans le cas de LLVM/GCC, c'est la partie qui va être optimisé.
Le back end prend la form SSA Tree et la convertie en binaire (bon sauf gcc, qui convertie les GIMPLE en RTL qui est une autre représentation intermédiaire).
Je suppose que le code entre 2 parser C qui target LLVM-IR peuvent avoir des architecture différents, mais en soie ça reste le même job.
Âpres ICC étant close source, c'est pas impossible qu'il ai modifier le middle-end et le back-end aussi.
Effectivement ils sont passée a LLVM en 2021, âpres leur ancien compilateur supportais aussi C11 il me semble.
Ceci dit l'implémentation de C, est pas dans LLVM, mais dans le front-end qui l'utilise, donc ICC et clang, ça reste 2 implémentations différents(en theory, ICC étais Close Source…).
Un choses intéressante a savoir, c'est que un compilateur C11 est plus simple a codé qu'un compilateur C99, ça C11 a rendu beaucoup de choses de C99 optionnel. (c'est dalleur pour ça que MSVC ne gère pas C99).
Et C11 et C17, sont extrêmement similaire, vu que C17 c'est une version bugfix de C11.
En implémentation complète tu doit avoir gcc, clang, icc ? et recement MSVC.
Après t'a pas mal de compilateur qui l’implémente partiellement, tcc (qui support _Generic, _Static_assert, union/struct anonyme), pcc (_Static_assert), mir (lui jamais testé) et surement plein que je connais pas ou oublie.
L’essentiel des outils unix, par exemple, reste en c parce que ça fait une montagne de code à porter. Mais si tu devais réécrire sudo ou autre outil de ce style, je suis pas convaincu que le C serait le language le plus adapté.
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.
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.
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.
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.
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.
[^] # Re: Guillemets
Posté par uso (site web personnel) . En réponse au lien Stallman insulte la "gastronomie" canadienne et le président Russe en même temps. Évalué à 2. Dernière modification le 08 mars 2022 à 13:15.
en même temps, est-ce que la poutine n'est pas elle déjà une insulte à la frite belge ?
A l’instar des mac & cheese ou des gents qui coupes leur spaghetti qui sont une insulte a la cuisine italienne.
[^] # Re: Go with C
Posté par uso (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 0.
Vous connaissez Arch Linux ?
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -1.
Si j'ai donnée l’impression de dire que en C c'est facil de lire de l'unicode, pardon, c’était pas le but. (et encore y'a les wchar_t)
Ce que j'ai essayé de dire, c'est quand tu travaille sur un projet qui a un vrais besoins de perf tel que tcc,git,grep,quickjs,linux… Mieux vaut un truck cassée qui marche la plupart du temps, que d'avoir un truck qui marche tout le temps, mais qui casse ton CPU de temps en temps.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 2.
Dur a dire,
LLVM, comme GCC ont une Architecture très similaire qui ressemble grosso mode a:
[Front-end] -> [SSA Tree Form] -> [Back End]
Le Front-End, c'est ce qui convertie le Code C en SSA-Tree (LLVM-IR soue clang, GIMPLE soue GCC), c'est donc tout le parser.
Le Middle-end, qui utilise une SSA Tree form dans le cas de LLVM/GCC, c'est la partie qui va être optimisé.
Le back end prend la form SSA Tree et la convertie en binaire (bon sauf gcc, qui convertie les GIMPLE en RTL qui est une autre représentation intermédiaire).
Je suppose que le code entre 2 parser C qui target LLVM-IR peuvent avoir des architecture différents, mais en soie ça reste le même job.
Âpres ICC étant close source, c'est pas impossible qu'il ai modifier le middle-end et le back-end aussi.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 2.
Effectivement ils sont passée a LLVM en 2021, âpres leur ancien compilateur supportais aussi C11 il me semble.
Ceci dit l'implémentation de C, est pas dans LLVM, mais dans le front-end qui l'utilise, donc ICC et clang, ça reste 2 implémentations différents(en theory, ICC étais Close Source…).
sinon je suis aller voir la: https://developers.redhat.com/blog/2021/04/27/the-mir-c-interpreter-and-just-in-time-jit-compiler
et y'a une list de compilo que j'ai pas tester mais qui sont sensée gérer au moins partiellement C11:
https://github.com/rui314/chibicc
https://github.com/michaelforney/cproc
https://github.com/libfirm/cparser (qui comparer a ce que dit la description, a l'air d'au moins connaitre les mots clé de C11)
Un choses intéressante a savoir, c'est que un compilateur C11 est plus simple a codé qu'un compilateur C99, ça C11 a rendu beaucoup de choses de C99 optionnel. (c'est dalleur pour ça que MSVC ne gère pas C99).
Et C11 et C17, sont extrêmement similaire, vu que C17 c'est une version bugfix de C11.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 2.
En implémentation complète tu doit avoir gcc, clang, icc ? et recement MSVC.
Après t'a pas mal de compilateur qui l’implémente partiellement, tcc (qui support _Generic, _Static_assert, union/struct anonyme), pcc (_Static_assert), mir (lui jamais testé) et surement plein que je connais pas ou oublie.
[^] # Valve fait du C
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 4.
Et pourtant, valve viens de sortie Aujourd'hui son devkit pour la steam deck… En C. (bon pour la partie server, le client est en Python)
https://www.gamingonlinux.com/2022/03/valve-open-sources-steamos-devkit-client-for-steam-deck/
https://gitlab.steamos.cloud/devkit/steamos-devkit-service
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
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))
[^] # Re: Go with C
Posté par uso (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 2.
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.
[^] # Re: Go with C
Posté par uso (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 2.
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)
[^] # Re: Go with C
Posté par uso (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 5.
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.
wayland/Python3/Rust/IPv6 existe depuis 2008/2010/1995 pourtant ça fait pas depuis si longtemps qu'on en voie vraiment.
[^] # Re: Go with C
Posté par uso (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 0. Dernière modification le 04 mars 2022 à 11:42.
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.
[^] # Re: Go with C
Posté par uso (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
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.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
Exactement !
PHP 6 avais pour but de rajouter le support unicode dans le langages (exemples):
mais a était complétement abandonné parce-que:
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.
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -4.
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)
[^] # Re: Survivor
Posté par uso (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 0.
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.
[^] # 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.