StrToChar???????

[foxy]

Hi all ... ja ich weis das es nich so geht :lol:
nur meine Frage nu wie kann ich einen Str zu char machen???

[lodda]

Hallo foxy

das ist ganz einfach. Du kannst nämlich auf die einzelnen Zeichen zugreifen.

Delphi-Quellcode:

...
var s : string;
    c : char;
...
begin
  s := 'fsdf'
  c := s[0];
...

Damit bekommt c den Wert 'f'

[RomanK]

Hoi,
ein String (Zeichenkette) besteht aus mehreren Chars (zeichen) er ist ein sozusagen Array of Char. Wenn du ein Zeichen aus dem String haben willst dann mit

Delphi-Quellcode:

char := Str[Stelle];

[Edit]Shit, zu lagsam[/Edit]

[foxy]

waaa daruf hätt ich auch kommen könne ;) danke

[oki]

Holla!!

vielleicht habe ich was verpaßt, aber in String[0] steht die Länge!!

Das erste lesbare Zeichen ist doch String[1]!!
Natürlich nur so lange nicht fogendes dasteht:

Delphi-Quellcode:

MyString : Array[0..xxx] of Char

Gruß Oki

[CalganX]

Ähm... Wenn die Länge 9 überschreitet so kann in Str[0] nicht mehr die Länge stehen. Soll heißen: stimmt leider nicht. Eine Stringliste fängt ja auch bei 0 an.
Alles fängt bei 0 an. Delphi ist numal einer der 0-Anfänger... ;)

Chris

PS: Länge mit length(AStr: String);

[Sebastian Nintemann]

Hi, wieso kann s[0] nicht die Länge sein, wenn diese 9 überschreitet? Ein byte ist doch von 0 bis 255... Allerdings stimmts schon, dass man im Normalfall nicht mit s[0] die Länge bekommt, dies funktioniert nur bei Shortstrings (Länge: 255 Zeichen). Bei den Standardstrings musst du wie Chris gesagt hat mit length(s) die Länge prüfen falls sie dich interessiert, und das erste Zeichen kriegst du mit s[1].

Gruß, Sebastian

[sakura]

Beide falsch :!:

In Turbo Pascal (u.U. auch Delphi 1) stand im String[0] die Länge. Seit der 32 Bit Welt, steht die Länge dort nicht mehr, da sonst ein String maximal 255 Zeichen lang sein könnte. ;)

Dieser Zugriff ist nur noch für ShortStrings gültig.

String[0] ergibt eine Access Violation. Auch wenn bei Delphi fast alles bei null (0) anfängt, so ist das erste Zeichen in einem String immer bei eins (1).
...:cat:...

[lodda]

@ oki:
Ich glaube in Pascal bekam man mit String[0] die Länge des Strings heraus, weil ein Pascal-String auf 255 Zeichen beschränkt war.

@Chakotay1308:
Der String durfte in Pascal auch 10 Zeichen lang sein :D
String[0] ist ein Byte groß. Damit ist die maximal darstellbare Zahl 255

Zu spät

[CalganX]

Hi, aber wenn

Delphi-Quellcode:

type
  String = array[0..255] of char;

ist, dann stellt sich doch folgliches Problem: string[0] wäre, laut der gerade genannten Definition ein Char. Ein Char ist aber einstellig! Und nach 9 kommt 10. 10 ist zweistellig somit kein Char mehr.

Wenn es aber so ist, dass dies bei ShortString noch möglich ist, dann hätte ich gerne mal die Definition von String/ShortString!

Chris

[lodda]

Der Typ char ist nicht einstellig. Er ist geanu 1 Byte groß und geht damit von 0 bis 255

[sakura]

@Chakotay1308: Ich muss Dich erst einmal enttäuschen. Du hast da ein arges Verstädnisproblem.

Wenn ein String so definiert wäre

Delphi-Quellcode:

type
  String = array[0..255] of char;

, dann könntest Du immer noch auf die 100. Stelle mit StringName[100] zugreifen. Ohne Problem. Zusätzlich: Ein Char ist ein Byte groß, dass heisst, ess kann eine beliebigen Wert zwischen #0 und einschließlich #255 einnehmen.

Nun zum "AS-IS"
Ein String ist ein Pointer auf einen Block mit folgender Definition

Delphi-Quellcode:

type
  PStrRec = ^StrRec;
  StrRec = packed record
    refCnt: Longint;
    length: Longint;
  end;

