David Demelier a écrit 663 commentaires

Oui c'est même pour ça que lors d'un hackaton FreeBSD (si je me trompe pas) les développeurs en ont fait une petite blague.

Tout ça pour rajouter des standard --help et copyright.

git is great because linus did it, mercurial is better because he didn't

Sauf que personne utilise c99 de POSIX. Une bonne partie des développeurs sensés activent tôt ou tard les warnings (options -W de gcc/clang) qui n'est évidemment pas couvert par POSIX et donc ton utilisation non portable. De plus, POSIX demande un compilateur C99, aujourd'hui on est bientôt à C23, ce serait dommage de rester sur des anciennes versions juste pour être 100% POSIX compliant.

Évidemment, loin de moi l'idée de dénigrer POSIX je suis moi même développeur C et embarqué privilégiant des APIs POSIX pour rester portable, mais je considère pas POSIX comme la bible non plus (POSIX make par exemple, c'est bien pour un projet à 2-3 fichiers, mais ça devient vite casse gueule sur des projets plus riches).

Pour résumer, je pense que ton argument n'est pas valable. POSIX stipule l'option -o de disponible donc quiconque voulait un nom de fichier prédictif devrait l'utiliser de toute manière.

git is great because linus did it, mercurial is better because he didn't

J'oublie toujours à quel point on est réfractaire au changement. Surtout quand c'est aussi trivial que ça.

git is great because linus did it, mercurial is better because he didn't

cl.exe utilise le nom du fichier, main.c devient main.exe. Donc dans notre cas main.

git is great because linus did it, mercurial is better because he didn't

Moi j'ai aussi hâte que les compilateurs C arrêtent de créer un exécutable a.out par défaut. Surtout quand celui ci est un ELF.

git is great because linus did it, mercurial is better because he didn't

C'est pas juste une position ou le respect des HIG de Apple, c'est clairement un autre style.

Exemple avec Terminal.app

Et avec Qt Creator (Qt 6)

La position des polices, la taille des polices, la couleurs du tab widget, la forme du selecteur de combobox. Rien ne va donc c'est pour ça que je ne comprends pas pourquoi si Qt 6 utilise les APIs native comme ça a été indiqué au dessus il y a autant de choses qui ne vont pas.

git is great because linus did it, mercurial is better because he didn't

Baaaah alors je comprends pas pourquoi les applications Qt 5 n'ont pas du tout un look natif sur macOS.

git is great because linus did it, mercurial is better because he didn't

Mais Qt utilise le toolkit sous-jacent dessiner les widgets. Et là c'est bien le but oui.

Cela a changé avec Qt 6 alors, parce qu'avec Qt 5 on peut toujours « simuler » l'interface de n'importe quel système sur n'importe qu'elle plateforme (aka Windows sur Linux, macOS sur Windows).

Tiled, une application en Qt 5 par exemple sur macOS Big Sur est pas native et a un look-and-feel des anciennes versions de macOS (<= Catalina).

git is great because linus did it, mercurial is better because he didn't

Au style:

• Onglets avec mauvaises couleurs.
• Boutons avec des icônes.
• Encore d'autres détails que l'on voit directement quand on connait macOS.

git is great because linus did it, mercurial is better because he didn't

Il y a écrit que c'est du natif en bureau mais en voyant la capture d'écran de la version macOS je constate immédiatement que ce n'est pas le cas. Aurais-je mal compris le terme natif ?

git is great because linus did it, mercurial is better because he didn't

Le C++ évolue beaucoup alors les ressources deviennent rapidement obsolètes (ou presque). Le cours du site du zero est évidemment à bannir.

Celui du zeste de savoir est pas mal mais contient pas tout des dernières normes. En tout cas tu peux commencer par ça. Pour le reste, le plus simple est de faire de la recherche et de poser des questions. Il y a des tonnes d'articles sur le C++11, C++17 et C++23 qui vont expliquer les nouveautés, à quoi elles servent, quels problèmes elles résolvent, etc.

git is great because linus did it, mercurial is better because he didn't

Comme en shell, tu peux simplement mettre un tiret avant EOF et alors tu peux indenter ce dernier.

my $help = <<-EOF;
...
...
EOF

Perl suit visiblement la même syntaxe que le shell (sauf le ; obligatoire)

