Unicode und FPC/Lazarus

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.
pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von pluto »

Ich frage mich, was ich die ganze Zeit falsch mache. Ich kann mich nicht erinnern, jemals mit FPC über ein Encoding-Problem gestolpert zu sein.

Ein Beispiel kann ich dir geben:
Lies mal eine Text Datei mit Umlauten mit TFileStream direkt ein(Kein TStrings oder so).
Anschließend Zeichen den Text auf ein TCanvas.

In der Vergangenheit hatte ich hier immer wieder Probleme z.b. mit Umlauten.

Vielleicht erstelle ich sogar gleich so ein Beispiel.
Ach ja, ich verwende natürlich in der regel String als Datentyp.
MFG
Michael Springwald

diogenes
Beiträge: 200
Registriert: So 11. Jul 2010, 18:39
OS, Lazarus, FPC: Linux
CPU-Target: 64 Bit
Wohnort: Wien
Kontaktdaten:

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von diogenes »

pluto hat geschrieben:
Ich frage mich, was ich die ganze Zeit falsch mache. Ich kann mich nicht erinnern, jemals mit FPC über ein Encoding-Problem gestolpert zu sein.

Ein Beispiel kann ich dir geben:
Lies mal eine Text Datei mit Umlauten mit TFileStream direkt ein(Kein TStrings oder so).
Anschließend Zeichen den Text auf ein TCanvas.

In der Vergangenheit hatte ich hier immer wieder Probleme z.b. mit Umlauten.

Vielleicht erstelle ich sogar gleich so ein Beispiel.
Ach ja, ich verwende natürlich in der regel String als Datentyp.

Sorry, aber das ist meiner Meinung nach weder ein Problem der Programmiersprache noch eines ihrer Implmentation, sondern eines, das sich daraus ergeben hat, dass man erst vor relativ wenigen Jahren eine Lösung für das Problem "8-Bit-Codierte Zeichen für möglichst alle Sprachen" gefunden hat, und das ist UTF-8. Dass man für FPC und Lazarus das übernommen hat, ist meiner bescheindenen Menung nach erstklassig. Ansonsten bleibt dem Programmierer nur, sich mit alten Codierungen herumzuschlagen. Dass die Codepage 1252 (Windows Westlich) als normal empfunden wird, ist ein Windows-Vergehen und keines von Pascal.

Im übrigen bin ich der Meinung, dass Pascal keine sterbende Sprache ist.
Ceterum censeo computatores per Pascal docendos esse.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

m.fuchs hat geschrieben:Ich frage mich, was ich die ganze Zeit falsch mache.

Schau mal im deutschen Forum und auch in den englischen Mailing Listen. Da kommt das Thema immer wieder hoch.

Natürlich gibt es Möglichkeiten mit den Gegebenheiten umzugehen und wenn man überall nur UTF-8 benutzt und weiß man tut (als vermeidet, dass man irgendwo mit anderen Codierungen in Berührung kommt oder die Anzahl der druckbaren Zeichen in einem String wissen will), geht das auch ganz prima.

In anderen Fällen ist es aber reichlich unkomfortabel und inkompatibel. Wobei - wie gesagt - ein Haupt-Problem ist, dass man durch TStrings (z.B. TStringlist) und die Anbindung der GUI-Bibliothek praktisch gezwungen ist, UTF8 zu verwenden (bei Delphi XE dagegen UTF-16, und bei Delphi 7 und älteren fpc/Lazarus-Versionen ANSI), auch wenn die "Code Aware Strings" etwas anderes suggerieren.

-Michael

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von Michl »

mschnell hat geschrieben:Schau mal im deutschen Forum und auch in den englischen Mailing Listen. Da kommt das Thema immer wieder hoch.
Und viele geben sich Mühe, die aufkommenden Fragen zu beantworten. Zeige doch bitte ein ungelöstes Problem, ich versuche immer gern zu helfen.

mschnell hat geschrieben:ein Haupt-Problem ist, dass man durch TStrings (z.B. TStringlist) und die Anbindung der GUI-Bibliothek praktisch gezwungen ist, UTF8 zu verwenden
Das ist kein FPC-Problem sondern ein Lazarus Feature. Dieses Programm funktioniert einwandfrei:
- neues Projekt -> Einfaches Programm
- Projekt in ein Verzeichnis speichern
- Rechtsklick auf Sourcefile -> Dateieinstellungen -> Zeichenkodierung -> CP1252
- folgenden Code einfügen:

Code: Alles auswählen

program project1;
uses Classes, sysutils;
var
  SL: TStringList;
