Reservirtes Wort String und keins Integer

[jdelphi]

Joa wie der Tittel schon sagt.

Warum ist String ein Reserviertes Wort und Integer keins.

Wenn man bei Delphi eine String Variable definiert, erscheint String in Fett, da es ein Reserviertes Wort ist.

Wenn man allerdings Integervaribalen Definiert, wird Integer nicht Fett hervorgehoben.

[mkinzler]

Integer ist aber trotzdem ein reserviertes Wort. Auch wenn die IDE es vielleicht nicht erkennt.

[Popov]

Zitat:

Zitat von jdelphi (Beitrag 1260341)

Warum ist String ein Reserviertes Wort und Integer keins.

Wenn man bei Delphi eine String Variable definiert, erscheint String in Fett, da es ein Reserviertes Wort ist.

String ist nicht fett, weil es ein Variablentyp ist, das ist nur ein Zufall. Laut meiner Kenntnis ist String deshalb fett, weil es auch eine Funktion ist, z. B.

Delphi-Quellcode:

ShowMessage(String('Hallo'));
//

Gäbe es die Funktion nicht, wäre String als Variablentyp nicht fett.

Ob es nun diese oben genannte Funktion ist oder eine andere, das weiß ich jetzt auch nicht genau. Was ich aber ziemlich sicher weiß ist, dass String neben dem Variablentyp auch noch eine andere wichtige Funktion hat. Und deshalb ist es ein reserviertes Wort und fett. Nicht weil es ein Variablentyp ist.

[Stevie]

Das gabs schonmal.

[Medium]

Zitat:

Zitat von Popov (Beitrag 1260353)

Laut meiner Kenntnis ist String deshalb fett, weil es auch eine Funktion ist

Das kann nicht der wirkliche Grund sein. Eigentlich ist das in deinem Beispiel ein Cast, kein Funktionsaufruf. Da String (u.a.) aber Compilermagic nutzt, wird hinter den Kulissen mehr gemacht als bei einem Cast einfacher Typen. Semantisch ist es aber dennoch kein Funktionsaufruf, Casts sehen aber syntaktisch in Delphi genau so aus.

Wie der verlinkte Thread gut demonstriert ist der genaue Grund dafür nicht (mehr) wirklich offensichtlich. Ich schließe mich da aber der Theorie von dort an, dass es schlicht ein Relikt aus Zeiten ist, wo String und Array und File ziemlich die einzigen Typen waren, bei denen mehr passiert ist als stumpfes "interpretiere Register X als [Typ]", und diese daher eher als Sprachfeature galten. Würde man die Delphi Language heute erfinden, würde vermutlich keiner mehr auf die Idee kommen diese auf die Art hervorzuheben. Ein Fall von "ist jetzt halt einfach so" :)

[Dejan Vu]

Wie ich an anderer Stelle schon schrieb:
'string' ist ein Systemtyp, also ein Typ, der nicht durch andere Sprachelemente erzeugt werden kann, und damit integraler Bestandteil der Sprache => 'string' ist ein fett geschriebenes weil reserviertes Schlüsselwort. 'Integer' kann durch '..' dargestellt werden, ist also ein normaler Basistyp.

'Double','Single','Real' sind Records und werden deshalb syntaktisch wie 'Integer' behandelt.

'Char'... Mist... ist, öhm.. eine Ausnahme. :mrgreen: Wie auch..öhm.. 'Boolean'.

[mkinzler]

Zitat:

'Double','Single','Real' sind Records

:gruebel:

[himitsu]

Zitat:

Zitat von Popov (Beitrag 1260353)

String ist nicht fett, weil es ein Variablentyp ist, das ist nur ein Zufall. Laut meiner Kenntnis ist String deshalb fett, weil es auch eine Funktion ist, z. B.

Delphi-Quellcode:

ShowMessage(String('Hallo'));
//

Gäbe es die Funktion nicht, wäre String als Variablentyp nicht fett.

String ist keine Funktion.

Sonst müsste jeder CAST fett sein.

Delphi-Quellcode:

ShowMessage(SortString('Hallo'));
ShowMessage(AnsiString('Hallo'));
ShowMessage(FloatToStr(Double(1)));

Reservierte Wörter sivd einfach nur fest und lassen sich nicht für irgendwas Anderes verwenden. Sie sind halt nur für diese eine Funktion reserviert.

Delphi-Quellcode:

type
  Integer = Double;
  string = Integer;  // geht nicht

const
  True = False;
  False = 123;

var
  False: Integer;
  Integer: TObject;
  string: IInterface;  // geht nicht

Das mag vielleicht historische Gründe haben, aber meiner Meinung Nach sollte String kein reserviertes Wort sein.
Problem: Wenn man das jetzt ändert, dann sind Neue Codes womöglich nicht mehr mit alten Compilern kompatibel.

