Pas d'accord. Ce n'est pas le rôle de la lib C ou de POSIX (pour la lib C :-)) d'avoir des fonctions de haut niveau.
La lib C offre le minimum pour tout faire. Ça fait bizarre comme phrase mais c'est le cas. D'ailleur il n'y a pas le choix, tout fini par passer par la libc avant de passer par le noyau.
Le but est la vitesse, la taille, la vitesse, la taille et la portabilité.
Pour les fonctions "dangereuses", c'est principalement pour des raisons historiques. Puis la libc GNU a la délicatesse de mettre un warning lorsqu'on utilise une fonction dangereuse et de vérifier les appels des fonctions à nombres de paramètres variables.
> sans parler des pbs de portabilité.
J'ai développé des programmes qui doivent tourner sur plusieurs Unix et c'est assez mineur (entre système Unix !). Il y a des difficultés beaucoup plus dure ailleur (make, le shell, l'édition de lien des librairies partager, etc).
Puis ces problèmes de portabilité sont les problèmes classiques de non respect de norme. D'ailleur tu peux aussi installer la lib C gnu si la lib C de l'OS (proprio forcément) t'emmerde.
Par contre, et on s'y attend, c'est beaucoup plus merdique avec Windows.
> je suis quand meme bien content d'avoir les fonctions fournies par la glib.
Moi aussi, et bien que je trouve la lib C bien foutu (compte tenu des objectifs/contraintes) je pousse tout le monde à utiliser Glib qui est beaucoup plus "confortable", sûre et portable.
PS :
J'invite à lire la doc de la libc (info libc) qui est l'un des meilleurs moyens pour faire connaissance avec Linux.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Pas d'accord. Ce n'est pas le rôle de la lib C ou de POSIX (pour la lib C :-)) d'avoir des fonctions de haut niveau.
La lib C offre le minimum pour tout faire. Ça fait bizarre comme phrase mais c'est le cas. D'ailleur il n'y a pas le choix, tout fini par passer par la libc avant de passer par le noyau.
Le but est la vitesse, la taille, la vitesse, la taille et la portabilité.
Pour les fonctions "dangereuses", c'est principalement pour des raisons historiques. Puis la libc GNU a la délicatesse de mettre un warning lorsqu'on utilise une fonction dangereuse et de vérifier les appels des fonctions à nombres de paramètres variables.
> sans parler des pbs de portabilité.
J'ai développé des programmes qui doivent tourner sur plusieurs Unix et c'est assez mineur (entre système Unix !). Il y a des difficultés beaucoup plus dure ailleur (make, le shell, l'édition de lien des librairies partager, etc).
Puis ces problèmes de portabilité sont les problèmes classiques de non respect de norme. D'ailleur tu peux aussi installer la lib C gnu si la lib C de l'OS (proprio forcément) t'emmerde.
Par contre, et on s'y attend, c'est beaucoup plus merdique avec Windows.
> je suis quand meme bien content d'avoir les fonctions fournies par la glib.
Moi aussi, et bien que je trouve la lib C bien foutu (compte tenu des objectifs/contraintes) je pousse tout le monde à utiliser Glib qui est beaucoup plus "confortable", sûre et portable.
PS :
J'invite à lire la doc de la libc (info libc) qui est l'un des meilleurs moyens pour faire connaissance avec Linux.