Das dahinter die eigentlichen Daten stehen, versteckt Delphi vor uns, wie freundlich :)

Der ShortString hat keine direkte Definition, ist von der Logik aber wie folgt aufgebaut:

Delphi-Quellcode:

type
  // ObereGrenze liegt im Bereich von 1..255 (Standard=255)
  ShortString: array[0..ObereGrenze] of AnsiChar;

Du kannst Dir eigene Shortstrings definieren. Ein Datentyp ShortString der Länge 56 Zeichen wäre

Delphi-Quellcode:

type
  MyShortString56 = string[56];

[HAF68k]

das ist der eintrag von der delphi hilfe zum thema
mit der ORD-funktion.

Code:

uses Dialogs;
type

   Colors = (RED,BLUE,GREEN);

var

  S: string;
 begin
   S := 'BLUE has an ordinal value of ' + IntToStr(Ord(BLUE)) + #13#10;
   S := S + 'The ASCII code for "c" is ' + IntToStr(Ord('c')) +  ' decimal';
   MessageDlg(S, mtInformation, [mbOk], 0);
 end;

ich hoffe du hast das gemeint.
ansonsten meldest dich halt

[Sebastian Nintemann]

Noch einmal zum Thema einstellig:
Ein Char ist insofern einstellig, als das es nur einen Character (Buchstaben) aufnehmen kann, nämlich genau einen aus dem 256 (0..255) Zeichen umfassenden ASCII Alphabet. Zahlenmäßig gesehen ist ein Char (ein Byte) also keineswegs einstellig sondern kann Zahlen im Bereich 0..255 aufnehmen.

Gruß, Sebastian

[Hansa]

Hi,

da muß ich meinen Senf für die Nachwuchskünstler eben auch noch dazu geben. Auch um die Verwirrung wenigstens vollständig zu machen. :mrgreen:

Zitat:

Zitat von Grotesquery

Zahlenmäßig gesehen ist ein Char (ein Byte) also keineswegs einstellig sondern kann Zahlen im Bereich 0..255 aufnehmen.

Da werden keine Zahlen aufgenommen. Ein Char ist schon einstellig, weil es eben nur ein Buchstabe ist :!: Wie soll man aber 256 Buchstaben in einem einstelligen Wert unterbringen ? Ganz einfach : in einer Oktalzahl (=1 Byte). Die größte wäre dann eben 11111111, wobei die 1 je Stelle verdoppelt wird. 8 Einsen sind dann 1+2+4+8+16+32+64+128 = 255 im Dezimalsystem zuzüglich der Null, insgesamt also 256.

Stelle Dir a..z vor, dann hätte a den Wert 1 und z den Wert 26. Dann nimmst Du noch die Großbuchstaben, dann sinds schon 52. Dann noch die Umlaute, Zahlen, Punkt, Komma, blablabla. Dann sind es weit über 100. Deshalb sind die Zahlen mit Ihrem ASCII-Wert ("Oktalwert") gespeichert un belegen genau ein Byte. Maximal kriegst Du also 256 Zahlen in einer 8-stelligen Binärzahl unter. Da es aber auch Chinesen gibt, mußte das auf 65XXX erweitert werden. Das ist dann Ansi und die Codepages etc., da blick ich selber nicht genau durch.

Gruß
Hansa

[Chewie]

Zitat:

Zitat von Hansa

Maximal kriegst Du also 256 Zahlen in einer 8-stelligen Binärzahl unter. Da es aber auch Chinesen gibt, mußte das auf 65XXX erweitert werden. Das ist dann Ansi und die Codepages etc., da blick ich selber nicht genau durch.

Merkt man :mrgreen:
Ne, quatsch, ich kenn mich auch nicht so aus, aber meines Wissens ist ANSI die 8bit-Erweiterung von ASCII (7Bit). Die 16bit-Variante mit 65536 Zeichen heißt Unicode (das ist dann für die Chinesen :wink: ). Daneben gibt es noch Multibyte-Zeichensätze, die benutzen auf jeden Fall 7Bit, und falls das achte Bit einen bestimmten Wert hat, wird das nächste Byte auch noch mitbenutzt. Ist also komplizierter als DualByte (UniCode), aber platzsparender, da nicht immer zwei Bytes benötigt werden.

[sakura]

@Hansa
Ein Byte oder Char ist keine "Oktalzahl", da sich dieser Begriff auf das Oktalsystem bezieht. (Dezimalsystem: 0..9, Binaärsystem: 0..1; Hexadezimalsystem: 0..9,A..F; Oktalsystem: 0..7)

