sc
v1.0.4
Bibliothèques C et structures de données portables et autonomes. (C99)
Chaque dossier est autonome et contient une seule paire en-tête/source. Il n'y a pas
construisez pour les bibliothèques, copiez simplement les fichiers que vous voulez.
Par exemple, si vous voulez l'enregistreur, copiez sc_log.h et sc_log.c dans votre projet.
Il y a une couverture de branche à 100 % sous Linux et CI fonctionne sur
Système d'exploitation : Linux, MacOS, FreeBSD et Windows Compilateurs : GCC, Clang, MSVC Arch : x64, aarch64, armv6 (32 bits), armv7 (32 bits), ppc64le, s390x (big endian), riscv64 Désinfectants : désinfectants valgrind et clang/gcc (adresse, non défini, fil de discussion)
| Bibliothèque | Description |
|---|---|
| tableau | Tableau/vecteur générique |
| tampon | Tampon pour les variables de codage/décodage, mieux adapté aux implémentations de protocole/sérialisation |
| condition | Wrapper de condition pour Posix et Windows |
| crc32 | Crc32c, utilise l'instruction CPU crc32c si disponible |
| tas | Tas minimum qui peut également être utilisé comme tas maximum/file d'attente prioritaire |
| ini | Analyseur initial |
| liste chaînée | Liste chaînée intrusive |
| enregistreur | Enregistreur |
| carte | Une hashmap d'adressage ouverte haute performance |
| carte mémoire | Wrapper Mmap pour Posix et Windows |
| mutex | Wrapper Mutex pour Posix et Windows |
| option | Analyseur d'arguments de ligne de commande. Très basique |
| performance | Utilitaire de référence pour obtenir des informations sur les compteurs de performances via perf_event_open() |
| file d'attente | File d'attente générique qui peut également être utilisée comme retrait de file d'attente/pile/liste |
| sc | Fonctions utilitaires |
| signal | Snprintf sécurisé et gestionnaire de signal (gestion de CTRL+C, impression de la trace en cas de crash, etc.) |
| douille | Sockets Pipe / TCP (également sockets de domaine Unix) /Epoll/Kqueue/WSAPoll pour Posix et Windows |
| chaîne | Chaînes C avec préfixe de longueur et terminaison nulle. |
| fil | Wrapper de thread pour Posix et Windows. |
| temps | Fonctions de temps et de veille pour Posix et Windows |
| minuteur | Implémentation d'une roue de synchronisation hachée avec des opérations d'interrogation/annulation rapides |
| uri | Un analyseur d'uri de base |
Est-ce mieux que la bibliothèque X ?
J'utilise souvent ces bibliothèques pour des applications côté serveur hautes performances. Aussi,
Je me soucie d'un code lisible et facile à déboguer. En résumé, ces bibliothèques montrent
mes goûts (compromis) en matière de performances/conception d'API/lisibilité. Vous pouvez ou pouvez
pas comme ça.
Pourquoi ne changez-vous pas l'API ici chez X, pour qu'elle soit plus facile à utiliser ?
Envoyez une pull request s'il vous plaît, mais assurez-vous de ne pas introduire de nom indéfini
comportement. Il est possible de fournir de meilleures API, notamment aux bibliothèques génériques,
si vous ne vous souciez pas des comportements indéfinis. J'essaie de l'éviter.
Quelle est la manière la plus efficace d’utiliser ces bibliothèques ?
Comme n’importe quel autre code. Ajoutez à votre projet en tant que fichiers sources et utilisez idéalement
-O3 -flto + PGO. Cela ne fera peut-être aucune différence pour votre cas d'utilisation.
La bibliothèque X est-elle utilisée dans un produit ?
Certaines bibliothèques sont utilisées dans la production, mais veuillez toujours vous tester.
Y a-t-il une sortie ?
Veuillez utiliser la branche master. C’est considéré comme stable.
Allez-vous maintenir l’API stable ?
Ne vous attendez pas à une API stable. Ces bibliothèques sont assez
petit (la plupart d'entre eux contiennent moins de quelques centaines de lignes de code) et idéalement, vous
sont censés lire le code, comprendre ce qu'il fait et l'adapter à votre
besoins. Vous ne devez donc pas mettre à jour les bibliothèques aveuglément. J'attends de toi que tu gères
facilement toutes les différences possibles entre les API. Ceci étant dit, je ferai de mon mieux pour garder
API stable.