Genauso gibt es ein Problem, wenn man neue reservierte Wörter und Steuerzeichen einführt, wo dann alte Codes nicht mehr mit neuen Compilern compatibel sein könnten.
Siehe Generics, Attribute, ClassHelper, überladene Operatoren, anonyme Funktionen usw.

An der Liste etwas zu ändern ist halt nicht so einfach.



Witzig sind aber die reservierten Wörter, welche nur in einem bestimmten Kontext "reserviert" sind, wie z.B. Index.
Problem ist da, daß der Code-Highlighter das nicht ganz kappiert und das Wort auch dann fett schreibt, selbst wenn es da gerade nicht reserviert ist.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1260380)

Zitat:

'Double','Single','Real' sind Records

:gruebel:

Kannst Du sie als Record darstellen? Wie sind die Datentypen aufgebaut? Als Record. Das sind strings zwar auch, aber wegen dem Referenzzähler, der *vor* der Adresse der Variablen steht, kann man ihn nicht als Record definieren.

[himitsu]

Der String kann natürlich in einen Record rein.

PS: die Referenzzählung, das Encoding und die CharSize stehen vor den Daten. (nicht alles bei ShortString und WideString)
In der "Variable" steht nur der Zeiger auf die Daten (beim LongStrings zeigt der Zeiger aber auf das erste Char und davor verstecken sich diese Zusatzinfos, so, wie bei TClassvor beim Zeiger noch Daten liegen ... es gibt je einen festen Index nach vorne und zurück, für bestimmte Informationen)

Bei Strings, Objekten, Interfaces gibt es den darstellbaren "inneren" Record und außen einen "Record" nur mit einem Pointer drin, wenn man es unbedingt so darstellen will.
Beim Variant wird es dann noch schlimmer. (ein bis zwei Records)

[Sir Rufo]

Es liegt wohl daran

Delphi-Quellcode:

var
  Str : string;
  Str10 : string[10];

Sowas gibt es nur bei

Delphi-Quellcode:

string

und dadurch fällt der wohl in die gleiche Kategorie wie

Delphi-Quellcode:

array

.

Historisch gesehen wurde

Delphi-Quellcode:

string

mit Turbo Pascal 6.0 ein reserviertes Wort.

[himitsu]

Wobei das ja eigentlich "falsch" ist

Es müsste eigentlich

Delphi-Quellcode:

Str10; ShotString[10];

heißen, aber man dachte sich, bei der Umstellung auf die LongStrings, daß es weniger probleme mit Altcode gibt.
Drum ist String[x] auch immernoch ANSI, obwohl der String nun ein Alias für den UnicodeString ist.


Meine Vermutung:

String war früher mal nur der jetzige ShortString und die LongStrings oder den WideString gab es noch nicht.

Im Inneren ist der String ein Record und so dachte sich der Niklaus ich mein natürlich den Herrn Wirth, daß eben reserviert zu machen, genauso wie den Record und das Array.

Delphi-Quellcode:

type
  ShortString = record
    Byte: Length;
    Chars: array[1..x] of AnsiChar;
  end;
  
  // oder
  ShortString = record
    Chars: array[0..x] of AnsiChar; // 0 = Länge
  end;

  // oder
  ShortString = type array[0..x] of AnsiChar; // 0 = Länge

Die Idee war vielleicht nicht die Beste und man hätte sich das, mit Einführung der LongStrings, vielleicht nochmal überlegen sollen, aber das ist nunal so ... Pech gehabt.


Fatit:
Fette Wörter haben absolut nichts damit zu tun, was sie sind oder machen, sondern es geht nur darum, daß es Wörter/Befehle mit einer definierten Funktion sind und Dieses sich (niemals) ändern wird.

[Sir Rufo]

Zitat:

Zitat von himitsu (Beitrag 1260395)

Drum ist String[x] auch immernoch ANSI, obwohl der String nun ein Alias für den UnicodeString ist.

Die Doku ist da anderer Meinung
http://docwiki.embarcadero.com/RADSt...Typen_(Delphi)
(es sei denn du meinst mit ANSI die 8-bit Zeichen)

[DeddyH]

Wieso anderer Meinung?

Zitat:

Bei Variablen, die auf diese Weise deklariert werden, wird dem Typ nur so viel Speicherplatz zugewiesen, wie für die angegebene Länge plus ein Byte erforderlich ist.

[himitsu]

Für Delphis automatische Konvertierungsfunktionen ist in ShortStrings die CP_ACP drin, also das, was standardmäßig auch im AnsiString drin steckt.
(selbst wenn man in Beides auch was Anderes reinmachen könnte)

[Popov]

Zitat:

Zitat von Medium (Beitrag 1260368)

Zitat:

Zitat von Popov (Beitrag 1260353)

Laut meiner Kenntnis ist String deshalb fett, weil es auch eine Funktion ist