begin
  SL := TStringList.Create;
  SL.Add('Das ist ein Test');
  SL.Add('mit ä, ö und ü,');
  SL.Add('die auch in CP1252 vorkommen');
  SL.SaveToFile(GetCurrentDir + PathDelim + 'test.txt');
  SL.Free;
end.
Es wird eine CP1252 kodierte Datei mit entspechend kodiertem String erstellt.

Darüber, wie Lazarus, speziell die LCL mit Strings umgehen soll, wurde vor ein paar Jahren trefflich gestritten. Soll man native Strings oder soll man eine feste Kodierung verwenden? Es gab Beführworter für beide Seiten. Soviel ich weiß, wollten gerade die FPC-Core member, daß die LCL intern mit nativen Strings arbeitet. Wobei es unter Windows schon zwei unterschiedliche gibt, die alten Ansistrings und Unicodestrings (Widestrings), siehe https://msdn.microsoft.com/de-de/library/windows/desktop/ff381407(v=vs.85).aspx. Letztlich durchgesetzt haben sich die Beführworter eines einheitlichen plattformübergreifenden Strings und der war schon lange vor FPC 3.0.0 intern UTF-8 kodiert, sonst hätte man die ganze LCL umschreiben müssen und sämtlicher Usercode (sollte er denn plattformübergreifend sein, bräuchte {$IFDEF}s, welche Strings je nach OS gerade verwendet werden sollen).

Außerdem ist deine Aussage schlichtweg falsch. Probiere mal eine GUI mit einem Button und einem Memo zu erstellen, die Kodierung der Unit1 auf CP1252 zu stellen und folgenden Code (und sei erstaunt):

Code: Alles auswählen

uses ..., LConvEncoding;
...
procedure TForm1.Button1Click(Sender: TObject);
var
  SL: TStringList;
begin
  SL := TStringList.Create;
  SL.Add('Das ist ein Test');
  SL.Add('mit ä, ö und ü,');
  SL.Add('die auch in CP1252 vorkommen');
  SL.SaveToFile(GetCurrentDir + PathDelim + 'test.txt');
  SL.Text := CP1252ToUTF8(SL.Text);
  Memo1.Lines.Assign(SL);
  SL.Free;
end;

Ein Hinweis will ich noch mitgeben. Auf ganz lange Sicht ist es geplant, von UTF-8 auf UTF-16 umzustellen. Die Grundsteine wurden bereist gelegt. Da dieses Ziel aber nicht absehbar ist, würde ich erst dann den Shitstorm starten, wenn es erste Diskussionen in den Mailinglists dazu gibt. Hier im deutschen Forum wird es wohl kaum entschieden :)

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von marcov »

pluto hat geschrieben:Lies mal eine Text Datei mit Umlauten


Es besteht kein Typ "Text Datei mit Umlauten". Das ist ein typisch Zeichen das man nichts von Eincodierung verstanden hat.

mit TFileStream direkt ein(Kein TStrings oder so).


Also total Binär und ganz um jede Sprache Unterstützung von Encodings um. Solch ein Szenario kann man nie garantieren. Wenn es klappt ist das reine Zufall.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

Michl hat geschrieben:Außerdem ist deine Aussage schlichtweg falsch.
Welche ?
-Michael

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

Im Prinzip ist die Unicode schon eine Pascal - Problematik, da - soweit ich weiß - alle existierenden Pascal - Dialekte früher ausschließlich mit ein-Byte-codierten Strings gearbeitet haben (ANSI - C dagegen hat gar keine Strings, da tritt das Problem nicht auf :twisted: ) "Moderne" Sprachen sind von vorne herein mit Unicode-Strings entstanden, da gibt es dann keine Kompatibilitäts-, Lernkurven und Dokumentations-Probleme.

-Michael

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von Michl »

mschnell hat geschrieben:
Michl hat geschrieben:Außerdem ist deine Aussage schlichtweg falsch.
Welche ?
-Michael
Na diese:
Michl hat geschrieben:
mschnell hat geschrieben:ein Haupt-Problem ist, dass man durch TStrings (z.B. TStringlist) und die Anbindung der GUI-Bibliothek praktisch gezwungen ist, UTF8 zu verwenden
Wie gesagt, man ist frei, welches Encoding man verwenden will, per default ist überall UTF-8 eingestellt, wenn man dies nicht will, so kann man dies ausstellen mit all seinen Auswirkungen. Bei Fragen, bitte fragen!

