Salut' nal,
Dans la foulée, pas immédiate, des excellents articles de pulkomandy sur les évolutions du langage C, j'ai décidé de m'intéresser à… C11.
Oui seulement lui ; car ça fait peut-être déjà 12 ans, mais l'adoption du truc reste relativement récente…
En tant que développeur C++, revenir aux "bases" m'a fait du bien. Pas de références universelles à transmettre à travers des couches de templates, pas d'instanciation de générique avec un type privé, pas de surcharge-surprise des opérateurs…
([gueule]et pis j'ai récemment eu des échos des cours de C à l'univ et là… franchement ! On leur explique ni la pile ni le tas, "faisez des tableaux[1024] et ça passera", "_Tu utilises le "bool" de stdbool.h> ? C'est pas un peu trop récent ?"… RHaahaaaaa! Ça sent un mélange de condescendance et de naphtaline toussa… 🤬[/gueule])
Je te propose donc un petit composant, pas optimisé mais cependant fonctionnel et normalement thread-safe :
variant_list
c'est-à-dire une liste dynamique d'éléments hétérogènes, qui supporte : les Entiers, Booléens, Flottants et Chaînes.
L'intérêt est surtout qu'il démontre pas moins de 5 features du C11 ! Les voici :
1. macros _Generic
La principale innovation ! Ce code :
#define list_add(L, V) _Generic((V), \
int: list_add_int, \
bool: list_add_bool, \
double: list_add_float, \
char*: list_add_string)(L, V)
nous permet d'écrire :
list_add(l, 42); // entier
list_add(l, true); // booléen
list_add(l, 3.14); // flottant
list_add(l, "Toto"); // chaîne
un début -même timide- de polymorphisme en C, et ça régale !
2. Threads cross-platform
C'est quand même bien d'avoir des threads utilisables sur tous les OS…
#include "<threads.h>
typedef struct
{
...
mtx_t locked; // C11
}
mtx_init(&l->locked, mtx_recursive | mtx_timed);
mtx_lock(&list->locked);
...
mtx_unlock(&list->locked);
3. struct timespec
Alors ça c'est lié, même si ça paraît n'être qu'un type "temps" de plus. En fait ça permet de faire ça :
struct timespec ts; // C11
timespec_get(&ts, TIME_UTC); // heure actuelle...
ts.tv_sec += 1; // ... + 1 seconde
mtx_timedlock(&list->locked, &ts); // attend 1 seconde si c'est occupé !
et a sûrement été ajouté à la norme pour cette raison précise.
4. structs/unions anonymes
C'est une facilité qui permet de s'adresser directement au "contenu" des structs/unions à travers une hiérarchie, à conditions qu'elles n'aient pas de nom propre :
struct Value
{
union { int i; bool b; double f; char* s; }; // C11: anonyme
...
struct Value v;
v->i = 42; // comme si "i" était directement dans "v"
et dans notre contexte de "variant", on s'en sert bien sûr à mort 😉.
5. _Static_assert()
Du code C de test à la compilation ! Tant que les valeurs sont éligibles au static const :
_Static_assert(sizeof(NULL) == sizeof(void(*)()), "NULL n'est pas un pointeur, allô ?");
annonciation du futur "nullptr" de C23, nous sert notamment à vérifier le terrain pour la future surcharge:
double: list_get_float, \
char*: list_get_string, \
void*: list_get_Type)(L, V) // à faire !
qui nous permettra d'obtenir des infos sur les éléments sans variable ni réinventer la roue.
(C23 renomme en "static_assert()" et aura aussi "constexpr" qui permettra bien d'autres choses)
Voilatou !
Okazou, j'ai également fait une version bibliothèque du composant.
Je pense éventuellement le faire évoluer pour rajouter ce dont j'ai parlé ci-dessus, ainsi que les quantités d'arguments variables ("varargs") :
list_add(l, 42, true, 3.14, "Toto"); // autant d'arguments qu'on veut !
et peut-être même, un jour, de l'optimisation…
… sortie de la prod' où tout est plus rapide mais plus laid 😉 .
# Génération Z
Posté par sobriquet . Évalué à 8 (+7/-0).
Oh là là, tu utilises des // pour commenter du code C, à la place des /* */ ? C'est un peu cavalier quand même, ça ne passera pas sur tous les systèmes.
Blague à part, j'ai récemment accompagné un jeune à se préparer pour entrer dans l'école 42, et cette syntaxe aventureuse n'est pas acceptée. Elle est standard depuis 1999. Je cherche toujours une explication plausible…
[^] # Re: Génération Z
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+14/-1).
Si c’est la même explication que les règles idiotes de la « piscine » d’Epitech (~modèle de 42), le but pédagogique derrière est surtout d’être capable de programmer en respectant des règles arbitraires, et absolument pas d’apprendre à bien programmer (et on est pas censé continuer à respecter ces règles au-delà).
Quant à l’intérêt pédagogique réel (de ces règles comme de la « piscine » en général), je vous laisse seuls juges – mon avis ne peut pas s’exprimer ici sans tomber dans la grossièreté.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Génération Z
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Pourtant, on a tous du bien à dire de 42 😉.
Car le bien étant le juste milieu, il s'applique bien à la proportion de 50% des profils qui en sortent !
[^] # Re: Génération Z
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 14 mai 2024 à 08:13.
On me disait déjà ça dans mes cours, quand 1999 était pourtant trèèès passé 😄.
Je pense que c'est un conservatisme "de fait" qui s'appuie sur la transmission informelle plutôt que sur la normalisation formelle :
très peu fréquente et mal suivie en C, une tous les 10 ans ; en C++ c'est important et tous les 3 ans maxi.
Les profs de C reproduisent le code du Grand Schtroumpf ; pour les innovations ils considèrent que c'est pas chez eux et t'envoient vers leurs collègues Java qui savent pas compiler sans IDE ("t'en auras jamais besoin").
(au fait, on t'a dit que j'aimais pousser des [gueule] au fil de l'eau ?)
[^] # Re: Génération Z
Posté par groumly . Évalué à 5 (+3/-0).
Ouais, après, je suis pas convaincu qu’il y ait grand monde qui lancé
javacdirectement ces 15 dernières années. C’est même pas une question d’ide, tout le monde (y compris les ide) déléguent cette tâche à maven.C’est probablement techniquement possible de compiler la plupart des projets Java à la main, mais je suis franchement pas convaincu de l’intérêt.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Génération Z
Posté par Pol' uX (site web personnel) . Évalué à 5 (+4/-1).
Je l'ai fait dans l'encadrement de TP d'info. J'espère ne pas être seul, et que nous sommes légions. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
D'autant que les cas où ça pouvait permettre de faire très simplement des choses simples n'existent presque plus puisque tu peut "lancer" un fichier
.javasimplement avecSauf intellij et eclipse. Ils tentent d'être plus malins que maven et d'ailleurs ne cherchent pas à être trop lié à ce dernier mais ils ont une bonne intégration et tu n'a pas à savoir ce qu'ils font dans l'énorme majorité des cas. Tu manipule juste des pom.xml et c'est terminé.
Je pense que le commentaire au dessus parlait de cas de ne pas savoir ni compiler ni lancer le programme sans l'IDE. Je ne sais pas ce qu'il en serait aujourd'hui mais fut un temps si tu te laissais portait par l'IDE sans chercher à comprendre, tu cliquait juste sur un bouton play et tu n'avais aucune idée de ce qui se passait derrière.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par groumly . Évalué à 3 (+1/-0).
Ben, dans l’ensemble, c’est un javac de tout ce qu’il y’a sous main/src et main/test. Le problème, c’est les dépendances, et c’est pas IntelliJ/eclipse qui va les chercher, ça fait juste tourner un mvn.
C’est précisément mon point. Ça fait 20 ans que je fais du java professionnellement (la vache, ça pique!), je serais absolument incapable de builder mon appli a la mano. Et par dessus tout, ça serait complètement con.
Idem pour lancer l’appli à la main, mvn exec:java, et encore je vais me ramasser sur la syntaxe (je sais qu’il y’a un exec, mais probablement pas java, et je sais aussi que mes variable -D vont passer à la trappe).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Génération Z
Posté par Tarnyko (site web personnel) . Évalué à 7 (+5/-0). Dernière modification le 14 mai 2024 à 20:17.
En fait, c'est moins une question d'utilité (car moi aussi je me sers de l'IDE 24H/24) que de pédagogie.
Quand c'est ton 1er cours de Java, que tu demandes à ton prof comment compiler ton projet constitué d'un seul .java ; et qu'il te répond qu'il sait pas, que de toute façon on va utiliser Eclipse… Précision supplémentaire : il n'a pas non plus cité maven, ni gradle, ni aucun outil du genre.
Notre taf (qui est aussi pour certains notre passion) est basé sur des couches qui s'empilent.
Ne pas évoquer les couches de base, au moins durant la phase d'apprentissage, c'est rendre l'élève captif d'un empilement ad hoc qu'il sera incapable de reconstruire à sa façon si on le change de terrain. À mon humble avis.
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Je ne pense pas. Personne n'est captif d'un IDE. Celui au quel on pense tous avec java et un gros bouton play c'est eclipse. Projet libre pas relié à une entreprise et personne hors études se retrouve enfermé avec eclipse (au point où jetbrain - très peu présent dans le monde universitaire en tout cas français - a pu arriver et lui tailler des croupières). Parce qu'en fait c'est relativement simple. Le sujet de compiler du code java n'existe pas vraiment. Tu as des outils de builds différents mais qui se démarquent pour des choses autour de ça. pour ce qui est de compiler du java, c'est un sujet résolu (en bytecode tout du moins).
Tu as des IDE qui enferment : xcode par exemple, mais aussi les platefrome à la mode dans les années 90 (delphi ? smaltalk ?), mais dans le monde java je ne crois pas.
Je gèrerais un cours de programmation java, je préfèrerais probablement garder plus de temps sur du code que de prendre du temps d'une part qui ne leur servira quasiment que s'ils font du java et qu'ils apprendront en arrivant en entreprise très surement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 14 mai 2024 à 21:25.
Je pense qu'on ne va pas être d'accord là-dessus.
Notamment quand tu dis:
Résolu en pratique, d'accord.
Mais il y a bien un truc qui le fait, qui doit le faire, à un moment donné; et comment le fait-il ?
Ne pas répondre à cette question au moins une fois ; à mon sens, c'est un manquement majeur.
L'équivalent en TypeScript serait de ne pas expliquer qu'il existe un transpileur nommé "tsc" qui transforme les .ts (que le développeur écrit) en .js (que le navigateur charge).
On peut vivre sans, juste écrire le bousin, cliquer sur le bouton, et recharger la page ; mais ça ne permet pas de qualifier au titre d'expert AMHA.
En fait ça limite le développeur à la tâche d'écriture du code, sans notion de l'environnement en-dessous.
Et je dis bien "limite", sans doute parce que je considère ça insuffisant.
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 2 (+1/-1).
En fait (pour le cas de java) la question est tellement trivial que c'est vraiment facile à trouver par soit-même ou de se faire aider par un collègue ou ce que tu veux comme autre source d'information. Alors que comprendre ce qu'est l'orienté objet à la fin du module tu aura 30% de la promo qui ne le comprendront pas et tu vois des gens qui s'écharpe depuis des décennies dessus. Entre arriver à aider un peu plus 2 ou 3 élèves à comprendre comment utiliser le paradigme derrière le langage et en perdre 2 ou 3 avec de la technique je pense que mon choix est vite fait.
Les études ne forment pas des experts. Tu acquière l'expertise après des années de pratiques.
En fait tu ne prend pas en considération le contexte. Tu as un module il fait quelques heures, tu va voir comment avance les étudiants, il y a un moment où tu va devoir choisir tu retire quoi ?
Oui tu ne va pas former des cracks qui se vendront 70k en sorti d'étude, il y a des trucs qu'ils n'auront pas vu, des trucs qu'ils auront mal appris et des trucs qu'ils auront totalement oublié dans la semaine qui suit le diplôme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
D'accord, si le critère n°1 est le temps, pourquoi pas.
J'ai presque envie de troller en disant que pour ça, ce n'est pas du Java qu'il faut faire,
mais du Rust/C++/Swift 😁.
[^] # Re: Génération Z
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 15 mai 2024 à 07:54.
Je ne retire rien, je condense ou je demande une rallonge de temps.
Aujourd'hui un développeur qui sait programmer mais ne maîtrise pas la construction d'un projet (dépendances, gestion de version, CI/CD…), c'est aussi utile qu'un garagiste qui connait la mécanique mais ne sait pas utiliser une valise de diagnostic.
Nos métiers sont plus complexes, les formations doivent s'adapter.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 1 (+1/-2).
Condenser c'est à la fois retirer du contenu et perdre une partie de la promo. Pour ce qui est de demander du temps, je te laisse te confronter aux réalités d'une université.
Franchement non. Mon métier n'est pas drastiquement plus complexe qu'il y a 15 ans (et j'ai commencé par du JavaEE Oracle à tous les étages à du kubernetes on premise avec spring et vertx déployé dessus). Il a changé, mais de là à le présenter comme plus complexe c'est se fourvoyer amha.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par groumly . Évalué à 2 (+0/-0).
Ouais, comprendre la chaîne de compilation, c’est important. Mais aussi, pas tant que ça. Sur du java/javascript/python, y’a pas forcément grand chose de subtil, et en 20 ans, j’ai jamais eu un seul problème la dessus. Tout est dynamique, on s’en fout du layout en mémoire (sorti de trucs bizarres comme la serialization, mais c’est assez extrême comme example).
Sur un cours c/c++/objc/swift, la oui, ça me paraît indispensable, parce que ça va très vite te peter à la gueule si tu comprends pas ce qu’il se passe. Je suis le gars de service qui explique pourquoi le build a pété, pourquoi non, on va pas static linker une librairie dans 4 extensions, et pourquoi le runtime gueule comme un putois d’avoir des symboles en double à cause dudit static link de partout. Et me lance pas sur les Bitcode, le simulator meme sur un m1 est une arch différente, et non, tu peux pas juste linker, juste parce que la méthode existe dans les 2, le layout est pas le même et ça va te peter à la gueule.
Mais, aussi, je vois une armée de dev java/js/.net à côté qui s’en battent les steaks de leur chaîne de compilation et ont jamais eu le moindre souci en 15 ans de carrière. Disons que c’est un peu choquant pour les vieux de la vieille, mais dans ce monde moderne de runtime, bytecode et interpreteurs jit, c’est loin d’être le plus important.
Pour être tout à fait honnête, je préférerais de très, très, très loin qu’on arrête d’enseigner que l’oriente objet, c’est l’héritage, parce que ça fait beaucoup plus de dégâts que de ne pas savoir lancer javac à la mano. J’te jure, le prochain nouveau diplômé qui m’explique qu’une voiture c’est un véhicule, et que donc c’est polymorphique avec des camions, des motos et le vélo à petites roue de mon fils, je vais peter une durite.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 1 (+1/-2). Dernière modification le 14 mai 2024 à 23:39.
Souffler sur un pissenlit fais plus de dégât que de ne pas savoir lancer javac.
En fait la question c'est qu'elle est ton travail ? Est-ce que c'est écrire le code qui tire le mieux parti possible de l'architecture sur le quel il tourne ou est-ce que c'est par exemple le fait de sortir certaines fonctionnalités aux utilisateurs ? (vraiment il ne faut pas y voir du manichéisme de ma part les 2 ont de la valeur et c'est d'un côté ce que l'on te demande et de l'autre comment toi tu envisage ton travail) C'est ça qui devrait déterminer le runtime et le temps que tu alloue à chaque chose. Sachant que si tu as des dev c++ qui s'intéressent au hardware autant que des dev js, c'est pas garanti que l'on gagne grand chose sur le résultat final.
Bien sûr le monde n'est pas totalement figé, il n'y a pas longtemps en java j'ai pu gagner de la performance nécessaire en cas d'utilisation réel parce que je sais comment fonctionne le modèle mémoire du langage.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
J'ai travaillé sur des projets ou la chaîne de compilation sur les serveurs de build était obligée de lancer un Eclipse parce que les développeurs avaient écrits certains de leurs outils de build sous forme de modules Ant qui appelaient des API de Eclipse et ça ne marchait que dans le contexte de l'IDE.
Alors il n'est certainement pas nécessaire que tout le monde dans l'équipe comprenne comment ça fonctionne dans le détail, mais pour ce genre de choses, c'est peut-être pas mal d'avoir au moins une vague idée de ce qu'il se passe.
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 1 (+1/-2).
Mais là ce que t'es entrain de dire c'est qu'une équipe a fait le choix délibéré d'avoir un build sophistiqué. C'est un peu comme dire que ça peut être utile de connaitre perl parce que j'ai déjà vu une équipe faire son build en perl.
Surtout que ce qui est nécessaire c'est plus de connaitre le principe d'une CI que de comment tu lance javac qui ne va pas t'aider quand tu te retrouve devant une API d'eclipse amha
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par jyes . Évalué à 6 (+4/-0). Dernière modification le 15 mai 2024 à 15:02.
Je ne connais pas Java, mais je suis en désaccord assez profond à propos de Python. C’est bourré de subtilités, quand un script Python tourne, ça n’a rien d’évident de savoir où il est allé charger ses modules (pip système, pip utilisateur, conda, venv, etc) et quel interpréteur Python il utilise. Ta remarque me fait penser que tu ne dois pas beaucoup enseigner, parce-qu’un débutant qui a installé Spyder via Anaconda ou chargé son script dans VSCode a rarement la chance que son code tourne du premier coup, sauf éventuellement, s’il n’utilise aucun module que les plus courants et il n’a alors absolument aucune idée de ce qu’il fait (et par conséquent de comment faire fonctionner son script sur un autre ordinateur).
Déjà, après le clic sur la flèche verte de VScode ou Spyder, ce n’est pas évident pour tout le monde de comprendre quel est le dossier d’exécution du script. À l’inverse, si tu commences un cours avec un éditeur de texte, et en appelant explicitement
python monpremierscript.py, toutes ces notions apparaissent simplement et se comprennent facilement.[^] # Re: Génération Z
Posté par Lutin . Évalué à 6 (+4/-0).
Un xkcd pour illustrer ton commentaire:
[^] # Re: Génération Z
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 15 mai 2024 à 16:48.
Très bon 😁.
Sans sarcasme, mais quand même: pour avoir déjà pratiqué le serpent, l'"environnement Python stable et reproducible" est effectivement un challenge en soi.
Immpensable de faire des déploiements sans maîtriser les préfixes, les venvs, au pire les dockers qui vont bien.
[^] # Re: Génération Z
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Aujourd'hui la pratique consiste à utiliser un "équivalent" du binaire statique avec ce qu'on appel des fatjars (ou uberjar). C'est un zip qui contient ton code compilé (des fois le source), tes dépendances et un ou 2 fichiers qui décrivent le truc.
Sur un jar comme ça tu peux simplement faire
java -jar fichier.jaret c'est clos. Quel java ? Tu peux bien sûr fairejava --version, mais comme il n'y a pas de bibliothèque dans le JRE (hors la bibliothèque standard), ils sont tous interchangeables (tu as une suite de tests qui est là pour le vérifier).Tu n'a pas java ou pas la bonne version ? Tu le télécharge, le décompresse, set la variable
JAVA_HOMEdans le dossier que tu viens de créer et tu lance${JAVA_HOME}/bin/java.Comme java est de base très découplé du système ça n'est pas un gros problème.
Je dirais qu'en python tu dois faire des pieds et des mains pour te dépatouiller du système (avec les différentes formes d'env, etc) en java c'est les mainteneurs de distribution qui se tapent le sale boulot pour tordre java pour en faire des paquets systèmes (c'est pas la mère à boire mais tu sent que c'est pas fait pour).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Génération Z
Posté par jseb . Évalué à 6 (+4/-0).
Le fait que tu pétes une durite™, quand on te parle de l'objet véhicule, montre que c'est héritable.
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: Génération Z
Posté par fearan . Évalué à 3 (+0/-0).
je l'ai fait y'a pas longtemps pour vérifier certains comportements sur des classes de tests et valider des hypothèses.
Si tu fais un truc rapide hors ide, avec que quelques fichier, sortir maven ou autre sera bien plus chiant.
note bien doit aussi y'avoir moyen de passer par make et ses règle auto ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Génération Z
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
Diantre, j'ai commencé à coder en C en 1991, et j'utilisais déjà les deux syntaxes de commentaires, je crois les avoir toujours connues…
[^] # Re: Génération Z
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Il semblerait que les commentaires commençant par
//étaient présents dans BCPL, un des ancêtres du C, dès 1967 au moins: https://retrocomputing.stackexchange.com/questions/27834/which-computer-language-was-the-first-with-two-forward-slashes-for-commenLes commentaires sur plusieurs lignes
/* */quant à eux, semblent provenir de PL/I en 1964: https://pldb.io/concepts/pl-i.html ? (à moins qu'ils existent dans un langage plus ancien, ou bien qu'ils ne soient pas apparus dès le début de l'existence de PL/I).[^] # Re: Génération Z
Posté par Pol' uX (site web personnel) . Évalué à 3 (+2/-1).
Personnellement j'ai toujours connu les deux notations mais je suis plus jeune. :) Par contre j'ai appris dans un contexte où l'option
-ansiétait de rigueur.Adhérer à l'April, ça vous tente ?
# Notes
Posté par David Demelier (site web personnel) . Évalué à 4 (+2/-0).
Sous licence GPL, pour une bibliothèque c'est la plaie. Personne ne va l'utiliser, au pire LGPL.
En C23 tout cela devient des keywords, donc à éviter.
Bof, les C11 threads sont extrêmement limités. En vrai personne ne les utilise et on préfère pthread la plupart du temps (quand on a pas besoin de portabilité) parce que les C11 threads n'ont pas de read-write lock (comme pthread_rwlock) et c'est dommage car c'est quand même pratique.
Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial
perrornistrerror(errno).On a aucune garantie de ce qui s'applique avec ces threads (partage des signaux bloqués, etc).
Autre note en vrac, pourquoi des script shell pour compiler du code et pas un Makefile/ CMake ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Notes
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 14 mai 2024 à 09:44.
Hello David,
Merci pour ton comm, je prends ça dans l'ordre !
Très bonne remarque ! J'avais oublié ça en générant la version "library" de la chose.
Je regarde pour changer les headers et mettre un COPYING approprié dans le répertoire.
Excellente remarque également. Je vais les #ifdef-garder.
(NB: j'ai prévu une version C23 pour quand j'aurai accès à un compilo capable. Ça me permettra de tester toussa)
Je suis d'accord sur le fait que c'est une version appauvrie des pthreads (sur lesquels ils sont en réalité basés au runtime).
Perso je ne me sers pas de toutes leurs fonctions, sauf celle-là… dont l'absence me paraît absurde:
La version C11 "mtx_destroy()" ne renvoie rien… dans ces conditions, le seul contournement c'est de se discipliner ou -super lourd- rajouter une variable de synchro. J'ai choisi l'option 1 pour pas gonfler, mais dommage quand même…
(après mon opinion est que c'est bien de les avoir, même si le draft final est pauvre de fou)
Assez d'accord ; c'est là que j'ai réalisé que les messages "perror()" étaient figés dans le runtime. J'avais toujours cru qu'on pouvait les surchager… tu me recommandes quoi, fournir ma propre fonction ?
Etant une pure démo, CMake (que j'utilise couramment) était trop lourd, hors de question.
Un Makefile ça pourrait se faire, juste j'en ai pas écrit à la main depuis des plombes ! Je vais regarder…
(au pire j'ajouterai des $CPPFLAGS/$CFLAGS dans le script -pour que l'utilisateur puisse facilement surcharger les commandes)
[^] # Re: Notes
Posté par Nicolas Boulay (site web personnel) . Évalué à 8 (+6/-1).
gcc -M ou gcc -MM te génère ton makefile.
"La première sécurité est la liberté"
[^] # Re: Notes
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0).
Alors ça… alors ça !!!
[^] # Re: Notes
Posté par David Demelier (site web personnel) . Évalué à 3 (+2/-1).
Non ça génère des règles de dépendances en fonction des en-tête que tu as inclus. Donc si un fichier foo.c inclue foo.h alors foo.c sera recompilé en cas de modification de foo.h grâce à une règle que
gcc -MMD/gcc -MMva générer sous la forme :Cela est nécessaire pour garantir une recompilation du code source notamment pour assurer la compatibilité binaire. Sans ça, modifier une structure ou une fonction dans un entête ne provoquera pas la recompilation des fichiers dépendants, utilisant donc une version binaire non compatible.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Notes
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+1/-1).
oui donc il génère un makefile fonctionnel. Je ne comprends pas ou tu veux en venir.
"La première sécurité est la liberté"
[^] # Re: Notes
Posté par freem . Évalué à 2 (+0/-0).
Je suppose que le point est que ça ne génèrera pas un makefile qui gère les libs aussi souplement qu'un makefile à la main qui utilisera probablement pkg-config.
Je ne fait que supposer, ici.
Ma foi, je ne savais pas que c'était un format interprétable directement par make que ça crachais, je ne connaissais la fonctionnalité que grâce à la doc de ninja, je n'ai jamais eu la curiosité d'ouvrir ces fichiers. Merci de l'info.
[^] # Re: Notes
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
En fait les Makefiles bien écrits sont déjà auto-suffisant dès lors qu'on a pas trop besoin de portabilité et qu'on utilise
gccetclang,-MMDpermet de générer des règles automatiques pour les entêtes. On peut donc avoir un Makefile qui recompile tous les fichiers y compris ceux avec dépendances indirectes.On peut par exemple avoir un Makefile tout à fait correct pour compiler un projet sans écrire aucune règle, cela est encore plus flagrant quand on a un nom d'exécutable du même nom du fichier.
Avec GNU Make:
Démonstration:
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Notes
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0).
Mise à jour comme promis :
Par ailleurs pour tester tout ça, j'avais besoin d'une version méga-récente du compilo.
J'avais peur de galérer, mais en fait j'ai trouvé ça facilement :
- ici pour Debian/Ubuntu;
- ici pour RHEL/Fedora.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.