Das kann nicht der wirkliche Grund sein.

Ich hab ja auch geschrieben, dass ich mir nicht ganz sicher bin wegen welcher Regelung es fett ist, es soll aber nicht fett sein, weil es ein Variablentyp ist. Den Grund - vorausgesetzt derjenige wusste was er schrieb - habe ich vor zig Jahren in einem Buch über Pascal gelesen. Ich kann mich jetzt aber auch nicht erinnern was es war. Die Aussage war aber dort - String wird als Begriff mehrfach genutzt, einmal als Variablentyp-Bezeichnung, aber auch für etwas anderes. Danach wäre der Variablentyp String selbst kein reserviertes Wort, der String für die andere Nutzung aber schon. Und da man einen Begriff nicht mal als reserviertes Wort haben kann, dann aber wiederum nicht, ist String allgemein ein reserviertes Wort.

Ob es stimmt, weiß ich nicht, zumindest habe ich es so gelesen. Und für mich klang es damals logisch.

[Medium]

Das war dann bestimmt die o.g. Benutzung als ShortString mit Längenangabe á la Array, welches ja auch fett ist. Dass die anderen Stringtypen diesem Schema nicht folgen könnte daran liegen, dass diese erst später hinzu kamen, wo man die Idee möglicherweise wieder verworfen hatte.

[himitsu]

Zitat:

Zitat von Popov (Beitrag 1260440)

Und da man einen Begriff nicht mal als reserviertes Wort haben kann, dann aber wiederum nicht, ist String allgemein ein reserviertes Wort.

Möglich wäre das schon.
- nur reserviert Worte neu einzuführen oder freizugeben ist nicht so leicht Möglich (siehe meine Begründung im letzten Post)
- und wie beim

Delphi-Quellcode:

Index

kann man Wörter auch kontextsensitiv steuern (hier ja und dort nicht)

Aber vorallem Code-Parser, wie hier z.B. der Code-Highlighter im Forum, hätten damit Probleme, da hier oftmals nur Code-Teile vorliegen und somit der Kontext nicht immer bestimmt werden kann.
Und selbst der Code-Highlighter im Delphi schafft es nichtmal das Index immer richtig darzustellen.
Auch bei IFDEFs im Code ist es nicht immer einfach, wenn man den aktuellen Status der Definitionen nicht bestimmen kann.

[Perlsau]

Zitat:

Zitat von jdelphi (Beitrag 1260341)

Wenn man bei Delphi eine String Variable definiert, erscheint String in Fett, da es ein Reserviertes Wort ist.

Tatsächlich wird ein String deshalb fett dargestellt, weil du das unter Tools/Optionen so eingestellt hast. Willst du auch einen Integer fett darstellen, kannst du das ebenfalls einstellen.

[DeddyH]

Ich verstehe die Einstellung so, dass reservierte Wörter fett dargestellt werden sollen. Damit auch integer fett würde, müsste es daher auch ein reserviertes Wort sein, was es aber eben nicht ist.

[Jumpy]

Zitat:

Zitat von Perlsau (Beitrag 1260445)

Zitat:

Zitat von jdelphi (Beitrag 1260341)

Wenn man bei Delphi eine String Variable definiert, erscheint String in Fett, da es ein Reserviertes Wort ist.

Tatsächlich wird ein String deshalb fett dargestellt, weil du das unter Tools/Optionen so eingestellt hast. Willst du auch einen Integer fett darstellen, kannst du das ebenfalls einstellen.

Ich hab das so verstanden das es nicht um einen String sondern das Wort "String" geht.

[DeddyH]

Japp, "String" ist nunmal ein reserviertes Wort.

[Perlsau]

Was ich eigentlich damit sagen will: Die ständigen Hinweis à la "deshalb ist es fett" und "deshhalb ist es nicht fett" sind im Grunde irreführend – zumindest für Anfänger –, denn was fett ist und was nicht, stelle ich in den Tools-Optionen unter Editorfarben ein. So könnte ich auch reservierte Begriffe kursiv lila darstellen und Bezeichner fett. Es ist ja schließlich nicht die individuell eingestellte Darstellung, die ein reserviertes Wort dazu macht.

[DeddyH]

Man muss ja nur einen Blick in den Ausgangspost respektive den (etwas unglücklich formulierten) Threadtitel werfen.

[himitsu]

Zitat:

Zitat von Perlsau (Beitrag 1260450)

Was ich eigentlich damit sagen will: ...

Ist das nicht gerade andersrum?
Gerade die werden dort wohl nichts verstellen, geschweige denn die Optionen überhaupt kennen, und vorallem wissen sie nicht was eigentlich ein "reserviertes Wort" ist.
Für Jene ist es also einfach nur Fett. :angel:

[Dejan Vu]

