strlen-Funktion Funktionsweise

Es wird, die so genannte, "Pointer Arithmetik" verwendet.
Google, oder seine Brüder, sollten dazu was finden.
Auch gibt jedes C oder C++ Buch gerne dazu Auskunft.

Es wird beginnend vom String-Anfang gesucht, s wird auf die 
Anfangsadresse des Strings gesetzt:

1

s = str

Es wird so lange gesucht, so lange sich an der Position auf die s 
aktuell zeigt etwas ungleich 0 befindet:

1

*s

Dabei wird s nach jedem Test weiter gezählt, d.h. s zum nächsten Zeichen 
in str bewegt:

1

++s

Die Differenz aus der Position von s, an der das String-Ende gefunden 
wurde, und dem String-Anfang str ergibt die String-Länge:

1

s - str

Das ist wie üblich auch wieder mal so unleserlich wie nur irgend möglich 
formuliert.

gestartet wird mit s = str;
weitergemacht wird, solange  *s; nicht Null ist
und in jeder Runde wird  s inkrementiert:  ++s

Anschließend wird die Differenz von s und str als Ergebnis genommen.

simpler wäre das mit

1

 int laenge;

2

 laenge = 0;

3

 while (*s)

4

 { ++s;

5

   ++laenge;

6

 }

7

 return laenge;

8

9

10

oder wenn s passend deklariert ist

11

und die CPU gut indexiert zugreifen kann

12

13

 int laenge;

14

 laenge = 0;

15

 while (s[laenge]) ++laenge;

16

 return laenge;

Bei heutigen Compilern bin ich mir fast sicher, daß dank Optimierung bei 
beiden Versionen der gleiche Maschinencode herauskommt.

W.S.

Frank schrieb:
> return(s - str);


Die Zeigerdifferenz ist ja vom Typ ptrdiff_t.

die Funktion liefert size_t zurück.

Kann es hier Probleme geben?

zitter_ned_aso schrieb:
> Kann es hier Probleme geben?

Natürlich!
size_t ist vorzeichenlos.
Und die Differenz ptrdiff_t ist mit einem Vorzeichen behaftet.

Dein AVR(?) hat allerdings nicht soviel Speicher, dass das jemals 
greifen wird.

Hallo zusammen,

ich Danke euch für die Super Erklärungen !!!

Grüße

Frank

W.S. schrieb:
> simpler wäre das mit

Führe das mal auf einem 386-System mit einem String der Länge 3000000000 
aus. Oder auf einem AVR mit einem String der Länge 35000. Was fällt auf?

W.S. schrieb:
> Das ist wie üblich auch wieder mal so unleserlich wie nur irgend
> möglich
> formuliert.

Wir haben alle verstanden, dass du mit C auf Kriegsfuß stehst und daher 
in jedem C-Programm etwas unleserliches findest. Leserlichkeit liegt 
auch ein Stück weit im Auge des Betrachters, daher treffen da oft starke 
Meinungen aufeinander, die mit Fakten nur schlecht zu hinterlegen sind.

Allerdings verstehen Millionen Programmierer diverser 
Programmiersprachen for-Schleifen ebenso gut wie while-Schleifen. Deine 
Umschreibung macht es daher unleserlicher, weil die implizierte Aussage 
"Diese Schleife iteriert über..." verloren geht.

Und einen IMMO wesentlichen Leserlichkeitsfaktor hast du ausgelassen - 
statt

1

*s

würde ich auf

1

*s != '\0'

abfragen.

Und dein

1

while(BEDINGUNG) do;

ist unglaublich schlecht lesbar und sehr fehleranfällig bei Änderungen.

Nicht umsonst ist auch

1

while(BEDINGUNG)

2

{ do1;

3

  do2;

4

}

reichlich verpönt, weil dabei die geschweifte Klammer als Block-Beginn 
leicht verloren geht.

Dass das Mitzählen mittels separater Zählvariable neue Fallstricke 
einbaut, hat Dr. Sommer ja schon dargestellt. Demnach bin ich sehr 
sicher, dass deine Programme nicht den gleichen ASM-Code erzeugen wie 
eine funktionierende strlen-Implementierung.

MfG, Arno

Arno schrieb:
> reichlich verpönt, weil dabei die geschweifte Klammer als Block-Beginn
> leicht verloren geht.

Und wie ist das mit den geschweiften Klammern im Eröffnungspost? Die 
gehen wohl nicht verloren?

Walter T. schrieb:
> Irgendwie drückt ihr euch um die Erklärung, was an s jetzt
> konstant ist,
> wenn es doch inkrementiert wird.

s ist natürlich nicht konstant, sondern der Speicher, auf den s zeigt. 
So wird dem Leser der Funktionssignatur signalisiert, dass strlen() das 
Ziel des Zeigers nicht modifiziert. Außerdem kann man innerhalb der 
Funktion nicht so leicht versehentlich drauf schreiben.

Wollte man "s" selbst konstant machen, müsste man es "char * const s" 
schreiben. Aber das ist hier natürlich nicht Sinn der Sache und 
funktioniert nicht.

