Warum sind Speicherfunktionen wie memset, memchr… in string.h, aber nicht in stdlib.h mit anderen mem-Funktionen?

Ich frage mich, warum solche Funktionen wie:
-Speicher
-memmov
-mechr
-memcpy

Existieren in der Headerdatei string.h, aber nicht in der Datei stdlib.h, wo es andere Standardspeicherfunktionen als dynamische Speicherzuweisung gibt: malloc, calloc, realloc, free.

Vielleicht wäre es besser, sie in einem Header zu vereinen? Was denkst du darüber? Ich verstehe nicht, warum ein Satz von Speicherfunktionen von anderen getrennt ist und im String-Header ( string.h ) existiert.

Denn eigentlich string.h ist als Standard-Header definiert, der Funktionen deklariert, die Arrays von Zeichen und nicht nur Strings behandeln. Funktionen wie memcpy und memset Nehmen Sie Argumente, die als Zeiger auf das erste Element eines Objekts vom Typ Array von Zeichen behandelt werden.

(C99, 7.21.1p1) Der Header < string.h > deklariert einen Typ und mehrere Funktionen und definiert ein Makro, das zum Manipulieren von Arrays vom Zeichentyp und anderen Objekten nützlich ist, die als Arrays vom Zeichentyp behandelt werden.

Ich würde nicht wirklich an die denken string.h Funktionen als “Speicher”-Funktionen. Stattdessen würde ich sie als “Array”-Funktionen betrachten, da sie mit den Daten arbeiten, die in Speichersequenzen enthalten sind. Im Gegensatz, malloc (und andere) tatsächlich Speicherdienste wie Zuweisung bereitstellen, anstatt die Daten innerhalb eines Speicherbereichs zu manipulieren.

Insbesondere die Funktionen in string.h Kümmern Sie sich nicht um die Zuweisung oder Freigabe von Speicher oder um irgendeine Form der Speicherverwaltung. Sogar eine Funktion wie char * strerror(int), die anscheinend eine ganz neue Zeichenfolge erstellt, führt keine Zuordnungen durch, da der Rückgabewert tatsächlich eine statisch zugeordnete Zeichenfolge ist. Die anderen Funktionen geben möglicherweise einen Zeiger auf einen Speicherblock zurück, aber dies ist eigentlich nur einer ihrer Parameter (z memcpy). Oder sie geben einen Zeiger auf den Anfang einer Teilzeichenfolge zurück (strtok) oder eine Ganzzahl, die einen Vergleich darstellt (memcmp).

Auf der anderen Seite, stdlib.h geht es auch nicht wirklich um Erinnerung. Die Gestaltung von stdlib.h ist es, Allzweckoperationen bereitzustellen, die wahrscheinlich von einer großen Anzahl von Programmen benötigt werden. Die Speicherfunktionen sind zufällig Beispiele für solche grundlegenden Operationen. Andere Funktionen wie z exit und system sind auch gute Beispiele, gelten aber nicht für das Gedächtnis.

Jetzt sind einige Funktionen drin stdlib.h in die IMO hätte platziert werden können string.hinsbesondere die verschiedenen Konvertierungsfunktionen (mbstowcs, wcstombs, atoi, strtodetc.), und vielleicht sogar die bsearch und qsort Funktionen. Diese Funktionen folgen den gleichen Prinzipien wie die string.h Funktionen (sie arbeiten mit Arrays, geben keine neu zugewiesenen Speicherblöcke zurück usw.).

Aber aus praktischer Sicht, auch wenn es viel Sinn machte, das zu kombinieren mem* funktioniert mit der malloc, realloc, calloc und free Funktionen ist die C-Standardbibliothek noch nie wird so umorganisiert. Eine solche Änderung würde definitiv den Code brechen. Ebenfalls, stdlib.h und string.h gibt es schon so lange und sie sind beide so nützliche und grundlegende Bibliotheken, dass die Änderungen wahrscheinlich den meisten (oder zumindest viel) C-Code beschädigen würden.

In Pre-Standard C waren diese Funktionen zwar woanders definiert, aber auch nicht in stdlib.h noch in einem der anderen Standard-Header, sondern in memory.h. Es könnte immer noch auf Ihrem System existieren, es ist sicherlich immer noch auf OS X (Stand heute).

memory.h unter OS X 10.11 (ohne Lizenzheader):

#include <string.h>

Die ganze Datei ist nur #include‘ing string.hum die Abwärtskompatibilität mit Pre-Standard-C-Programmen aufrechtzuerhalten.

Neben historischen Erwägungen ist die Trennung von Datenbearbeitungsprogrammen wie denen in string.h und Systemfunktionen wie malloc in stdlib.h macht sehr viel Sinn, wenn man Kontexte betrachtet, in denen ein Betriebssystem nicht selbstverständlich ist. Eingebettete Systeme können ein RTOS haben oder nicht und sie können eine standardmäßige verfügbare Speicherzuweisung haben oder nicht. Allerdings Dienstprogramme wie strcpy und memcpy Sie nehmen einen ähnlichen Platz ein, da sie nicht auf externe Systeme angewiesen sind und daher in jedem Kontext ausgeführt werden können, in dem Sie kompilierten Code ausführen können. Konzeptionell und praktisch ist es sinnvoll, sie zusammenzufassen und von komplexeren Systemaufrufen zu trennen.