lib
1.0.0
Mis bibliotecas de encabezado único para C/C ++.
| biblioteca | la última versión | categoría | Loc | licencia | descripción |
|---|---|---|---|---|---|
| JSON.H | 1.00 | pasador | 848 | zlib | Parser JSON no asignado |
| sched.h | 1.00 | múltiples lectura | 699 | zlib | programador de tareas múltiples |
| web.h | 1.00 | red | 1455 | BSD | servidor web liviano |
| sdefl.h | 1.00 | compresión | 525 | dominio público | desinflar compresor |
| sinfl.h | 1.00 | descompresión | 320 | dominio público | desinflar descompresor |
Total de bibliotecas: 5
Líneas totales del código C: 4487
Windows no tiene directorios estándar donde viven las bibliotecas. Eso hace que la implementación de bibliotecas en Windows sea mucho más dolorosa que los desarrolladores de código abierto en los derivados de UNIX generalmente se realizan. (También empeora las dependencias de la biblioteca en Windows).
También hay un problema común en Windows donde se construyó una biblioteca contra una versión diferente de la biblioteca de tiempo de ejecución, que causa conflictos y confusión de enlaces. Enviar las Libs como encabezados significa que normalmente solo los compilan directamente en su proyecto sin hacer bibliotecas, por lo que eludir ese problema.
Hacerlos un solo archivo hace que sea muy fácil soltarlos en un proyecto que los necesite. (Por supuesto, aún puedes ponerlos en un árbol de biblioteca compartido adecuado si quieres).
¿Por qué no dos archivos, uno un encabezado y otro una implementación? La diferencia entre 10 archivos y 9 archivos no es un gran problema, pero la diferencia entre 2 archivos y 1 archivo es un gran problema. No necesita cremar o recargar los archivos, no tiene que recordar adjuntar dos archivos, etc.
Cada archivo tiene documentación, descripción básica de la USSAGE y ejemplos en la parte superior del archivo. Además, cada función API, las variables Struct y miembros también están documentadas. Finalmente, cada biblioteca tiene un archivo de prueba correspondiente dentro del directorio de prueba para ejemplos de trabajo adicionales.
Personalmente, uso principalmente C en lugar de C ++ y dado que quiero admitir tanto C como C ++ y C ++ no se pueden usar desde CI, por lo tanto, se centra en C.
Utilizo C89 en lugar de C99/C11 para su portabilidad entre diferentes compiladores y accesorios para otros idiomas.