Genau genommen sind die Pascaltypen Char und Byte gleich. Intern (in Assembler) macht Delphi absolut keinen Unterschied zw. Byte und Char. Lediglich für uns Programmierer gibt es einen Unterschied.

[Hansa]

Hi,

Zitat:

Zitat von Chewie

Merkt man :mrgreen:
Ne, quatsch, ich kenn mich auch nicht so aus, aber meines Wissens ist ANSI die 8bit-Erweiterung von ASCII (7Bit). Die 16bit-Variante mit 65536 Zeichen heißt Unicode (das ist dann für die Chinesen :wink: ).

Unicode und Ascii: Für mich fast dasselbe. ASCII hat aber definitiv 8 Bit (vielleicht reden wir aneinander vorbei, es gibt auch extended ASCII, dann meine ich eben das)!!! für eben 256 verschiedene Werte.

Mit sieben Bit komme ich nur auf 128. Verdoppele ich ab 256 (8 Bit)wieder Achtmal und addiere dann gibt das 65XXX.

Gruß
Hansa

[Hansa]

Hi Sakura,

Zitat:

Zitat von sakura

Genau genommen sind die Pascaltypen Char und Byte gleich. Intern (in Assembler) macht Delphi absolut keinen Unterschied zw. Byte und Char. Lediglich für uns Programmierer gibt es einen Unterschied.

Ja, so ist das. Der Compiler setzt das Zeichen in seinen Ascii-Wert (oder sonstwas zurück). Mit diesem wird dann gerechnet, (SHL, SHR usw.). D.h., da werden die Funktionen ORD, CHR usw. automatisch aufgerufen, um uns die Arbeit zu ersparen. Ich wollte das lediglich einmal in Erinnerung rufen. Denn dadurch kommen auch Rundungsdifferenzen etc. zustande. Gerechnet wird eben letztenendes nur auf Basis von 0 und 1. Also Strom AUS oder Strom EIN.

Gruß
Hansa

[sakura]

Zitat:

Zitat von Hansa

Ja, so ist das. Der Compiler setzt das Zeichen in seinen Ascii-Wert (oder sonstwas zurück)

Der Compiler setzt gar nichts zurück. Wenn der Compiler es nicht verhindern würde, dann könntest Du folgendes tun

Delphi-Quellcode:

var
  B: Byte;
  C: Char;
...
B := 65;
C := 'A';
if B = C then
  ...

Der Lauf würde True ergeben, nur der Compiler erlaubt den Vergleich nicht!

Delphi-Quellcode:

var
  B: Byte;
  C: Char;
...
B := 65;
C := 'A';
asm
  Mov AL, B
  Mov AH, C
  CMP AL, AH
  JNZ @@OOPS
  ...
@@OOPS:

Das würde ohne Probleme gehen und True ergeben. Intern sind Byte und Char IDENTISCH.

Zitat:

Zitat von Hansa

D.h., da werden die Funktionen ORD, CHR usw. automatisch aufgerufen, um uns die Arbeit zu ersparen.

Schlußfolgerung aus oben. Der Compiler macht GAR NICHTS.

Zitat:

Zitat von Hansa

Denn dadurch kommen auch Rundungsdifferenzen etc. zustande.

Byte Ganzzahln wie Byte und Integer dies sind, kommt es nicht zu Rundungsfehlern!
...:cat:...

[Hansa]

Hi,

Zitat:

Der Compiler setzt das Zeichen in seinen Ascii-Wert (oder sonstwas zurück). Mit diesem wird dann gerechnet, (SHL, SHR usw.).

Was ist denn das anderes ? Was Du schreibst, genau das wollte ich sagen. Egal. Wir meinen dasselbe. :chat:

Gruß
Hansa :cat:

P.S.: Da ist ja noch was. :shock:

Zitat:

Byte Ganzzahln wie Byte und Integer dies sind, kommt es nicht zu Rundungsfehlern!

Bei Umwandlung Binär -> Dezimal bleibt das aber doch nicht aus ! Bei HEX ist das genau so. Wenn Du das hin kriegst und mir sagst wie, bin ich noch vor Dir auf dem Patentamt. :mrgreen:

[Chewie]

Zitat:

Zitat von Hansa

Hi,

Zitat:

Zitat von Chewie

Merkt man :mrgreen:
Ne, quatsch, ich kenn mich auch nicht so aus, aber meines Wissens ist ANSI die 8bit-Erweiterung von ASCII (7Bit). Die 16bit-Variante mit 65536 Zeichen heißt Unicode (das ist dann für die Chinesen :wink: ).

