Gof a écrit 2210 commentaires

ils font ce qui les arrange avec les "undefined behaviours"…

Euh, non. LLVM est sensé être compilable avec GCC et MSVC.

Car ça ne résout pas le problème

int strange_apply(int (*f)(int) )
{
    std::function<int(int, int)> f1 = f; // Ne compile pas
    std::function<int(int)> f2 = f; 
    f2(1, 2); // ne compile pas.
}

Il est tout a fait possible de compiler Qt en statique avec la version « Communautaire ».

Qt est LGPL ça veux dire aucun problème si ton appli est libre (ce qui devrait être le cas, on est sur linuxfr après tout). Et même si ton appli est proprio, la LGPL le permet à condition que tu permettes à l'utilisateur de customiser Qt (ce qui peut être possible en fournissant les .o)

On se moque des applis Électron mais bon Qt n'est pas mieux.

Une application python packagée avec Qt peut faire 34Mo (d'après l'auteur du journal), alors qu'une application Electron fait minimum 120 Mo.

Donc Qt est ~4x mieux.

Je ne vois pas le rapport. Il est possible de faire des bindings combinant tout ces langages depuis pratiquement chacun de ces langages.

Je ne sais pas, peut-être pas. (Apparemment, il reste quelque bug dans le backend LLVM pour AVR). Ça dépends de ce que tu appelle « production ready ».

C'est pour ça que j'ai dit « Rust ou C++ ».
Si tu veux un langage stable et éprouvé, tu peux utiliser C++.
Si tu peux te permettre langage plus jeune et prometteur, mais donc forcément pas encore bien poli pour tout les cas d'utilisation, prends Rust.

Oui.
https://github.com/avr-rust

Sauf si tu fais de l'embarqué, sauf si tu veux toucher au matériel, sauf si tu veux des contraintes temporelles fortes.

Rust ou C++ fonctionnent très bien avec toutes ces contraintes.

Peut être une exception si tu vise une architecture ésotérique obsolete pour laquelle il n'existe qu'un compilateur C proprio et tout pourri. Mais on ne choisis pas une telle architecture pour de nouveau projets.

Avant de commencer mon troll, je tiens à préciser que ce n'est absolument pas une critique personnelle ou du projet. Ulfius représente un travail que je ne veux pas dénigrer.
À la question « Pourquoi tu fait ça ? », la réponse « Pourquoi pas ! » est complètement valide.
J'imagine que c'est les mêmes raison qui pousse certain à écrire un Serveur HTTP en Brainfuck ou à contribuer à la.wikipedia.org

Mais je ne peut pas me retenir de lancer un troll sur les langages de programmations.
En 2018, il n'y a aucune raison (mis à part le "fun") de commencer un projet en C.
En particulier, c'est même limite irresponsable d'écrire un serveur web en C, au vu des contrainte de sécurité.
En pratique, il existe suffisamment de langages récent et supérieur tel que C++, Go, Rust, Python, etc. pour faire ce genre de chose.

Alors pour le fun c'est vrai que ça peut être amusant d'écrire un web framework en C ou en Brainfuck, mais ce n'est pas un truc à utiliser en production.

et constexpr qui vient d'être introduit dans la norme.

Euh, faut pas exagérer. Ça fait au moins 10 ans que constexpr fut introduit. (Le Working Draft ISO de 2008 le contiens déjà).
C++11 n'est plus nouveau. C'est dépassé par plusieurs nouveau standards depuis.
Pareil pour l'initialisation avec {}

D'ailleurs, l'expression peut être simplifiée: Je pense que ceci devrai fonctionner.

constexpr frozen::map cached = {{Vs, F{}(Vs)}...};

À vérifier, mais le static me semble inutile ici puisque c'est une constexpr dont on ne prends pas l'addresse. (Ou alors le compilateur essaie-t-il quand même de recopier toute la map sur la stack?)
Et en C++17, ont peu omettre les types du templates s'il peuvent être déduits via des guide de déduction.

l'adresse du registre étant volatile, etc.

C'est le registre qui doit être volatile. Pas son adresse.
En faisant (uint16*)(adresse_registre) tu enlève le volatile du registre.
Le code correct serait peut-être:

uint16 val = *(volatile uint16*)adresse_registre;

(Ton code pourrait encore avoir le problème si tu a la même race condition deux fois de suite)

Note: Je ne connais pas Fushia, donc je peux me tromper. Corrigez moi si j'ai tord.

je vois mal Google se refermer et limiter les plateformes supportant Android

Oui mais:

• Fushia est libre, mais pas copyleft, permettant au constructeur de faire des fork non libre pour leur platforme.
• Fushia est un micro-kernel, donc à priori les drivers fonctionnent en user-space avec une ABI stable (spéculation de ma part). Ce qui permettrais au fabricant matériel de créé des drivers proprio (ou pas) qui n'ont pas besoin d'être mis à jour avec les nouvelles version du noyaux. (Contrairement à Linux ou tout les driver doivent être ajusté et recompilé si on veux mettre à jour.)
• (En plus, le Kernel est écrit en C++ qui est bien mieux que C (troll facile de ma part :-) ). et il est même possible de faire des drivers en Rust et en Go je pense)