Wenn wir über fette Darstellung philosophieren, möchte ich meinen Sohn anbringen: Er malt neuerdings, müsst ihr wissen. Und da stellt er mich eben fett dar.

Warum? Ich bin reserviert (sagt meine Frau), aber ein 'string'? Nee. das passt nicht. Eher ein fat client.

Aber wir kommen vom Thema ab. Ich, genauer gesagt.

[Perlsau]

Naja, wenn man einerseits Anfänger dazu "erziehen" möchte, korrekte Ausdrücke zu verwenden, z.B. statt "es klappt nicht" eine korrekte Fehlermeldung, statt Tabelle StringGrid zu schreiben, wenn sie sich nicht auf Datenbanken beziehen oder aussagekräftige Bezeichner zu verwenden, sollte man andererseits auch Zusammenhänge korrekt erklären. Natürlich gibt es eine Voreinstellung, doch wer garantiert dir, daß da kein Anfänger rumspielt und hinterher keinen blassen Schimmer hat, daß ganz andere Wörter im Code gemeint waren, weil bei ihm eben die Bezeichner auf fett eingestellt sind. Die direkte Ursache der Fettschrift ist nunmal nicht die Tatsache, daß es sich um ein reserviertes Wort handelt, sondern die Tatsache, daß ich mir reservierte Wörter fett anzeigen lasse. Genauso könntest du statt über Kommentare über grün angezeigten Text diskutieren, und klar, die Kenner wüßten dann schon, was du meinst. Bei mir sind Kommentare aber nicht in allen IDE's, die ich verwende, grün. Gerade Anfänger, insbesondre Schüler spielen gerne mal in den Einstellungen herum, wenn sie mal irgendwo nicht weiterkommen und sich ablenken wollen oder in der Schule der Unterricht zu langweilig ist (das betrifft natürlich nicht nur den "Informatik"-Unterricht). Und später wissen sie nicht mal mehr, wann sie da was wo verstellt haben.

So manche Anfrage in den Delphiforen versteht man erst gar nicht, weil der Fragesteller mit allerlei Begriffen hantiert, deren Bedeutung er nicht wirklich kennt, so wie z.B. gerade wieder in diesem Vokabeltrainerthread. Programmieren erfordert nunmal exakte Ausdrucksweisen, was durch die Bezeichnung "fett" für reservierte Wörter nicht wirklich gefördert wird.

Natürlich muß sich hier niemand meinen Einwand zu Herzen nehmen, ich will da auch nicht darauf rumreiten, aber es hat mich irgendwie gestört.

[himitsu]

Zitat:

Zitat von Perlsau (Beitrag 1260523)

So manche Anfrage in den Delphiforen versteht man erst gar nicht, weil der Fragesteller mit allerlei Begriffen hantiert, deren Bedeutung er nicht wirklich kennt, so wie z.B. gerade wieder in diesem Vokabeltrainerthread.

Erst die Grundlagen zu lernen ist doch voll langweilg. Also warum nicht einfach gleich loszuscripten auch wenn man nicht weiß was man eigentlich macht.
Und was scheinbar einige Leerer so lehren, will ich lieber nicht wissen.

[Perlsau]

Zitat:

Zitat von himitsu (Beitrag 1260525)

Erst die Grundlagen zu lernen ist doch voll langweilg. Also warum nicht einfach gleich loszuscripten auch wenn man nicht weiß was man eigentlich macht.

Genau :!: Erstmal 'ne Runde Autofahren, Führerschein kann mann dann immer noch nachholen :lol:

Zitat:

Zitat von himitsu (Beitrag 1260525)

Und was scheinbar einige Leerer so lehren, will ich lieber nicht wissen.

Der war gut: Leerer :lol::twisted::thumb:
Manche Schüler scheinen sich nach der Schule ja tatsächlich völlig leer vorzukommen, vor allem sinnentleert :stupid:

[Popov]

Gelegentlich unterrichte ich und eines merke ich immer wieder - zuerst Grundlagen beibringen bringt nichts. Klingt zwar logisch, denn bevor man sich an das Wichtige wagt, sollte man die Grundlagen kennen, aber davon bleibt kaum etwas hängen. Es fehlt der Bezug, man versteht die Notwendigkeit nicht, deshalb wird das (oft) sofort wieder vergessen. Der andere Weg, also zuerst das Wichtige lernen ohne die Grundlagen, funktioniert auch nicht. Da bleiben zu viele Fragen offen. Trotzdem ist das der bessere Weg, nur darf man nicht übertreiben und muss man den goldenen Mittelweg finden. Zuerst soviel Grundlagen wie nötig, damit man das Wichtige versteht, danach der Rest der Grundlagen. Nun versteht man auch die Notwendigkeit. Erfahrungsgemäß ist das der effizienteste Weg, ich behaupte aber nicht, dass es der einzige oder allerbeste ist.