git is great because linus did it, mercurial is better because he didn't

Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.

Faut vraiment s'abstenir de dire des inepties quand on sait pas de quoi on parle. Le seul moment où ça devient compliqué c'est quand tu veux utiliser une fonctionnalité qui est récente et que tu vises des distributions qui ont des vieux paquets. Pour ma part ça m'arrive jamais et pourtant j'utilise des outils moderne (je demande du CMake 3.20 par exemple, du C11, du C++17, du Qt 6, etc.). Alors à un moment donné tu peux aussi dire « désolé mon application ne supporte pas Debian 7 ». Tout comme tu peux voir des applications stipulant « Windows 10 ou supérieur, macOS Catalina ou supérieur, etc » Mais à ce moment là on jette la pierre au développeur plutôt qu'à la distribution qui fournit une panoplie de paquets sentant le formol.

C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.

Pas sûr de comprendre en quoi tu peux en avoir quelque chose à faire que Gtk soit compilé en -O0 ou -O3. Pour Qt et Gtk, les choses sont bien faites, il y a des modules indépendants. Comme QtWayland, QtMultimedia, etc. Ça permet justement de pas faire un Qt monolithique « Oops, mon programme peut pas se compiler car la distribution crux ne compile pas le support de l'audio dans Qt »/.

Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent

Là c'est la preuve totale que tu ne sais pas de quoi tu parles. Rien ne bizarre se passe du moment que l'ABI est respectée. Hint : il s'agit du petit numéro stocké dans le SONAME d'un ELF.

readelf -d /usr/lib/libgtk-4.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libgtk-4.so.1]

git is great because linus did it, mercurial is better because he didn't

Dis ça lorsque le poste en question est un développement d'une application Windows utilisant la WinAPI, les MFC, RPC et COM :)

git is great because linus did it, mercurial is better because he didn't

Note : GNU/Linux n'est plus. Beaucoup de distributions ne sont plus basées sur GNU comme celle que j'utilise et je contribue : Alpine.

Pour ma part :

• Je développe quasiment que sous Linux (vim, make, cmake, clang comme outils).
• J'utilise un mac en “daily driver” parce que je n'apprécie plus Linux en bureautique comme je l'appréciais il y a 17 ans.

Concernant le sondage, pas de Visual Studio et encore moins de Azure, AWS ou Google Cloud Platform. La centralisation de masse, pas mon truc :).

git is great because linus did it, mercurial is better because he didn't

sizeof (char) renverra toujours 1, peu importe la machine et l'architecture. La différence c'est qu'il existe des machines ou un char vaut 64 bits donc pour faire simple : un octet ne fait plus 8 bits mais 64.

git is great because linus did it, mercurial is better because he didn't

Hmm ouais. Sauf qu'une fois j'ai voulu utiliser un seul module "header-only" et j'ai du me trimballer MPL, System et d'autres modules transitifs. Et System lui n'est pas header-only, donc ceux qui disent que cette bibliothèque est header-only et modulaires vendent du vent.

git is great because linus did it, mercurial is better because he didn't

Faudra m'expliquer cet entêtement à vouloir copier cette barre de menu globale. GNOME a viré les menus des applications mais Plasma le gère toujours. Ça n'a strictement plus aucun sens, c'était utile quand on avait des écrans en 800x600 où il fallait économiser le moindre pixel. Maintenant qu'on a des écrans géants et des résolutions 5k je perds plus de temps à naviguer entre la barre de menu et la fenêtre quand je connais pas le raccourci clavier par cœur.

git is great because linus did it, mercurial is better because he didn't

Et strlen ne renvoie pas la taille d'une chaine non plus. c.f. strlen("ça va")

git is great because linus did it, mercurial is better because he didn't

Aussi, rien qu'évoquer Rust est toxique maintenant ?

Non, tu n'as pas évoqué Rust. Tu as dit « Ou utilise Rust/autre langage moderne de son choix ». Ce n'est pas tout à fait la même chose.

git is great because linus did it, mercurial is better because he didn't

C'est pas joli setjmp/longjmp. Comme disent certains “Exceptions are, in essence, sophisticated GOTO statements”.

