David Demelier a écrit 676 commentaires

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

Ça ne répond pas tout à fait à ta question mais j'ai moi même régulièrement mal à mon petit doigt droit à force de massacrer la touche shift. Je suis développeur et je fais essentiellement du snake_case, en qwerty. Le seul inconvénient cet agencement par rapport à l'azerty c'est que _ est accessible en shift. Du coup je l'abuse beaucoup et j'ai parfois mal à mon petit doigt droit.

On m'a conseillé de me forcer à aussi utiliser le shift gauche (idem pour altgr/option/ctrl/cmd), qui lui, le pauvre est aussi propre qu'une salade fraichement coupée alors que l'autre paye son usure. J'essaie tant bien que mal mais c'est pas évident. En fait l'idée est de ne jamais appuyer sur le shift du même côté que la touche désirée. En gros les 3/4 des gens qui font un bon vieux ctrl+s dans Word, le font mal.

Exemples :

• super_cool (je dois utiliser shift gauche car _ est proche de la main droite)
• ssh pi@192.168.1.10 (je dois utiliser shift droit car @ est à gauche)

C'est très difficile de perdre des habitudes, surtout quand on écrit à une vitesse phénoménale comme moi.

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

Hélas je ne crois pas trop. Les fabricants disent eux même que faire une non-Smart TV ça ne se vendrait pas.

La seule solution actuelle c'est de ne pas les connecter à internet.

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

Quand j'ai aidé ma maman à acheter une nouvelle télé, on a pris une samsung car on était assez satisfait de la dernière (datant de 2011) sauf que ça a bien changé.

Au premier démarrage, un tas de questions stupides à choisir. J'ai fait refuser partout. Résultat maintenant dans le menu il y a un grand bandeau en permanence qui t'invite à te connecter un compte pour avoir du contenu personnalisé. Plus jamais de samsung.

Pour ma part, j'ai acheté une Philips Ambilight car j'adore le concept lumineux. L'autre jour j'ai eu une mise à jour … de ma télécommande. Va vraiment falloir qu'on m'explique comment on a pu en arriver là.

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

Non les modules C++ sont juste une alternative saine aux #include.

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

Justement en tant que dev C/C++ je trouve dommage qu'on doive tout faire à la main.

Tu n'as pas à tout faire à la main

• Json ? nlohmann json / jansson
• Client HTTP ? libcurl
• Lecture d'archives ? libarchive
• XML ? expat, tinyxml, pugixml
• Multimedia ? SDL2, SFML

D'ailleurs le plus simple c'est de chercher dans les projets “awesome”.

Pour C, pour C++.

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

Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.

Ça change rien, je viens d'essayer en local et ça a téléchargé 92 dépendances. C'est plus que le nombre de paquet total de mon image minimale de alpine.

Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.

Toujours pas d'accord. Boost c'est un framework bloat, il y a certes beaucoup de modules mais la plupart sont indépendants. Mais tu prends un mauvais exemple.

Personnellement quand je développe en C ou en C++, j'ai jamais eu à utiliser une lib externe pour faire des trucs aussi basique que générer un nombre positif dans une plage précise.

Dans mon application actuelle voilà mes dépendances :

• curl
• jansson
• mosquitto
• sqlite

Je comprends pas l'intérêt de faire une bibliothèque (comprendre paquet cargo) pour une ou deux fonctions.

A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.

Ça n'a absolument rien à voir avec le langage. Tu peux faire du full statique en C si ça te chante. Les 3/4 des bibliothèques sont fournies en statique et comme le linker est intelligent il inclue aussi que le nécessaire (à condition que la bibliothèque soit pas amalgamée).

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

Quand je vois le Cargo.lock du projet je suis content de toujours développer en C et C++ et ne pas faire parti du nouvel npm.

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

On fait du ELF depuis des lustres mais on continue d'appeler l'exécutable par défaut a.out. J'aimerais bien que ça sorte le nom du fichier sans son extension.

c99 bar.c
./bar

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

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

Non alpine est utilisable en desktop aussi, il y a même GNOME et KDE !

Évidemment il reste toujours des paquets pas forcément compatible ou manquant mais comme c'est super simple d'en rajouter ça va vite. D'ailleurs je suis la raison pour laquelle il y a beaucoup de jeux et d'émulateurs ;o)

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

• Alpine au quotidien, à laquelle je contribue
• La mienne sur laquelle je travaille (une dépêche sera faite cette année)

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

L’intérêt principal que j’y vois est que c’est décentralisé en très grande partie et résilient. Une forge peut disparaitre

Ça permet aussi de partager le coût de l’infrastructure

C'est mignon tout plein mais; c'est pas parce qu'une personne n'utilise pas GitHub ou tout autre forge qu'il va y avoir un impact écologique. Pour que le torrent marche, il faut que les gens laissent leur PC allumés et laissent le partage actif, est-ce réellement mieux ?

Mis à part le côté partage, je souligne surtout le fait que développer quelque chose d'opensource sans la possibilité de contribuer facilement c'est légèrement contradictoire.

Les projets mednafen et lua sont opensource mais avec un développement fermés et c'est bien dommage. Pour envoyer un patch, tu sais pas si tu es sur la dernière version ou non (en ayant téléchargé une version snapshot) donc si ça se trouve ton patch est plus obsolète.

Il n'y pas que la convivialité de voir le code en ligne et de ne pas attendre un temps variable de torrent, il y a la faculté de pouvoir cloner, mettre à jour, voir l'historique, créer des patch Mercurial ou git, etc. Surtout pour un projet qui est encore en travaux.

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