Pourquoi les fonctions de mémoire telles que memset, memchr ... sont dans string.h, mais pas dans stdlib.h avec d'autres fonctions mem?
Je me demande pourquoi une fonction telle que:
- memset
- memmov
- memchr
- memcpy
Existe dans le fichier d'en-tête string.h, mais pas dans le fichier stdlib.h, où il existe d'autres fonctions de mémoire standard comme allocation dynamique de mémoire: malloc, calloc, realloc, free.
Peut-être vaudrait-il mieux les réunir dans un en-tête? Qu'est-ce que tu en penses? Je ne comprends pas pourquoi un ensemble de fonctions de mémoire est séparé des autres et existe dans l'en-tête de chaîne (string.h).
Parce qu'en fait string.h est défini comme un en-tête standard qui déclare des fonctions qui traitent un tableau de caractères et pas seulement des chaînes. Des fonctions comme memcpy et memset prennent des arguments qui sont traités comme des pointeurs vers le premier élément d'un objet de type tableau de caractères.
(C99, 7.21.1p1) L'en-tête <string.h> déclare un type et plusieurs fonctions et définit une macro utile pour manipuler des tableaux de type caractère et d'autres objets traités comme des tableaux de type caractère.
Je ne penserais pas vraiment aux fonctions de string.h Comme des fonctions de "mémoire". Au lieu de cela, je les considérerais comme des fonctions de "tableau", car elles opèrent sur les données contenues dans des séquences de mémoire. En revanche, malloc (et d'autres), fournissent en fait des services de mémoire tels que l'allocation, plutôt que la manipulation des données dans une région de mémoire.
En particulier, les fonctions de string.h Ne prennent en charge aucune allocation ou désallocation de mémoire, ni aucune forme de gestion de la mémoire. Même une fonction comme char * strerror(int), qui semble créer une toute nouvelle chaîne, ne fait aucune allocation, car la valeur de retour est en fait une chaîne allouée statiquement. Les autres fonctions peuvent renvoyer un pointeur sur un bloc de mémoire, mais ce n'est en fait qu'un de leurs paramètres (par exemple memcpy). Ou ils renvoient un pointeur au début d'une sous-chaîne (strtok), ou un entier représentant une comparaison (memcmp).
D'un autre côté, stdlib.h N'est pas vraiment une question de mémoire. La conception de stdlib.h Est de fournir des opérations à usage général dont un grand nombre de programmes auront probablement besoin. Les fonctions de mémoire se trouvent être des exemples de telles opérations fondamentales. Cependant, d'autres fonctions comme exit et system sont également de bons exemples, mais ne s'appliquent pas à la mémoire.
Maintenant, il y a certaines fonctions dans stdlib.h Que l'OMI aurait pu être placé dans string.h, En particulier les diverses fonctions de conversion (mbstowcs, wcstombs, atoi, strtod, etc.), et peut-être même les fonctions bsearch et qsort. Ces fonctions suivent les mêmes principes que les fonctions string.h (Elles fonctionnent sur des tableaux, ne renvoient pas les blocs de mémoire nouvellement alloués, etc.).
Mais d'un point de vue pratique, même si cela avait beaucoup de sens de combiner les fonctions mem* Avec les malloc, realloc, calloc et free fonctionne, la bibliothèque standard C est jamais va être réorganisée comme ceci. Un tel changement briserait définitivement le code. De plus, stdlib.h Et string.h Existent depuis si longtemps, et sont à la fois des bibliothèques si utiles et fondamentales, que les modifications briseraient probablement la plupart (ou du moins, beaucoup) de code C.
En pré-standard C, ces fonctions étaient en effet définies ailleurs, mais ni dans stdlib.h ni dans aucun autre en-tête standard, mais dans memory.h. Il pourrait toujours exister sur votre système, mais il existe certainement toujours sur OS X (à partir d'aujourd'hui).
memory.h sur OS X 10.11 (sans en-tête de licence):
#include <string.h>
Le fichier entier est seulement #include 'ing string.h, pour conserver la compatibilité avec les programmes C pré-standard.
Outre les considérations historiques, la séparation des utilitaires de manipulation de données comme ceux de string.h et des fonctions système comme malloc dans stdlib.h a beaucoup de sens lorsque vous considérez des contextes où un système d'exploitation n'est pas une donnée. Les systèmes intégrés peuvent avoir ou non un RTOS et ils peuvent ou non avoir une allocation de mémoire standard disponible. Cependant, les utilitaires comme strcpy et memcpy occupent un l'espace dans la mesure où ils ne dépendent d'aucun système externe et peuvent donc être exécutés dans n'importe quel contexte où vous pouvez exécuter du code compilé. Conceptuellement et pratiquement, il est logique de les regrouper et de les séparer des appels système plus complexes.