Walter T. schrieb:
> Irgendwie drückt ihr euch um die Erklärung, was an s jetzt konstant ist,
> wenn es doch inkrementiert wird.

Nicht s ist "const"ant, sondern das, worauf s zeigt. C Typdeklarationen 
werden von innen nach außen gelesen:

const char *s; --> s is a pointer to a constant character

Walter T. schrieb:
> Irgendwie drückt ihr euch um die Erklärung, was an s jetzt
> konstant ist,
> wenn es doch inkrementiert wird.

Das ist doch klar...
Der Pointer ist nicht konstant.
Er zeig nur auf einen konstanten Inhalt.

Ein konstanter Pointer auf einen konstanten Inhalt sieht so aus:
const char * const s = test; // C++

Jim M. schrieb:
> C ist eine uralte Sprache und eher auf Maschinenlesbarkeit denn auf
> Lesbarkeit durch Menschen getrimmt.

Das sehe ich anders. In Mathematik und Physik bevorzugt man auch kurze 
prägnante Schreibweisen und kommentiert das ggf.. Beispiele:

 * E=mc²
 * v=a*t

Ein Code mit "sprechenden Namen" wie oben ist für strlen einfach nur 
grauselig. In einem Lehrbuch oder Beispielcode schreibt man dann halt 
ran, was s ist und was passiert.

Frank M. schrieb:
> Aber tröste Dich: W.S. hat das auch nie verstanden.
Spassvogel!

Ob der String außerhalb der Funktion konstant ist, ist vollig egal.
Für das Innere der Funktion ist er konstant.

Der Kompiler schreit einen an, wenn man *s = 42; probiert.

Der Zeiger zeigt auf einen (für die Funktion) konstanten Inhalt.

Veränderung unterbunden === konstant

Das Schlüsselwort const dient dazu "Dinge" als konstant zu deklarieren.

Die Frage war:
"Wieso kann man einen const Zeiger ändern?"

Antwort:
Nicht der Zeiger wird als konstant deklariert, sondern das worauf er 
zeigt!


> Falsch.
Und jetzt sage nochmal: Falsch!

-------
Gerne darfst du mich falsch verstehen wollen!
Auch gerne in der Öffentlichkeit demütigen wollen.

> hat das auch nie verstanden.
Danke!

W.S. schrieb:
> simpler wäre das mit int laenge;
>  laenge = 0;
>  while (*s)
>  { ++s;
>    ++laenge;
> ...

Simpler für die Ausführung ist es, wenn man nicht zwei verschiedene 
Größen inkrementieren muss.

Manchmal ist Verarbeitungsgeschwindigkeit wichtiger als die geistige 
Unbeweglichkeit des geneigten Lesers.

my2ct schrieb:
> Manchmal ist Verarbeitungsgeschwindigkeit wichtiger

Aber nur ganz selten, in sicher weniger als 10 von 1000 Zeilen. Hier 
z.b. sind beide Varianten sicher gleich schnell.

Die Version mit 2 Inc ist nur einfach schlechter lesbar und schlechter 
wartbar (für einen Programmierer, nicht für einen Schüler)

Zeno schrieb:
> Arno schrieb:
>> reichlich verpönt, weil dabei die geschweifte Klammer als Block-Beginn
>> leicht verloren geht.
>
> Und wie ist das mit den geschweiften Klammern im Eröffnungspost? Die
> gehen wohl nicht verloren?

Die stehen für sich in einer eigenen Zeile, da passiert es deutlich 
weniger leicht, dass man sie überliest.

MfG, Arno

Viel Verwirrung hier kommt leider davon dass einige C nicht ausreichend 
beherrschen. Der Code oben ist grundsätzlich in Ordnung. Je nach Coding 
Guidelines KÖNNTE eine solche strlen Funktion aber unschön sein (z.B. 
würde ich empfehlen die Schleifenbedingung explizit zu formulieren als 
(*s != 0), da *s vom Typ her nicht direkt true/false ist.)

Die oben gezeigte strlen Funktion ist SEHR einfach. Und auch nicht 
sonderlich performant, besonders nicht für längere Strings auf allen 
Architekturen. Daher sollte man so etwas nicht explizit selbst schreiben 
sondern sich auf die optimierten Libs verlassen für den jeweiligen 
Prozessor.


(ich gehe im folgenden einfach mal von 32-bit ARM aus)
Das strlen oben operiert auf 8 Bit. Es wird pro 8 Bit ein Lesezugriff 
per Pointer durchgeführt. Die Maschine ist aber 32 bit breit. D.h. pro 
Transaction auf dem Bus würden 4 mal soviel Daten drüber gehen 
(=ineffizient!). Dazu kommt noch dass pro Zeichen eine 
Schleifeniteration gemacht wird was (je nach Branch Prediction 
Fähigkeiten) auch teuer sein kann. Zumindest wird viel gesprungen was 
Performance kostet.

SOWAS ist eine komplexe Strlen Funktion, die dann auch gar nicht mehr in 
C geschrieben wurde:
http://yann.poupet.free.fr/arm/optimized_strlen.html

Das operiert gleich mal auf 32 bit Worten und geht das geschickter an.