Loin de moi l'idée de penser que les exceptions sont mauvaises, mais ça n'a pas sa place dans ce langage aussi bas niveau qu'est le C. En C++ par exemple, un simple std::cout << "hello\n" peut lever une exception ce qui signifie que dans les programmes très critiques il faut absolument lire la documentation de chaque fonction qu'on utilise. Mais aussi, si j'utilise une bibliothèque qui ne documente pas bien les exceptions qu'elle peut lever (car elle en oublie d'une couche plus bas niveau) je risque tout simplement de planter mon programme car j'arriverai dans la gestion de l'exception peut-être là où je ne le souhaite pas. Alors devons nous protéger tous les appels de chaque fonction ?

On dit aussi que les exceptions sont performantes. Ce n'est pas le cas. Une fois on a réduit drastiquement les performances d'une boucle de notre application qui était écrite de cette manière :

for (...) {
   try {
      something();
   } catch (...) {
      blabla();
   }
}

En

try {
    for (...) {
        something();
} catch (...) {
    blabla();
}

Certes une erreur d'étourderie. Mais si la fonction something() fait aussi des try-catch à tout va, les performances sont encore une fois impactées.

Pour ma part j'ai utilisé une seule fois setjmp/longjmp dans mon application (un jeu vidéo). L'idée est de faire un mécanisme de « panic » : s'il arrive quelque chose d'irrécupérable (carte corrompu, image manquante, …) au lieu de crasher l'application à la sauvage, j'affiche quelque chose à l'écran avant de quitter (un peu comme un BSOD). Mais c'est la seule utilisation viable que j'en ai.

git is great because linus did it, mercurial is better because he didn't

C'est exactement a cause de ce genre de commentaire que j’apprends pas le Rust.

Exactement. De toute façon c'est assez simple, il y a la règle de Rust : à chaque fois qu'une discussion commence sur le C ou le C++ elle finira toujours par aboutir sur Rust.

Ce dont les gens ont tendance à oublier avec le C :

• C'est normé par l'ISO et par POSIX. Quand tu vas sur un système compatible POSIX tu sais que tu peux déjà compiler un projet entier : make, c99, lex, yacc, etc sont disponibles de base.
• Contrairement à Rust ce n'est pas bloat. Faire un hello world minimal ne nécessite pas 35 dépendances et de liaison statiques à foison.
• Contrairement à Rust un projet en C ou C++ ne télécharge pas 12000 dépendances à la npm (c.f. exa).
• Contrairement à Rust, je sais que mon programme sera compatible pendant des années, Mozilla peut du jour au lendemain tout péter s'ils le souhaitent.
• Contrairement à Rust, je peux tourner sur une panoplie de micro contrôleurs embarqués et m'implémenter sur une nouvelle architecture avec aise.

Longue vie au C.

git is great because linus did it, mercurial is better because he didn't

Après 30 ans, Java/C++/.Net/python/ruby/JavaScript/swift/objc/kotlin ont finis par le repousser dans les 2 seuls domaines où il perdure, à savoir la programmation très bas niveau (kernel/drivers) et l’embarqué où le hardware est digne des années 80, et nécessite de grosses optimisations pour pouvoir exister.
Et même dans l’embarqué, il reste beaucoup de scénarios ou d’autres langages sont plus adaptés.

Elles sont tirés de ton chapeau personnel ces statistiques ?

Il y a des projets récents en C, y compris dans le jeu vidéo et dans le reverse engineering. Faut juste se renseigner.

git is great because linus did it, mercurial is better because he didn't

Quand je parle de difficultés à gérer la mémoire c'est très simple à vérifier tout outillage qui existe il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.

Et à l'inverse le système d'exploitation le plus utilisé sur les serveurs au monde et dans la téléphonie mobile est écrit en C. Pour autant, pas de pannes majeures à ce que je sache.

Les boites à outils modernes comme LLVM fournissent une panoplie de “sanitizers” qui rendent le développement bien plus simple. La plupart des erreurs peuvent être déterminés pendant le cycle de développement. Pour ma part, j'ai déjà été sauvé à plusieurs reprises grâce à -fsanitize=address. (Et pas qu'en C).

git is great because linus did it, mercurial is better because he didn't

Quel rapport avec les logiciels libres ?

git is great because linus did it, mercurial is better because he didn't