mschnell hat geschrieben:Embarcadero dagegen hat ein Beta draußen, dass für Linux-PCs kompilieren kann. Android und iOS geht schon (allerdings nicht mit VCL GUI). Wenn Delphi nicht so unverschämt teuer wäre würde es möglicherweise eng für fpc/Lazarus.
Das sehe ich genau anders herum, ein starkes Delphi wird sich eher positiv für FreePascal/Lazarus auswirken, da mit Delphi auch die Sprache Object-Pascal vermarktet wird. Daher, Daumen hoch dafür :D

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

Michl hat geschrieben:
mschnell hat geschrieben:
Michl hat geschrieben:Außerdem ist deine Aussage schlichtweg falsch.
Welche ?
-Michael
Na diese:
Michl hat geschrieben:
mschnell hat geschrieben:ein Haupt-Problem ist, dass man durch TStrings (z.B. TStringlist) und die Anbindung der GUI-Bibliothek praktisch gezwungen ist, UTF8 zu verwenden
Wie gesagt, man ist frei, welches Encoding man verwenden will, per default ist überall UTF-8 eingestellt, wenn man dies nicht will, so kann man dies ausstellen mit all seinen Auswirkungen. Bei Fragen, bitte fragen!


Wenn man die String - Codierung von TStringList von UTF-8 auf irgendetwas anderes umstellen will, muss man die RTL und dann vermutlich auch die LCL neu kompilieren. Das will vermutlich niemand.

Wenn man die UTF-8 TStringList mit Strings einer anderen Codierung verwendet, wird beim Eingeben und beim Auslesen der Strings in die Liste unter der Hand eine aufwändige Umcodierung gemacht. Das will vermutlich auch niemand wirklich.

Für "einfache" Programme ist die String-Codierung - wie besprochen - meist kein wirkliches Problem. Wenn man aber Daten in irgendwelchen Codierung von außen (z.B. TCP/IP) bekommt und nach außen abgeben will, und sie (z.B., aus Performance-Gründen) nicht beim Einlesen und Auslesen jeweils (in UTF-8) umcodieren will, wird es komplex. Außerdem ist z.B. UTF-8 auf Platz und UTF-16 auf Verarbeitungsgeschwindigkeit optimiert. Wenn man größere Mengen Text auf komplexe Weise verarbeiten will, ist es sinnvoll, jeweils die optimierte Codierung zu benutzen. Das kann in einem Programm beides vorkommen (und vielleicht auch noch andere Wunsch-Codierung). Wenn man dann - wie es ja eigentlich sinnvoll ist - TStingList oder einen anderen Abkömmling von TStrings zum Speichern oder verarbeiten der ganzen Strings verwenden möchte, läuft man vor genau diese Wand. Das könnte durchaus besser (und dabei noch kompatibler zu den anderen Pascal-Dialekten) sein.

-Michael

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von wp_xyz »

mschnell hat geschrieben:Wenn man die String - Codierung von TStringList von UTF-8 auf irgendetwas anderes umstellen will, muss man die RTL und dann vermutlich auch die LCL neu kompilieren. Das will vermutlich niemand.

Wenn man die UTF-8 TStringList mit Strings einer anderen Codierung verwendet, wird beim Eingeben und beim Auslesen der Strings in die Liste unter der Hand eine aufwändige Umcodierung gemacht. Das will vermutlich auch niemand wirklich.

Für "einfache" Programme ist die String-Codierung - wie besprochen - meist kein wirkliches Problem. Wenn man aber Daten in irgendwelchen Codierung von außen (z.B. TCP/IP) bekommt und nach außen abgeben will, und sie (z.B., aus Performance-Gründen) nicht beim Einlesen und Auslesen jeweils (in UTF-8) umcodieren will, wird es komplex. Außerdem ist z.B. UTF-8 auf Platz und UTF-16 auf Verarbeitungsgeschwindigkeit optimiert. Wenn man größere Mengen Text auf komplexe Weise verarbeiten will, ist es sinnvoll, jeweils die optimierte Codierung zu benutzen. Das kann in einem Programm beides vorkommen (und vielleicht auch noch andere Wunsch-Codierung). Wenn man dann - wie es ja eigentlich sinnvoll ist - TStingList oder einen anderen Abkömmling von TStrings zum Speichern oder verarbeiten der ganzen Strings verwenden möchte, läuft man vor genau diese Wand. Das könnte durchaus besser (und dabei noch kompatibler zu den anderen Pascal-Dialekten) sein.

