Wie funktioniert RawByteString? (ab FPC 3.x)

[theo]

Das bringt hier nichts MmVisual.
Der Ort wo so etwas diskutiert wird ist hier: http://lists.freepascal.org/lists/fpc-devel/
Lies erstmal die ganzen Threads der vergangenen Jahre zu diesem Thema durch.
Wenn du danach noch etwas zu dem Thema einbringen möchtest: Viel Glück!

[mschnell]

Meine ich nicht....

Soooo blöd sind die Jungs von Embarcadero auch nicht. Die werden sich schon etwas dabei gedacht und einiges ausgetestet haben, als sie sich von einigen Jahren dafür entschieden haben die "neuen" Strings so zu implementieren, statt die naheliegende Variante "Strings sind Objekte" einzubauen. Einige Fehler wurden dann bis DXE-2 ausgebügelt und es gibt sicherlich immer noch einiges zu verbessern und zu erweitern.

FPC/Lazarus müssen auf jeden Fall einen voll kompatiblem Modus anbieten, um den Umstieg DXE -> Lazarus zu ermöglichen. Das ist natürlich für ein Multi-Plattform nicht ganz so einfach (und auch weniger performant) als bei DXE, das nur Windows kann.

Alle Erweiterungen / Verbesserungen müssen intern hinreichend kompatibel sein, um die User nicht zu sehr zu verwirren.

-Michael

[MmVisual]

Genau das würde man mit meinem Vorschlag erreichen

- Kompatibel zu FPC 2.6
- Kompatibel zu Delphi, sogar kompatibler, da der Typecast per Typ(Var) geht.
- Einfacher zu verwenden
- Der String wäre dann zwar eine Kombination zwischen Datentyp und Objekt, sollte nach außen hin (Lazarus-User) nicht spürbar sein.

Blöd sind die Leute von Embarcadero sicher nicht. Nur haben die sich damals mit ihren festgelegten 16-Bit breiten Zeichen verkalkuliert.

Nun mit meinem Konstrukt ist ganz einfach per Definition der String innerhalb Lazarus UTF8. Und wenn das einem nicht passt und lieber Unicode als Standard haben will, so würde das per Kompileroption (Kompilerschalter) ganz einfach auf jeden anderen beliebigen Typ umgebogen werden können und schwups ist der "String" dann per Default Unicode oder Ansi oder sonst was. Somit hat der User selbst die Möglichkeit zu bestimmen wie der Typ String intern aufgebaut ist.

Sogar das:

Code: Alles auswählen

Var s1: Utf8String;
  s2: UnicodeString;
Begin
  s1 := s2;  // Würde keine Compiler Meker Meldung erzeugen

Eine Float := Integer; Zuweisung erzeugt ja auch keine Mecker-Meldung. Sondern funktioniert einfach ohne den User zu nerven.

[mschnell]

- Kompatibel zu Delphi, sogar kompatibler, da der Typecast per Typ(Var) geht.

Nützt nix, da Die verschiedednen Delphi Versionen untereinder gar nicht kompatibel sind.

- Einfacher zu verwenden

Da es (zum Beispiel) bei dem Ausdruck myString[n] von vorne herein nicht klar ist, ob man da das n-te "druckbare Zeichen" oder das n-ten Codewort der aktuell verwendeten Codierung meint. Somit geht bei Unicode "einfach" überhaupt nicht.

- Der String wäre dann zwar eine Kombination zwischen Datentyp und Objekt, sollte nach außen hin (Lazarus-User) nicht spürbar sein.

ein sehr frommer Wunsch

Blöd sind die Leute von Embarcadero sicher nicht. Nur haben die sich damals mit ihren festgelegten 16-Bit breiten Zeichen verkalkuliert.

Stimmt nicht. (Das würde für "WideString"s zutreffen). Die DXE-Strings können - wie gesagt - beliebig in 8, 16 oder 32 Bit Codierungen angelegt werden (16 Bit ist Default für den Type "String(0)", der auch einfach "String" heißt, aber man kann auch alle seine Strings anders anlegen.)

-Michael

[MmVisual]

Mit "myString[n]" erwarte ich als DAP (dümmster anzunehmender Programmierer) das n te sichtbare Zeichen, zurückgegeben in der Codierung die der String nun mal hat.
Da ein String ein intelligentes Objekt wäre, könnte man damit auch myString.GetByte(n) ausführen und man bekäme tatsächlich das Byte an der Position im Speicher.
Ein PChar(myString) liefert dann auch den Zeiger auf das erste String-Zeichen, so wie bisher auch.

Dass Delphi untereinander nicht so kompatibel ist durfte ich auch schon feststellen, genau deshalb sollten sich die FPC Leute auch nicht zu eng an Delphi klammern, sondern eher die Lösung verwenden, die für die Zukunft am besten geeignet ist und sich nicht an irgend einem alteingesessenen Festklammern.
Dafür gibt es dann den Versionssprung vom FPC von 2.x auf 3.x. Wer das nicht will kann Lazarus nach wie vor mit FPC2.x nutzen.

[Soner]

