Nützliche C-Befehle
-
Und was macht diese Funktion genau?
kannst du mir ein Beispiel geben????Danke!
-
Sie verschiebt den Inhalt eines Speicherbereiches an eine andere Position -siehe man: memmove:
char s[]="Dies ist ein Test"; char buffer[20]; memmove(buffer,s,strlen(s));
-
CStoll schrieb:
char s[]="Dies ist ein Test"; char buffer[20]; memmove(buffer,s,strlen(s));
Sowas ist vollkommener Unsinn. memmove ist dafür gedacht, Speicherbereich A in Speicherbereich B zu kopieren, falls A und B sich überlappen. Wirklich "verschoben", so wie man es zB von Dateien kennt, wird nicht.
Zudem ist memmove imo relativ nutzlos. Wie ein Kopieren erfolgen muss, damit keine Fehler durch Überlappung entstehen, sofern sie denn überhaupt entstehen können, ergibt sich idR aus der Implementierung. Und dann kann man auch gleich entweder memcpy oder ein reverse_memcpy verwenden.
-
memmove(my_buffer, my_buffer + line_len, buffer_len - line_len);
In diesem Fall garantiert nur memmove einwandfreie Ausführung, memcpy nicht. Kommt sicher auf die interne Implementierung dieser beiden an, aber die kenne ich in den meisten Fällen nicht
-
groovemaster schrieb:
Wie ein Kopieren erfolgen muss, damit keine Fehler durch Überlappung entstehen, sofern sie denn überhaupt entstehen können, ergibt sich idR aus der Implementierung. Und dann kann man auch gleich entweder memcpy oder ein reverse_memcpy verwenden.
Klar, wenn du weißt, an welcher Seite eine Überlappung auftreten wird, kannst du dich entsprechend für memcpy oder reverse_memcpy entscheiden. Wenn du's nicht weißt, solltest du die Entscheidung lieber dem "Experten" überlassen (dafür gibt's memmove).
-
LordJaxom schrieb:
memmove(my_buffer, my_buffer + line_len, buffer_len - line_len);
In diesem Fall garantiert nur memmove einwandfreie Ausführung, memcpy nicht.
Der zweite Teil ist korrekt, der erste nicht. Ein reverse_memcpy garantiert ebenfalls einwandfreie Ausführung.
memmove ist eher für solche Sachen gedacht:memmove(buf + x, buf + y, len);
Aber wie ich schon sagte, aus meiner Erfahrung heraus, braucht man das so gut wie nie. Erstens kopiert man sowieso relativ selten Bereiche, die sich überlappen. Und zweitens gibt dann oftmals die Implementierung vor, in welche Richtung es geht. Deshalb finde ich nicht, dass es eine wirklich nützliche Funktion ist. Da ist zB memcpy deutlich nützlicher.
-
Will ja nicht nerven aber
Aus man memcpy:
The areas may not overlap. Use memmove(3) if the memory areas do overlap
Da mein Linux reverse_memcpy nichteinmal kennt und ich mich im Allgemeinen an der dokumentierten Funktion und nicht an der internen Implementierung (die sich ändern _könnte_) orientiere, finde ich memmove sehr wohl äusserst nützlich...
Ich brauche das eigentlich immer wenn ich aus Blocks fester Länge Zeilen herausfiltere (siehe Beispiel oben), da hier der zusätzliche Aufwand eines Ringpuffers das "Herumkopieren" IMHO nicht aufwiegt...
-
LordJaxom schrieb:
Will ja nicht nerven aber
Aus man memcpy:
The areas may not overlap. Use memmove(3) if the memory areas do overlap
Da mein Linux reverse_memcpy nichteinmal kennt und ich mich im Allgemeinen an der dokumentierten Funktion und nicht an der internen Implementierung (die sich ändern _könnte_) orientiere, finde ich memmove sehr wohl äusserst nützlich...
Es ist doch aber viel schicker eigene Funktionen zu basteln.
-
TactX schrieb:
Es ist doch aber viel schicker eigene Funktionen zu basteln.
Klar, man könnte auch bei jedem Auto wieder nen komplett neuen Motor entwickeln.
Gruß
-
LordJaxom schrieb:
Da mein Linux reverse_memcpy nichteinmal kennt
Was wohl daran liegen wird, dass es keine Standardfunktion ist. Deshalb schrieb ich ja auch
ein reverse_memcpy
LordJaxom schrieb:
und ich mich im Allgemeinen an der dokumentierten Funktion und nicht an der internen Implementierung (die sich ändern _könnte_) orientiere
Es ist zwar richtig, dass memcpy bei sich überlappenden Bereichen undefiniertes Verhalten hat. Was aber kein Hindernis ist, eine Implementierung zu schreiben, die immer vorwärts kopiert. Ist halt immer eine Kostenfrage, ob man dies macht oder den memmove Overhead in Kauf nimmt, obwohl er locker vermeidbar gewesen wäre.