Vermutlich wird deine gewünschte Superimplementierung, die die 5% aller Anwendungen erwas vereinfacht, bei anderen 5% von Anwendungen und anderen Benutzern genauso Probleme bereiten wie die FPC-Realisierung bei dir. Wahrscheinlich hat dich das ewige Lästern über die FPC-Strings mehr Zeit gekostet als eine eigene Stringliste für deine spezielle Anwendung zu schreiben, mit der du alle Kompatibilitätsprobleme los gewesen wärst.

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von marcov »

mschnell hat geschrieben:Wenn man die String - Codierung von TStringList von UTF-8 auf irgendetwas anderes umstellen will, muss man die RTL und dann vermutlich auch die LCL neu kompilieren. Das will vermutlich niemand.


TStringList in FPC 3.0.0 ist NICHT UTF-8. Lazarus stellt es um bis UTF-8, ohne Rekompilierung.

Für "einfache" Programme ist die String-Codierung - wie besprochen - meist kein wirkliches Problem. Wenn man aber Daten in irgendwelchen Codierung von außen (z.B. TCP/IP) bekommt und nach außen abgeben will, und sie (z.B., aus Performance-Gründen) nicht beim Einlesen und Auslesen jeweils (in UTF-8) umcodieren will, wird es komplex.


Nicht wirklich mehr komplex als irgendwie eine Situation mit mehr als eine Codierung. Weil der Codierung der von das TCP/IP Protocol auch nicht zwingend dasselbe als der lokale Codierung ist.

Außerdem ist z.B. UTF-8 auf Platz und UTF-16 auf Verarbeitungsgeschwindigkeit optimiert.


Auch nicht ganz Wahr. Ein String kopieren zb Beispiel ist wesentlich schneller fuer UTF-8.


Wenn man dann - wie es ja eigentlich sinnvoll ist - TStingList oder einen anderen Abkömmling von TStrings zum Speichern oder verarbeiten der ganzen Strings verwenden möchte, läuft man vor genau diese Wand. Das könnte durchaus besser (und dabei noch kompatibler zu den anderen Pascal-Dialekten) sein.


TStringList wird auch fuer geordnete Liste genutzt. Jetzt, mit nur eine Codierung im TStringList kann man das schematisch so machen:

Code: Alles auswählen

procedure TStringlist.Suche(const s : rawbytestring);
 
begin
  ensureencoding(s); // force Codierung 0
  binsearch(s); // keine Konversionen im suche
end;


Speziell Dynamische Stringtypen wie oft als algemeiner Loesung gesehen wird, sind hier schlimmer, weil jeder Zugang zur solch einer String in der TstringList während das Suchen zu Konversionen leiten kann. (und deshalb mehrere Konversionen während einer Suche)

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

wp_xyz hat geschrieben:Vermutlich wird deine gewünschte Superimplementierung, die die 5% aller Anwendungen erwas vereinfacht, bei anderen 5% von Anwendungen .

Wie bereits gesagt ist die aktuelle Methodik sowohl in Lazarus als auch in Delphi für die meisten Anwendungen durchaus gangbar. Für die anderen wäre ein flexibles TStrings aber nicht eine "Vereinfachung" sondern würde eine sinnvolle Programmierung mit Hilfe von z.B. "TStringlist" überhaupt erst ermöglichen.
wp_xyz hat geschrieben: und anderen Benutzern genauso Probleme bereiten wie die FPC-Realisierung bei dir
Eine andere Realisierung der Strings könne - wie bereits mehrfach gesagt - wesentlich kompatibler zwischen dem aktuellen Lazarus und vor-Unicde Lazarus, Delphi 7 und Delphi XE sein und dadurch eine Menge von Problem-Meldungen von "Umsteigern" vermeiden. Ich selber habe übrigens überhaupt keine Problem und mich auch auch nie "beschwert". Ich habe immer nur auf die Problem-Meldungen von anderen Usern in den Foren reagiert.
wp_xyz hat geschrieben:Wahrscheinlich hat dich das ewige Lästern über die FPC-Strings mehr Zeit gekostet als eine eigene Stringliste für deine spezielle Anwendung zu schreiben, mit der du alle Kompatibilitätsprobleme los gewesen wärst.

Ich habe keine "spezielle Anwendung", mir liegt nur ein optimales Lazarus am Herzen und dass es nicht optimal ist, sieht man an den diversen Problemen, die seit Unicode-Einführung immer wieder in allen Forum gepostet worden sind (und denen, die Kollegen an mich herangetragen haben) . Deshalb habe ich (auf Anfrage aus dem englischen Forum) einen Wiki-Artikel mit einem entsprechenden Verbesserungsvorschlag verfasst. Wenn Du den liest wirst Du erkennen, dass man eine "eigene Stringliste" mit den gewünschten Eigenschaften nicht "machen" kann, weil dafür die Unterstützung des Compilers und der fpc RTL notwendig ist, die man ja nicht "mal eben" umschreiben kann.

