string in array of char kopieren

[alzaimar]

Äh.. hat jemand Muetze1's Beitrag gelesen? :mrgreen:

[himitsu]

ja und bei mir isses oftmals standardmäßig bis zum Release an :zwinker:

[gammatester]

Zitat:

Zitat von alzaimar

Äh.. hat jemand Muetze1's Beitrag gelesen? :mrgreen:

Natürlich haben wir Beitrag gelesen. Aber:

1. Geht es auch um einige Feinheiten in den anderen Implementationen

2. Muetze1' Code macht nicht was verlangt wird, zumindest bis Delphi 10 wird nicht der komplette String kopiert, sondern es wird beim 1. #0 abgebrochen, d.h von '123'#0'abc' kommt halt nur '123'#0 im array an. Das mag ja in den meisten Fällen erwünscht sein, ist aber zumindest nicht das, was gefordet wurde:

Zitat:

jetzt will ich die chars vom string in den array kopieren

.

[Muetze1]

Zitat:

Zitat von gammatester

2. Muetze1' Code macht nicht was verlangt wird, zumindest bis Delphi 10 wird nicht der komplette String kopiert, sondern es wird beim 1. #0 abgebrochen, d.h von '123'#0'abc' kommt halt nur '123'#0 im array an. Das mag ja in den meisten Fällen erwünscht sein, ist aber zumindest nicht das, was gefordet wurde:

Zitat:

jetzt will ich die chars vom string in den array kopieren

.

Bei seiner Forderung steht nix von 0 Bytes innerhalb des Strings. Von daher ist es fraglich dies gleich voraus zu setzen...

[gammatester]

Zitat:

Zitat von Muetze1

Bei seiner Forderung steht nix von 0 Bytes innerhalb des Strings. Von daher ist es fraglich dies gleich voraus zu setzen...

Das ist allerdings ein ziemlich komisches Argument, denn es würde auf alle Zeichen zutreffen. Was klipp und klar da steht ist "die Zeichen" also doch wohl alle.

[Muetze1]

Zitat:

Zitat von gammatester

Zitat:

Zitat von Muetze1

Bei seiner Forderung steht nix von 0 Bytes innerhalb des Strings. Von daher ist es fraglich dies gleich voraus zu setzen...

Das ist allerdings ein ziemlich komisches Argument, denn es würde auf alle Zeichen zutreffen. Was klipp und klar da steht ist "die Zeichen" also doch wohl alle.

Wir können uns noch stundenlang hier die Argumente um die Ohren hauen. Anscheinend stehst du ja drauf. Na dann hier mal ein weiteres von mir: Im normalen Umgang meinen die meisten mit "Zeichen" im Zusammenhang mit Zeichenketten eine Menge von Bytes exklusiv von Steuerzeichen (Ordinalwert < 32). Somit liesse sich eine Forderung erkennen in seinem ersten Beitrag, den meine Lösung erfüllt.

Grundlegend kann auch davon ausgehen, dass ein String seiner Bestimmung Verwendung findet, sprich: nicht als binärer Datencontainer. Aber nun gut, bitte unterbreite mir weitere deiner Argumente...

[gammatester]

Zitat:

Zitat von Muetze1

Wir können uns noch stundenlang hier die Argumente um die Ohren hauen. Anscheinend stehst du ja drauf.
...
Im normalen Umgang meinen die meisten mit "Zeichen" im Zusammenhang mit Zeichenketten eine Menge von Bytes exklusiv von Steuerzeichen (Ordinalwert < 32).