Unicode und Ascii: Für mich fast dasselbe. ASCII hat aber definitiv 8 Bit (vielleicht reden wir aneinander vorbei, es gibt auch extended ASCII, dann meine ich eben das)!!! für eben 256 verschiedene Werte.

Also die ASCII-Tabelle geht von 0 bis 127, enthält folglich 128 verschiedene Zustände und benötigt dementsprechend 7bit. Mit Hilfe des 8. Bit gibt es nun verschiedene Erweiterungen, wie z. B. zunächst ANSI und später diverse Abwandelungen für unterschiedliche Sprachen. Außerdem gibt es das Extended ASCII. Ich weiß jetzt nicht, welche Unterschiede es da zu ANSI gibt, da müsste man die Tabellen vergleichen. Gemein haben alle, dass die ersten 7 Bit mit ASCII identisch sind.

Zitat:

Zitat von Hansa

Mit sieben Bit komme ich nur auf 128. Verdoppele ich ab 256 (8 Bit)wieder Achtmal und addiere dann gibt das 65XXX.

Natürlich. Potenzierst du die 256 mit 8, kommst du auf 65536, also 2^16 = 16 Bit. Das ist dann Unicode.

[Christian Seehase]

Moin Hansa,

bei der Umwandlung von Zahlen von einem Zahlensystem in ein anderes kann es nicht zu Rundungsdifferenzen kommen, da bei der Umrechnung von einer Zahlenbasis in eine andere nicht gerundet werden muss.

Was Du meinst ist wohl die Genauigkeit bei der Berechnung von Gleitkommazahlen, da die Bereiche in denen diese gespeichert werden endlich sind, was allerdings dem Prinzip der irrationalen Zahlen wiederspricht. Diese können ja (z.B. ein Drittel) auch eine unendliche Anzahl Stellen haben.

[sakura]

Zitat:

Zitat von Chewie

Also die ASCII-Tabelle geht von 0 bis 127, enthält folglich 128 verschiedene Zustände und benötigt dementsprechend 7bit.

Keine Einwände. ASCII steht für American Standard Code for Information Interchange, Der Originalname für ASCII ist ANSI X3.4-1986

Code:

:: Definition (32-127)
  ! " # $ % & ' ( ) * + , - . /