-Michael

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

marcov hat geschrieben:Speziell Dynamische Stringtypen wie oft als algemeiner Loesung gesehen wird, sind hier schlimmer, weil jeder Zugang zur solch einer String in der TstringList während das Suchen zu Konversionen leiten kann. (und deshalb mehrere Konversionen während einer Suche)

Juchhu !! Endlich mal ein faktischer Einwand gegen einen dynamische String-Typ für TStrings, über den man nachdenken kann ! (Werde ich machen und möglicherweise den Wiki.-Artikel updaten...) (Den Einwand "zu viel Arbeit" habe ich ja bereits von Beginn an akzeptiert.)

Es ist bei sortierten und zu durchsuchenden Listen ganz offensichtlich problematisch, wenn die Listen-Einträge in unterschiedlichen Codierungen vorliegen. Dazu müsste ein solches System eine Lösung anbieten.

Danke,
-Michael

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von marcov »

mschnell hat geschrieben:
marcov hat geschrieben:Speziell Dynamische Stringtypen wie oft als algemeiner Loesung gesehen wird, sind hier schlimmer, weil jeder Zugang zur solch einer String in der TstringList während das Suchen zu Konversionen leiten kann. (und deshalb mehrere Konversionen während einer Suche)

Juchhu !! Endlich mal ein faktischer Einwand gegen einen dynamische String-Typ für TStrings, über den man nachdenken kann ! (Werde ich machen und möglicherweise den Wiki.-Artikel updaten...) (Den Einwand "zu viel Arbeit" habe ich ja bereits von Beginn an akzeptiert.)

Es ist bei sortierten und zu durchsuchenden Listen ganz offensichtlich problematisch, wenn die Listen-Einträge in unterschiedlichen Codierungen vorliegen. Dazu müsste ein solches System eine Lösung anbieten.

Danke,
-Michael


Es ist nur ein Vorbild von eine allgemeinere Problematik. Wenn man Codierung gleich am Enden des System auf eine allgemeine (UTF16 oder-8) Codierung umsetzt, sind Operationen innerhalb des Kern des Systems typisch ohne zu viel Konversionen. (und typisch nimmt man dafür auch ein Codierung wobei die die meisten Prozedure wie CompareStr oder Uppercase direkt arbeiten, und nicht noch ein mal konvertieren).

Wenn man ein polymorphisch Stringtyp hat (lassen wir es so nennen), dann entsteht im Kern des Programms eine Situation mit mehrere Codierungen, und dieselbe repetierte Operationen machen immer wider Codierungkonversionen.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Haltet ihr Pascal für eine sterbende Sprache?

Beitrag von mschnell »

Absolut richtig.

Alle diese "Systeme" müssen entsprechend betrachtet werden.

z.B. für das "Basis"-"System", das aus ":=", "pos", "copy", "delete", "s[i]" etc besteht, macht das bereits jetzt der Compiler und behandelt die Funktionen so, als wären die Formal-Parameter und die rechte Seite der Zuweisung dynamish (polymorphisch) codiert.

Über TStrings haben wir gerade diskutiert. (Ergebnis steht natürlich noch aus und ist aufgrund des "zu viel Arbeit" Arguments sowieso rein theoretisch.)

Ein weiteres "System" wäre die LCL. Hier scheint es mir am sinnvollsten zu sein, die Festlegung auf einen bestimmten Typ da zu machen, wo über den angebundenen externen Widget-Set entschieden wird. Der erfordert natürlich einen festen Codierungs-Typ.

Für "Systeme", die die Anwender implementieren, sind sie selbst verantwortlich. Wenn sie aber einfach nur "String" ohne explizite Angabe eines Codierungstyps verwenden, bleibt das so geschaffene "System" natürlich in dem beim Compilieren vom Compiler für den Type "String" festgelegten Codierungstyp und somit in dieser Betrachtungsweise unproblematisch. Wenn er explizit anderes codierte String Typen verwendet, weiß er, was er tut. Und der fehlerträchtige unbeabsichtigte implizite Gebrauch anderer Codierungstypen soll ja gerade durch die Verwendung von polymorphischen Strings bei "mitgelieferten" System vermieden werden.

marcov hat geschrieben: wobei die die meisten Prozedure wie CompareStr oder Uppercase direkt arbeiten, und nicht noch ein mal konvertieren

Gibt es die "polymorphisch" in mehreren Varianten ?
Schaue ich mir an....

-Michael

Antworten