Nein, daruf stehe ich überhaupt nicht. Letztendlich kommt es darauf an, was der TE eigentlich will und was sein String enthält. Wenn Du allerdings weiter diskutieren willst (zB ob auch bei #13 und #10 analog zu #0 das Kopieren beendet werden soll), mach doch einfach einen neuen Thread auf. Vielleicht findet sich wer, der darauf steht.

Festzuhalten bleibt allerdings, daß StrPLCopy eventuell nicht den ganzen String kopiert (und es ist nützlich, wenn man das weiß). Und wie ich schon in #13 geschrieben habe, mag dieses Verhalten ja erwünscht sein.

Schönes Wochenende
Gammatester

[p80286]

Ähm *hust*

ich hätte da noch eine etwas andere Definition von String zu bieten. Der String enthält alle Zeichen, die ich in ihn hineinpacke incl #0,#9,#13,#10 usw.. Und da ich mit Delphi/Pascal programmiere erwarte ich, daß alle Zeichen von S[1] bis S[length(S)] verarbeitet werden.

Wenn eine API-Funktion (#0) einem da einen Strich durch die Rechnung macht, ist das ärgerlich und man sollte darauf vorbereitet sein, daß soetwas passieren könnte.

Es ist also wichtig zu wissen, ob die Daten in einem String interpretiert werden (z.B. Bildschirmausgabe, Ausdruck ) oder ob es sich bei dem String um einen reinen Datenkontainer handelt.
Wobei die Interpretation der enthaltenen Zeichen, ja stark Systemabhängig ist. So wurde unter DOS jedes Zeichen (#0..#255) auf dem Bildschirm dargestellt, während es unmöglich war alle Zeichen auf einem Drucker auszugeben .

Gruß
K-H

[Muetze1]

Zitat:

Zitat von p80286

Und da ich mit Delphi/Pascal programmiere erwarte ich, daß alle Zeichen von S[1] bis S[length(S)] verarbeitet werden.

Und dabei enttäuschen dich schon soviele SysUtils und andere VCL Routinen welche einen string als Parameter nutzen und intern auf PChar casten und damit diese schöne heile Welt deiner Erwartungen zerstören.

Zitat:

Zitat von p80286

Wenn eine API-Funktion (#0) einem da einen Strich durch die Rechnung macht, ...

Welche API Funktion?

Zitat:

Zitat von p80286

... oder ob es sich bei dem String um einen reinen Datenkontainer handelt.

Wofür der String nie gedacht ist - aber durch das interne Design missbraucht werden kann. Aber ein vielfacher Missbrauch wird dadurch natürlich auch wieder legal...

Zitat:

Zitat von p80286

So wurde unter DOS jedes Zeichen (#0..#255) auf dem Bildschirm dargestellt, während es unmöglich war alle Zeichen auf einem Drucker auszugeben .

Ja nee, is klar. Schonmal probiert? Die BIOS String Routinen (INT 10h) haben diese Zeichen nicht interpretiert und ausgegeben. DOS Funktionen (INT 21h) hingegen haben die Steuerzeichen serwohl interpretiert. Ein CR oder LF wurde richtig umgesetzt. Wenn du schon mit solchen Behauptungen herkommst, hol mal dein Assembler und dein 80c286 wieder raus und probier es aus...

[p80286]

Zitat:

Zitat von Muetze1

Und dabei enttäuschen dich schon soviele SysUtils und andere VCL Routinen welche einen string als Parameter nutzen und intern auf PChar casten und damit diese schöne heile Welt deiner Erwartungen zerstören.
.....
Ja nee, is klar. Schonmal probiert? Die BIOS String Routinen (INT 10h) haben diese Zeichen nicht interpretiert und ausgegeben. DOS Funktionen (INT 21h) hingegen haben die Steuerzeichen serwohl interpretiert. Ein CR oder LF wurde richtig umgesetzt. Wenn du schon mit solchen Behauptungen herkommst, hol mal dein Assembler und dein 80c286 wieder raus und probier es aus...

Vorschlag zur Güte:
in einem String sind Zeichen enthalten. Deren Natur ist es, daß sie interpretiert werden (sollten). Nicht umsonst gibt es den Begriff Steuerzeichen.
Und je nachdem welcher Font zur Darstellung/Interpretation benutzt wird werden unterschiedliche Zeichen auch gleich dargestellt, bzw. das gleiche Zeichen (Byte-Wert) wird unterschiedlich dargestellt. Aber man sollte sich bewußt sein, daß Routinen die mit Strings umgehen mal auf Zeichenebene und mal auf Byteebene arbeiten - z.B. beim Sortieren und/oder vergleichen. (Unicode und andere MultiByteZeichensätze lassen wir jetzt erst einmal außen vor)

was den Int10 und Int21 angeht, da muß ich zugeben, daß ich die beiden wann immer es ging umgangen hab' und gleich in den Videospeicher geschrieben hab.
(Aber das ist so alt, das es schon garnicht mehr wahr ist.)

Gruß
K-H