Ces points pourrait favoriser un écosystème où il existerait plus de matériel mieux supporté (via des driver closed source) que sous Linux. Sans oublier la puissance de Google.

Peut être aussi que le plan de Google est de faire fonctionner l'userspace d'Android avec soit Fushia, soit Linux, au début.

Donc au final, je ne crois pas que ce soit un argument.

https://fr.wikipedia.org/wiki/Google_Fuchsia

N'oublies pas l'option -R de less pour les couleurs.

Perso, j'ai dans mon bashrc:

export LESS="-Rd"

Bon, je me reponds à moi même pour préciser que la spec a quand même un intérêt pour faire du code performant. Il faut avoir une idée de la taille des cache et tout ça. Mais c'est inutile pour éviter les undefined behaviour.

Undefined behavior ça corresponds a une interdiction dans le code de la route. Tu pourras tant que tu veux dire a l'agent qui t'arrête après avoir rouler à 180 km/h ou brûler un feu rouge, que tu as étudié le manuel de ta voiture et que il n'y avait personne, mais tu te prendra quand même une amande.

Je vais avoir besoin de savoir ce que tu appelle programme un peu complexe et aussi d'exemple d'undefined behavior qu'on ne peut éviter.

Un programme un peu complexe c'est à dire tout programme un peu plus utile que hello world.
Et des undefined behavior c'est, par exemple, overflow de signed integer, ou déréférence d'un pointeur invalide, ou un cast sur un mauvais type, ou une data race.

Il me semble que les undefined behavior du C correspondent à des cas très précis et le plus souvent documenté par l'implémentation.

Ne pas confondre « undefined behavior » et « implementation defined behavior ».
Si tu fait du C, la spec du hardware n'a aucun intérêt, sauf si tu utilise des extension genre asm ou autre intrinsics. Et en particulier, si tu crois que la spec du hardware rends les undefined behavior prévisible, tu fait une belle erreur.

À lire: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Rust à aussi ses chances en temps que language d'assembleur de haut niveau.

Le C est en effet un langage très simple (mais difficile à maitriser).

"simple" n'est pas très objectif, et est aussi assez limitant. D'ailleurs, le brainfuck est encore plus "simple" (et difficile à maitriser). Pourtant il ne prendra jammais la place du C.

Peu de mots clés

Rust a moins de mot clés que C (35 mot clé en Rust, 44 en C)

abstraction très légère

Pareil pour Rust.

norme peu contraignante laissant de grandes libertés aux compilateurs […]

Mais rends la tâche du programmeur extrêmement difficile car il est quasiment impossible de faire un programme un peu complexe qui n'a pas une « undefined behavior ».

Tout cela permet en C d'être facile à porter sur une nouvelle architecture matérielle

En effet. Mais comme il a été déjà dit, écrire un frontend pour LLVM n'est pas très dificile non plus.

Trouver quelqu'un qui a un niveau réel d'expertise en Rust, c'est autre chose.

Il suffit de recruter un programmeur C ou C++ et de le faire coder en Rust. Il s'adaptera assez vite.

Je suis plutôt d'accord avec toi, mais le commentaire auquel je répondait semble utiliser le terme "modèles de programmation parallèle" pour dire api de haut niveau, telle que les go-routines ou map réduce. d'où les guillemets.

Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).

Sur ce point je ne suis pas d'accord.
UB en C++ veux aussi dire que le compilateur peut faie n'importe quoi.

La rubrique « liens », c'est de la pollution numérique.

Les "modèles de programmation parallèle" simplifient un peu les choses, mais ça n'enlève pas le risque de data-races sur les données partagées.

Par ailleurs, en rust, Tu n'est pas non plus encourager à utiliser des thread directement. Tu utilise une des API de la librairie standard ou des différentes crate qui exposent des abstractions.

Tu remplaces new par make_unique, et tu n'as plus besoin de delete.
Quand tu passe ton pointeur à une fonction qui prends un raw pointer et qui garde l'ownership, utilise my_ptr.release().

Qu'on ne peut pas faire de trucs «sales» en Rust.

Bien sûr que si, on peut. Il suffit d'écrire unsafe { ... }, et tu peux faire tout les truc « sales » que tu veux. C'est bien ça la force de rust: par défaut le compilateur vérifie, mais quand tu es sur de ce que tu fait, tu peux utiliser unsafe.

il ne peut plus vérifier et on perd l'intérêt du langage

On ne perd pas l'intérêt du langage car on peut limiter les zones unsafe à quelques primitives de base (par exemple CurrentFrameAllocator, CurrentFrameBox<T>) qui est reviewé avec plus d'attention, alors que la plupart du code reste en safe.

Je la conaissait avec des sages sales dans un train:
https://web.archive.org/web/20130919012100/http://linux-sottises.net/math.php

Qt 5.6 est une version LTS, maintenue jusqu'en 2019

https://en.wikipedia.org/wiki/Qt_version_history#Qt_5