PureBoard

> wobei ich die von and51, so nicht nutzen wuerde, da sie viel zu unsicher ist
Wieso das denn?

Selbst, wenn ein leerer String übergeben wird, dann zeigt der Anfangspointer auf das Nullbyte, der Endpointer auf eine ungültige Adresse vor dem Anfangspointer (da ja pauschal 1 bzw. 2 Byte abgezogen werden).

Die Schleife wird aber in dem Falle nie ausgeführt, da sie immer dann abbricht, wenn der Endpointer vor den Anfangspointer wandert. Somit findet nie eine 'ungültige' Schreiboperation statt.

Solltest du eine andere Unsicherheit meinen, die ich hier nicht erkennen kann, erklär es mir mal bitte.


> man massiv Stringoperationen durchführen muss mit den Pointern besser gestellt ist
Natürlich steht man bei Stringoperationen mit Pointern (fast) immer besser da, weil man die Strings so direkt im Speicher manipulieren kann. Dabei kann man auch gut Strukturen (Structure, StructureUnion) einsetzen. Eine Stufe langsamer ist das Peeken und Poken z. B. mit PeekC() und PokeC() und ganz unten befinden sich die Stringfunktionen (FindString(), Trim(), Left(), RSet(), ...):

Stringfunktionen » Peek & Poke » Pointer



Ein allgemeines Wort zum Pointern

Dennoch ist ein wenig Vorsicht beim 'Pointern' angebracht, denn es schleichen sich auch bei 'geübten' Programmieren gern mal Logikfehler ein, die selten zu bestimmten Fehlern oder aber auch zu "Memoryleaks" (Speicherlecks) führen können. Das meint edel mit "unsicher". Auch ich habe diese Prozedur zwar geschrieben, aber nur selten genutzt; ich könnte also gewisse Sicherheitsaspekte übersehen haben, die beim wenigen Testen nicht auffielen. Diese Probleme haben die nativen Funktionen wie FindString(), Mid() oder StringField() nicht. Nicht, weil Fred sie programmiert hat, sondern weil sie schon tausend- oder millionenfach benutzt wurden. Fehler würden sehr viel schneller auffallen, gepostet und behoben werden.
Bei dieser ReverseString()-Funktion brauchst du dir allerdings keine Sorgen machen, denn die ist überschaubar und gut diskutabel. Selbst wenn ein Fehler drin wäre, wäre er nicht so gravierend, als das er gleich deinen Computer zerstören würde; die schlimmste Konsequenz wäre allenfalls ein Programmabsturz.

So viel zum Thema Pointern, dazu kann ich jeden nur ermutigen.

Die meisten der Stringfunktionen in PB sind schon optimiert, da bringen
Pointer dann auch nichts. Trim ist mit Sicherheit nicht langsamer als eine
Procedure mit Pointern. Wenn jedoch mehrere Trim geschachtelt sind, dann
kann sich ein Vorteil ergeben, da ja diverse Calls wegfallen und alles in
einem Abwasch erledigt wird.

Trim ist ein schlechtes Beispiel, aber Ihr wißt schon was ich meine

Du hast Recht, deswegen schrieb ich ja, dass man fast immer besser da steht, wenn man Pointer benutzt.
Und natürlich sind auch die PB-Funktionen performanceorientiert optimiert. Gute Beispiele sind ReplaceString() und Val(), die seit PB 4.00 von Fred kontinuierlich verbssert wurden und AFAIK von keinem bisher (in Sachen Schnelligkeit) geschlagen wurden.

Dennoch eignen sich nicht alle PB-Funktionen für alle Arten von Strings. Klar hantiert man meistens mit Strings im Bereich von 5 bis 500 Zeichen, dennoch müssen Stringfunktionen auch größere Datenmengen bewältigen können. Das gilt nicht nur für 1 KB oder 4 KB-Blöcke, sondern auch für mehrere hundert KB große HTML-Dateien oder sonstige Textdateien, die sehr schnell noch größer sein können.

Hier "versagen" die PB Funktionen manchmal (oft?), da die Daten eben "byVal" und nicht "byRef" übergeben werden - ein nicht gerade kleiner Faktor. Sieht man ja deutlich an diesem Thread (Pointer vs. Stringfunktionen).
Daraus kann man PureBasic bzw. Fred natürlich keinen Strick drehen, denn schließlich müssen 'simple' Funktionen wie Trim() oder LSet() auch für Anfänger leicht benutzbar sein.

> da die Daten eben "byVal" und nicht "byRef" übergeben werden
Alle Strings in PB werden byRef gehändelt
Es wird also nicht direkt eine Kopy übergeben, sondern ein Pointer zu einer
Kopie.

Naja, war mein erstes Mal, dass ich die Wörter "byVal" und "byRef" in diesem Forum in den Mund nehme...
Es sei mir vergeben^^
Aber du hast richtig erkannt: Ich wollte darauf hinweisen, dass das Erstellen besagter Kopie bedeutend viel Anspruch in Zeit nimmt.