0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z [ \ ] ^ _
` a b c d e f g h i j k l m n o
p q r s t u v w x y z { | } ~

Zitat:

Zitat von Chewie

Mit Hilfe des 8. Bit gibt es nun verschiedene Erweiterungen, wie z. B. zunächst ANSI und später diverse Abwandelungen für unterschiedliche Sprachen.

ANSI wird oft, fällschlicherweise, für die 8-Bit Codes genommen. ANSI ist jedoch die Abk. für: American National Standards Institute, die Vereinigung, welche den ASCII Code entwikelt hat (www.ansi.org)

Zitat:

Zitat von Chewie

Außerdem gibt es das Extended ASCII. Ich weiß jetzt nicht, welche Unterschiede es da zu ANSI gibt, da müsste man die Tabellen vergleichen.

Der ASCII-Code (oder auch US-ASCII), wie wir ihn heute nutzen, wurde 1986 entwickelt und festgeschrieben. Was viele ANSI Code nennen, ist der eigentliche 8-Bit Zeichensatz mit dem Namen ISO 8859-1

Code:

:: Definition (128-255)
  ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ * ® ¯
° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
à á â ã ä å æ ç è é ê ë ì í î ï
ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ

Zitat:

Zitat von Chewie

Gemein haben alle, dass die ersten 7 Bit mit ASCII identisch sind.

Leider nicht ;).
...:cat:...

[Chewie]

Na ja, ich hoffe, ein "Ausreichend" ist das noch :mrgreen:

[sakura]

Klar. Ich musste mich auch erst einmal schlau machen. Da ich die Einzelheiten auch nicht so genau wusste. War ein guter Anlass. Danke! :angle2:
...:cat:...

[Hansa]

Hi Chris,

Zitat:

Zitat von Christian Seehase

bei der Umwandlung von Zahlen von einem Zahlensystem in ein anderes kann es nicht zu Rundungsdifferenzen kommen, da bei der Umrechnung von einer Zahlenbasis in eine andere nicht gerundet werden muss.

Stimmt ! Handelt es sich um ganze Zahlen kann nichts passieren.

Zitat:

Zitat von Christian Seehase

Was Du meinst ist wohl die Genauigkeit bei der Berechnung von Gleitkommazahlen, .... Diese können ja (z.B. ein Drittel) auch eine unendliche Anzahl Stellen haben.

Ja, so ungefähr wollte ich das sagen. Bei einer Zahl mit unendlich vielen Stellen, gilt auch für Pi, nicht nur für Zahlen mit Periode :!: da muß für die Darstellung eben irgendwann gerundet oder abgeschnitten werden. Da wir jetzt schon beim Mathematik-Unterricht sind : Was hat das mit irrationalen Zahlen zu tun ? 1/3 und Pi sind für mich reelle Zahlen. Oder bin ich doch zu dumm ? :chat:

Gruß
Hansa

[CalganX]

Hi Hansa,
(endlich kann ich mal wieder was intellegentes sagen).
1/3 ist eine relle Zahl, da diese als Bruch dargestellt werden kann. Pi allerdings hat unendlich Nachkommastellen und kann nicht als Bruch dargestellt werden, da Pi in den Nachkommastellen kein Schema aufweist. Somit ist Pi eine irrationale und keine relle Zahl!!!

Chris

PS: Sqrt(2) ist ebenfalls irrational...

[Hansa]

Hi,

Zitat:

Zitat von Chakotay1308

Hi Hansa,
Pi allerdings hat unendlich Nachkommastellen und kann nicht als Bruch dargestellt werden, da Pi in den Nachkommastellen kein Schema aufweist. Somit ist Pi eine irrationale und keine relle Zahl!!!

Auch 1/3 hat unendlich viele Nachkommastellen. Ich sehe das ungefähr wie Sakura, es schadet nichs, sich mal wieder mit so etwas zu beschäftigen. Woher weißt Du das da überhaupt ? Sind die irrationalen Zahlen nicht die Wurzel aus -1 oder so? Wo die Zahl i als Rechenhilfe gebraucht wird ?

Jetzt habt ihr mich doch tatsächlich so weit gebracht, meine alten Mathebücher zu suchen. Das da wußte ich nämlich einmal ganz genau, wie das geht.

@Chako...: Das war, als Dein Vater noch mit Dir über die Hecken gesprungen ist. :mrgreen: Aber mach nur so weiter !!

Gruß
Hansa

[Chewie]

Zitat:

Zitat von Chakotay1308

Hi Hansa,
(endlich kann ich mal wieder was intellegentes sagen).
1/3 ist eine relle Zahl, da diese als Bruch dargestellt werden kann. Pi allerdings hat unendlich Nachkommastellen und kann nicht als Bruch dargestellt werden, da Pi in den Nachkommastellen kein Schema aufweist. Somit ist Pi eine irrationale und keine relle Zahl!!!

Chris

PS: Sqrt(2) ist ebenfalls irrational...

Wenn der letzte Satz lauten würde "Somit ist Pi eine irrationale und keine rationale Zahl", dann gäbe es von mir keine Einwände. Die rationalen und die irrationalen Zahlen bilden nämlich die Menge der reellen Zahlen.

[Daniel]

Nun mal kurz zu dem Zahlenmengen:

Die Menge der ganzen Zahlen
Beinhaltet alle ganzen Zahlen (positive wie negative Zahlen, die Null eingeschlossen). Diese Menge wird in der Mathematik i.A. mit 'Z' bezeichnet.

Die Menge der rationalen Zahlen
Beinhaltet die Menge aller aller Quotienten (a/b, | a,b aus Z ) ganzer Zahlen und wird in der Mathematik i.A. mit 'Q' bezeichnet. Mit der Einschränkung, dass nicht durch die 0 geteilt werden darf.

Die Menge der reellen Zahlen
Beinhaltet alle Zahlen, die sich auf einer Zahlengerade darstellen lassen und wird i.A. mit 'R' bezeichnet.

Wenn Du nun aus der Menge 'R' alle Zahlen rauswirfst, die Du mit 'Q' angededckt hast, erhälst Du die Menge der irrationalen Zahlen.

Dann bleiben noch die komplexen Zahlen, welche als 'a+b * i' definiert sind und i selber wiederum als Wurzel aus -1.

Dies als grober und nicht einmal vollständiger Überblick. :P

[CalganX]

Ooops, OK... Aber rational und irrational sind 2 verschiedene Sachen!!!

Aber die Wurzel aus -1 ist I (zumindest das ist richtig). Und I ist eine imaginäre Zahl. Die Wurzel aus -2 ist 2I, usw.
Nur zur Info: Die Achse der Imaginären Zahlen auf dem Zahlenstrahl ist sozusagen die Y-Achse. Sie geht durch die 0. Also ähnlich einem Koordinatensystem (Sozusagen wird der Zahlenstrahl 2Dimensional... ;) )
Bei den Imaginären Zahlen spricht man auch von den "Komplexen Zahlen".
Das Rechnen mit I und einer Zahl aus N ist recht kompliziert, und kann nicht als Zahl dargestellt werden! Nur auf dem Zahlenstrahl.

Chris

[EDIT]Mist! Zu spät.[/EDIT]

[Christian Seehase]

Moin Hansa,

einen hab' ich noch ;-)

Bei der Umwandlung von einem Zahlensystem in ein anderes kann auch bei Gleitkommazahlen nichts passieren, nur bei der Berechnung.

[nailor]

Zitat:

Zitat von Christian Seehase

Moin Hansa,

einen hab' ich noch ;-)

Bei der Umwandlung von einem Zahlensystem in ein anderes kann auch bei Gleitkommazahlen nichts passieren, nur bei der Berechnung.

:?: :?: :?:

[Christian Seehase]

Moin Nailor,

das bezog sich hierauf:

Zitat:

Zitat von Hansa

Hi Chris,

Zitat:

Zitat von Christian Seehase

bei der Umwandlung von Zahlen von einem Zahlensystem in ein anderes kann es nicht zu Rundungsdifferenzen kommen, da bei der Umrechnung von einer Zahlenbasis in eine andere nicht gerundet werden muss.

Stimmt ! Handelt es sich um ganze Zahlen kann nichts passieren.

[Hansa]

Genau das ist es :!: komplexe Zahlen.

Zitat:

spricht man auch von den "Komplexen Zahlen".

Das ist schon ein Unterschied.

Gruß
Hansa

[oki]

Hallo Leute,

vor vier Tage habe ich so ganz nebenbei eine Bemerkung zur vorliegenden Sache gemacht und heute erst wieder reinschauen können.

Erst hab ich schallend gelacht und jetzt traue ich mich kaum eure mathematischen Ausführungen zu stören.

Trotzdem kann ich es mir nicht verkneifen noch einmal zum eigentlichen Thema zu sprechen (auch auf die Gefahr hin, dass an dieser Stelle keiner mehr so etwas erwartet).

Ob ShortString oder nicht(erweiterter Syntax oder bla bla bla), solange ich folgendes definiere:

Delphi-Quellcode:

var MyString : String;
begin
  MyString := 'oki';

steht an der Stelle MyString[0] definitiv nicht 'o' !!!!!!

Delphi definiert Strings eben nun mal nach alten Pascalkonventionen.

Es ist auch föllig wurscht was 'unten' passiert, für jeden der da nicht so fitt ist gilt diese Regel. Wer sich nicht so gut mit Strings auskennt sollte auch nicht nach alter Verfahrensweise auf die Stelle Null für die Länge zugreifen (mach ich auch nicht / nicht mal bei ShortString).

Nun die Arrays!

Arrays sind nun mal Arrays und keine Strings und werden auch so behandelt!

Ein Array kann immer für den definierten Speicherbereich mit Werten gefüllt werden. Ohne Abstriche!

Wenn man typbezogen definiert muß mann das natürlich beachten. Umgeht mann das, muß natürlich wie beim Typecasting auf die Länge des Typs achten.
Also, im Speicher sieht mindestens folgendes gleich aus:
[delphi]

Array[0..255] of Char;
Array[1..256] of Char;
Array[0..255] of Byte;

[delphi]

[oki]

Ups,

ist mir hier doch alles abgeschmiert.

Ich bring es kurz zu Ende.

Definiert man Strings in Delphi muß man die alten Pascal-Konventionen beachten. String[0] ergibt definitiv nicht das erste Charakter!! So is dat nu mal.

Jetzt zu den Arrays.

Arrays sind für mich sozusagen definierte Speicherbereiche ohne Schnickschnak.

In Array [0.254] of Char passen eindeutig 255 Charakter oder eben auch 255 Byte. Punkt um!

Jetzt können wir auch wieder bei der Mathematik weitermachen.

(Alle Kommentare zu nullterminierten Strings habe ich mir an dieser Stelle verkniffen)

Schön wenn noch spaßige Antworten kommen,

bis dann

Oki