Manchmal werde ich das Gefühl nicht los, dass Lazarus+FPC eine billige Kopie von Delphi ist. Alles was in Delphi nicht richtig implementiert ist, ist auch bei FPC+Laz nicht richtig implementiert. Delphi hat keine richtige Netzwerk-, Grafikschnittstellen so Lazarus auch nicht.
Ich verstehe immer noch nicht, warum sie anstreben Delphi kompatibel zu sein. Wieviele Delphi Programmier gibt"s noch auf der Welt die angeworben werden müssen. Delphi ist doch kein standardisierte Sprache. Kein Mensch wird doch Lazarus+FPC verwenden weil er Delphi toll findet dann bleibt er auf Delphi.
Am wenigsten braucht man kompatibel mit XE-Versionen sein. Wieviele XE-Benutzer gibt"s denn auf Welt. Wenn jemand von Delphi auf Lazarus wechselt dann höchstens von alten Delphi-Versionen.
Ich wünschte Lazarus und Freepascal Leute würden sich zusammentun und alles Einheitlich machen, überflüssige mehrfache implementierungen eliminieren.

[Socke]

Ich wünschte Lazarus und Freepascal Leute würden sich zusammentun und alles Einheitlich machen, überflüssige mehrfache implementierungen eliminieren.

In der Tat gibt es da noch sehr viele Differenzen. Ich finde es schon doof, dass es für die Free Component Library und die Lazarus-Packages unterschiedliche Paketverwaltungen gibt (und beide sind nicht die Besten). Als Entwickler interessiert mich nur: Ich möchte Klasse/Komponente xyz verwenden. Ob die jetzt in die IDE integriert werden kann oder nicht, ist doch für den Bezug erst einmal nebensächlich.

[MmVisual]

@Socke
Das hat einen einfachen Grund:
Lazarus/LCL Entwickler gibt es relativ viele und wenn da etwas beim FPC fehlt wird es eben mal schnell implementiert.
FPC Entwickler gibt es lange nicht so viele und da was neues rein zu machen dauert auch entsprechend länger. Dazu kommt noch dass der FPC als nativ Compiler gedacht ist, mit dem man für alle möglichen Prozessoren ohne GUI ein Programm schreiben kann. Somit alles was man da ein macht muss auch für eine ganze menge an anderen Systemen unterstützen/getestet werden.
Mit auch aus diesem Grund wollte ich ein komplettes Redesign vom Typ "String" um für die Zukunft gerüstet zu sein.
(Irgend wann lernen wir Außerirdische kennen und dann wird deren Zeichensatz auch noch in unseren integriert Wir können ja schon mal mit dem Klingonischen beginnen.)

[mschnell]

weil er Delphi toll findet dann bleibt er auf Delphi.

Genau. Besonders wenn er seine Programme auf Linux oder Mac laufen lassen will.

-Michael

[Soner]

weil er Delphi toll findet dann bleibt er auf Delphi.

Genau. Besonders wenn er seine Programme auf Linux oder Mac laufen lassen will.

-Michael

Naja Lazarus ist ja für Mac OS X nicht richtig funktionsfähig, verwendet ein GUI das schon Apple abgeschrieben hat.
Und Linux Desktop kann man vernachlässigen. Linux Desktop ist wie Dieter Bohlen, eine kann nicht richtig singen andere funktioniert nicht richtig, drängen sich auf obwohl sie Kopfschmerzen bereiten.

[theo]

Und Linux Desktop kann man vernachlässigen. Linux Desktop ist wie Dieter Bohlen, eine kann nicht richtig singen andere funktioniert nicht richtig, dringen sich auf obwohl sie Kopfschmerzen bereiten.

Du bist ja ganz schön laut. Vielleicht erst mal am Deutsch arbeiten?
Ich bin seit Jahren fast ausschließlich auf Linux-Desktop und bekomme Entzugserscheinungen auf Windows und Mac.

[Soner]

@Socke
...
FPC Entwickler gibt es lange nicht so viele und da was neues rein zu machen dauert auch entsprechend länger. Dazu kommt noch dass der FPC als nativ Compiler gedacht ist, mit dem man für alle möglichen Prozessoren ohne GUI ein Programm schreiben kann. Somit alles was man da ein macht muss auch für eine ganze menge an anderen Systemen unterstützen/getestet werden.
..

Für Packages sind ja nicht zwingend GUI erforderlich.

[Soner]

Du bist ja ganz schön laut. Vielleicht erst mal am Deutsch arbeiten?
Ich bin seit Jahren fast ausschließlich auf Linux-Desktop und bekomme Entzugserscheinungen auf Windows und Mac.

Meinst du, da trete ich leiser
Mit dem Deutsch wird es nichst mehr, zu schwer und für die restlichen Jahre lohnt es nicht mehr. Dazu kommt die Eingeberonen können es nichtmal richtig.

[Christian]

Naja Lazarus ist ja für Mac OS X nicht richtig funktionsfähig, verwendet ein GUI das schon Apple abgeschrieben hat.

Also von "nicht richtig funktionstüchtig" bis es wird (noch) ein depricated Widgetset eingesetzt, ist schon noch ne ganze menge Luft. Ich hab unter OSX recht wenig Probleme dafür das es nach deiner Aussage nicht funktioniert...

[MmVisual]

Ich kann unter MAC mein Projekt nicht wirklich nutzen, siehe hier
http://bugs.freepascal.org/view.php?id=24602

Hilfe wäre willkommen (PN schreiben, ich kenne mich mit MAC kaum aus)