Hello David,
Merci pour ton comm, je prends ça dans l'ordre !
Sous licence GPL, pour une bibliothèque c'est la plaie. Personne ne va l'utiliser, au pire LGPL.
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.
En C23 tout cela devient des keywords, donc à éviter.
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)
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
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:
while (pthread_mutex_destroy(&mtx) == EBUSY) {
// mutex encore verrouillé ailleurs, on attend pour détruire
}
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)
Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial perror ni strerror(errno).
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 ?
pourquoi des script shell pour compiler du code et pas un Makefile/ CMake
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 Tarnyko (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 2. 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)