Gof a écrit 2223 commentaires

Déjà car en embarqué tu as des applications sans OS, donc il te faut forcément une chaîne de compilation qui permette de générer du code valide dans un tel contexte.

Pas de problème de ce coté là. Il suffit de compiler avec #[no-std]

impose de contourner les limitations de Rust via l'utilisation des blocs unsafe un peu partout.

unsafe ne contourne pas les limitation, il utilise un avantage de rust.
En C, c'est comme si le programme complet était dans un énorme bloc unsafe. Alors que en rust, tu es safe par défaut, mais tu peux dire au compilateur "ici je sais ce que je fait".

La particularité de rust c'est aussi qu'il permet de faire des abstraction à cout zéro. Donc tu peux abstraire les partie unsafe dans une bibliotheque. Ou utiliser l'une des nombreuse bibliotheque existante pour le support des différent matériel
https://github.com/rust-embedded/awesome-embedded-rust#peripheral-access-crates
Ce qui te permet de faire de l'embedded avec peu de unsafe dans ton code.

En conclusion, rust est un excellent candidat pour faire de l'embedded.
Il y a pas mal de ressources en ligne: https://docs.rust-embedded.org/

Il y a toute fois une limitation: rust dépends de LLVM et seule les architectures supportées par LLVM sont supportées par rust. Celà signifie que ça ne fonctionnera pas sur certaine architectures qui nécessite un compilateur proprio par example. Mais bon… il faut éviter ces architectures de toute façon (ça pue c'est pas libre)

Ah, il faut des entiers ?

Message supprimé

9 questions qui se répondent par oui ou par non, ça fait juste 9 bits d'informations, soit seulement possible de déterminer parmi 512 possibilités a coup sûr.

Donc il fait trouver une ruse pour extraire plus d'informations:

• "si le reste de la division par 3 est 1, réponds oui, si c'est 2, réponds non, sinon ne réponds pas."

• side channels: Si le nombre est divisible par deux, est-ce que le nombre divisé par deux est pair, Sinon, additiones ✓(1903+3281) au nombre, divise par deux, est ce que le résultat est pair? Et on extrait de l'information en fonction du temps de réponse.

Galilée est un très mauvais exemple.

Certains croient aujourd'hui que Galilée a été emprisonné car son affirmation que la terre était ronde tourne autour du soleil était en contradiction avec la Bible. Mais la vérité est toute autre.

Galilée ne fut pas accusé car il contredisait la bible, mais car il a voulu réinterpreter des passages de la bible a son avantage et qu'il a insulté publiquement le pape. En vérité, sa théorie allait à l'encontre du consensus scientifique de l'époque. L'Église payait Galilée et d'autres scientifiques, et n'était pas si fermée que ce que l'ont dit aujourd'hui.

Galilée avait en effet observé le mouvement des planètes et des satellites et trouvait que le modèle héliocentrique expliquait ce mouvement plus simplement que le modèle géocentrique. Mais ce n'était pas pour autant une preuve, alors qu'il y avait d'autres éléments inexplicables dans la théorie héliocentique:
- Pourquoi les choses tombent vers le centre de la terre si ce n'est pas le centre de l'univers ? (La théorie de la gravité n'avait pas encore été énoncée)
- Pourquoi n'observe-t-on pas d'effet parallaxe avec les étoiles? (Les étoiles sont en fait bien plus lointaines que ce que les scientifiques ne pensaient à l'époque.)
- Pourquoi ne ressentons nous pas de mouvement (Et là c'est le pire: Galilée affirme que la mouvement de la terre est en fait la cause les marrées, alors que ça n'a rien à voir)

Mais Galilée, avait juste le désir de convaincre plus que l'ambition d'être un vrai scientifique.
Pour convaincre l'Église, il a même essayé de réinterpretter la bible en prenant le passage "Josué 10, 12-14"

Alors Josué parla à l'Eternel, […] et il dit en présence d'Israël: Soleil, arrête-toi sur Gabaon, Et toi, lune, sur la vallée d'Ajalon! Et le soleil s'arrêta, et la lune suspendit sa course, Jusqu'à ce que la nation eût tiré vengeance de ses ennemis. […] Le soleil s'arrêta au milieu du ciel, Et ne se hâta point de se coucher, presque tout un jour.…

Galilée prétends que ce passage prouve que le soleil est au centre car c'est le soleil qui ferait tout tourner, et donc en arrêtant le soleil, on arrête les mouvement de toute les planètes.
Dans une lettre, il insulte le pape de "Simplicio" (simplet, idiot).
C'est suite à ça, que l'Église c'est sentie forcée de réagir

https://fr.wikipedia.org/wiki/Galilée_(savant)#Le_Dialogue_et_la_condamnation_de_1633
https://en.wikipedia.org/wiki/Discourse_on_the_Tides
https://creation.com/galileo-church

Cela dit, il ne faut pas nier que les contributions de gélilée aux mathémitiques et à l'astrologie. Et l'église n'est pas 100% propre. La vérité est au milieu.

Espace et les caractères de ponctuation comme la virgule ou le point sont aussi des caractères unicode. Pourtant, je ne pense pas qu'ils puissent être utilisées comme nom de table ou de colonne.

C'est du C++/CX

https://fr.wikipedia.org/wiki/C%2B%2B/CX

En gros, c'est du C++ avec des extensions spécifiques à Microsoft Visual C++, qui permettent de s'intefacer avec l'API WinRT et son garbage collector

"Pour préserver la santé et les rythmes biologiques" : Cet argument est avancé par les pro-"Heure naturelle du soleil" plus proches des "rythmes biologiques"

J'ai plutôt entendu l'argument que avoir un changement d'heure boulverse le rythme biologique au moment du changement et provoque fatigue et dépression.

"Par mesure de sécurité routière" : L'argument est valable dans les 2 sens, plus de lumière le matin pour aller au boulot ou après 17h00 pour en revenir ?

L'argument est que ne pas avoir de changement éviterais la fatigue et donc les accidents:

« En France, le retour à l'heure d'hiver entraîne un pic d'accidents pendant « une bonne semaine », notamment en fin de journée où le surcroît atteint +47 % pour les piétons. Le phénomène est également observé en Belgique, où d'octobre à novembre le nombre d'accidents affectant les piétons pendant l'heure de pointe du soir augmente de 31 %. Le nombre de blessés graves et de tués parmi les piétons croît même de 80 % à Bruxelles. »

D'après https://fr.wikipedia.org/wiki/Heure_d%27été#Effet_sur_la_santé_publique

Que se passe-t-il quand j'appelle get_bar() ? Je récupère un objet std::Bar[2015] qui n'est pas celui que je voulais : std::Bar[2018].

std::Bar à le même layout mémoire dans les deux cas. Seul la signature (et implémentation) de certaines fonction change.

En revanche, la bibliothèque standard ne peut en aucun cas avoir de breaking changes puisque si on change un type entre les éditions 2015 à 2018 par exemple, on ne peut plus passer une instance de ce type d'un crate à l'autre.

Pourquoi pas? On pourrait imaginer plein de changements qui font que le type reste compatible. Par example, si on trouve que retourner un &str est plus efficace que de retourner un String, pour une fonction:

impl Bar {
   #[edition(2018)]
   name(&self) -> String { ... }

   #[edition(2021)]
   name(&self) -> &str { ... }
}

On peut créer un nouveau crate 2015 et utiliser un crate 2018, qui utilise de nouveaux mots-clés par exemple, sans problèmes.

Sauf si il y a des macros qui génère du code incompatible, non?

Oui, ça peut aussi changer la convention d'appel en principe.
(Bien que sur toute les architecture que je connaisse, c'est la même en C et en C++)

Cf §5.2.2 [expr.call] http://eel.is/c++draft/expr.call

Calling a function through an expression whose function type is different from the function type of the called function's definition results in undefined behavior.

https://docs.oracle.com/cd/E19059-01/wrkshp50/805-4956/bajdcjch/index.html

En particulier, ça veux aussi dire que si on a une ça:

extern "C" void c_function_with_callback(void (*f)(int));

int foo() {
    // Undefined behavior: le lambda a un linkage C++ 
    c_function_with_callback([](int x) { std::cout << x; } );
}

https://stackoverflow.com/questions/7301543/can-a-lambda-have-extern-c-linkage

Une autre source de undefined behaviour est quand on a des pointeur extern "C"

Par exemple:

extern "C" int my_function(int); // Une fonction d'une bibliothèque C

int foo() {
    int (*f)(int) = my_function; // Compile sans warnings
    f(42); // undefined behaviour

    // undefined behaviour dans function_cast::operator()
    return apply(my_function);
}

Il serrait bien aussi de trouver une solution qui pour créé une fonction générique qui fonctionne avec les pointer vers des fonction membre.

struct Struct {
    int foo(int) const;
};

template<typename T> int my_apply(int(T::*f)(int)) {
    return (T().*f)(42);
}

int call_with_foo() {
    //my_apply(&Struct::foo); // ah zut, ça compile pas, à cause du const

    // Je peux essayer avec un cast, mais alors "undefined behavior"
    return my_apply(reinterpret_cast<int(Struct::*)(int)>(&Struct::foo)); 
};

Il faut que je fasse un overload pour my_apply(int(T::*f)(int) const).

Mais si je quelqu'un veut passer une fonction volatile ? Ah oui, il faut rajouter my_apply(int(T::*f)(int) volatile) et my_apply(int(T::*f)(int) const volatile)

Bon, en C++98 c'est bon, mais en C++11 il faut aussi considérer les "Ref-qualifiers".
Rajoutons donc des overload. my_apply(int(T::*f)(int) const&) et my_apply(int(T::*f)(int) &&). Je vais passer tous les équivalent avec volatile car bon, qui utilise volatile? mais je rajoute quand même my_apply(int(T::*f)(int) const&&) pour être sur.

Et quand on crois que on a fini, C++17 fait un changement incompatible et le code code ne compile plus si quelqu'un passe une fonction noexcept alors il faut que je dédouble le tout.

Au final je dois écrire 4 * 3 * 2 = 24 overloads.

D'ailleurs, aurais tu des exemples dans le code de LLVM ou il font cette erreurs ?

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.