Il n'y a pas besoin de fonction de gestion de caractères pour donner un nom de fichier, il suffit juste de spécifier une convention pour ces fonctions. Avoir juste les primitive de gestion de fichiers était suffisant et aurait encouragé bien plus fortement l'utilisation des bibliothèques un peu plus haut niveau.
L'idée de base de bibliothèque standard était d'abstraire les quelques éléments spécifique au système qui ne font pas partit du langage, donc le minimum aurait suffit. Mais ils on quand même ajouté un peu plus histoire que l'on ne se retrouve pas trop nus. Résultat, il n'y a pas suffisament de fonction pour que l'on puisse ce passer de librairies mais il y en trop pour que ce ne soit vraiment qu'une couche bas niveau qui est à peu près tout le temps caché au programmeur.
Au final, on se retrouve dans une situation ou il y a suffisament de fonction pour que les programmeurs préfèrent recoder le peu qu'il manque et faire avec les problème de la stdlib, et donc aucune lib un peu plus touffue n'a réussie à s'imposer. Les deux son liés :
- pas de lib de bonne qualitée et répandue --> on fait avec ce qu'il y a et on recode le reste
- on fait avec et on recode --> les libs qui éxiste n'attirent pas assez de monde et se répandent peu
Le problème ce situe à l'origine et à mon avis on ne pourra rien y changer. Je suis le premier à faire avec la stdlib et à recoder pour la simple raison que actuellement, écrire un code en ansi/C est ce qui ce fait de plus portable. La quasi totalités des système éxistant disposent d'un compilateur ansi/C.
Le problème c'est que à peu près toutes les libs éxistante pas trop pourries reposent sur des extention du compilateur ou des éléments spécifiques à la platforme, donc on perd la portabilité. Mon choix est vite fait, j'ai ma petite collection perso de fonction et structure de données, et je repique dedans ce dont j'ai besoin.
Si seulement ils avait choisit de faire une lib complète ou pas de lib du tout au moment de la standardisation...
[^] # Re: Humm...
Posté par beagf . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 5.
L'idée de base de bibliothèque standard était d'abstraire les quelques éléments spécifique au système qui ne font pas partit du langage, donc le minimum aurait suffit. Mais ils on quand même ajouté un peu plus histoire que l'on ne se retrouve pas trop nus. Résultat, il n'y a pas suffisament de fonction pour que l'on puisse ce passer de librairies mais il y en trop pour que ce ne soit vraiment qu'une couche bas niveau qui est à peu près tout le temps caché au programmeur.
Au final, on se retrouve dans une situation ou il y a suffisament de fonction pour que les programmeurs préfèrent recoder le peu qu'il manque et faire avec les problème de la stdlib, et donc aucune lib un peu plus touffue n'a réussie à s'imposer. Les deux son liés :
- pas de lib de bonne qualitée et répandue --> on fait avec ce qu'il y a et on recode le reste
- on fait avec et on recode --> les libs qui éxiste n'attirent pas assez de monde et se répandent peu
Le problème ce situe à l'origine et à mon avis on ne pourra rien y changer. Je suis le premier à faire avec la stdlib et à recoder pour la simple raison que actuellement, écrire un code en ansi/C est ce qui ce fait de plus portable. La quasi totalités des système éxistant disposent d'un compilateur ansi/C.
Le problème c'est que à peu près toutes les libs éxistante pas trop pourries reposent sur des extention du compilateur ou des éléments spécifiques à la platforme, donc on perd la portabilité. Mon choix est vite fait, j'ai ma petite collection perso de fonction et structure de données, et je repique dedans ce dont j'ai besoin.
Si seulement ils avait choisit de faire une lib complète ou pas de lib du tout au moment de la standardisation...