Lionel Debroux (./7379) :
En tout cas, mauvais point pour le langage d'implémentation: fournir une API externe en C reste bien sûr nécessaire pour des raisons d'interopérabilité, mais pour de nouvelles bases de code, continuer à tout écrire en C est de plus en plus inacceptable.

Le C grade quand même un avantage sur tous les autre langages: c'est qu'il y a des compilateurs C pour quasiment toutes les architectures existantes. Et comme Linux est en C, PipeWire est potentiellement portable partout ou est Linux.

Kevin Kofler (./7380) :
Pour moi, l'utilisation du C est un argument en faveur. Les alternatives n'ont pas la même efficacité en taille et en vitesse.

Non, il existe des alternatives compétitives sur ces points.
Le Rust par exemple est spécialement conçu pour permettre des performances similaires au C tout en garantissant un niveau de sécurité bien supérieur.
Le C++ peut avoir des performance équivalentes au C en taille et vitesse. Il a des fonction qui permettent une meilleure sécurité, mais ça demande quand même d'en faire bon usage, là où le Rust refuse de compiler tout ce qui peut aboutir à des UB (à moins d'utiliser un bloc "unsafe").

Folco (./7386) :
Euh oui, le fait de dire "on peut faire de la merde avec tel langage" est quand même léger, sachant qu'on peut en faire avec n'importe quel langage. Du C bourré de macros à n niveaux, ça peut très bien devenir imbitable par exemple.

En effet, mais le langage a son importance car il est clairement plus facile de faire involontairement du code dangereux avec certains qu'avec d'autres. On peut toujours se dire : "avec du bon code et des bons programmeurs, ça n'arrive pas", mais l'expérience prouve tous les jours que si, ça arrive.

Folco (./7389) :
Maintenant, j’al souvent lu qu’on peut faire du C++ propre en utilisant qu’un subset du langage.

En effet, Bjarne Stroustrup (le créateur du langage) travaille a définir un sous ensemble standard plus dont le bon usage pourrait être vérifié par les compilateurs. Mais c'est encore un travail en cours. A priori, ça limiterais pas mal les risques mais ne sera pas du niveau de ce que garantit Rust.

Warpten (./7396) :
Ben pareil sans qt en fait, t'as des bounds check dans les conteneurs de la STL

En effet, dans la STL, il y a deux syntaxes, avec et sans bound check. Mais ils ont eu la bonne idée de ne pas mettre de bound check sur la syntaxe la plus simple.

squalyl (./7398) :
c++ tu changes de version de gcc et toutes tes libs dynamiques deviennent inutilisables...

Dans le cas de PipeWire, ça ne serait pas un problème. Vu qu'il va falloir que la bibliothèque s'interface avec d'autre langages, Rust ou C++ utiliseraient l'ABI C de toute façon .

squalyl (./7398) :
C forever. bien écrit c'est pas plus dangereux qu'autre chose.

Si c'est bien fait, marcher en équilibre sur un fil à 10 mètres de haut sans protection n'est pas plus dangereux qu'autre chose non plus.

Sauf que c'est difficile de garantir le "si c'est bien fait", surtout quand il y a un facteur humain. Dans pratique, on sait que sur des bases de codes conséquentes, même avec des normes et des processus de relecture, on laisse toujours passer des erreurs. Donc si le compilateur peut de base empêcher toute une classe de problèmes, c'est toujours bon a prendre.