Mengen definieren

[theo]

Für dich ist da klar einfach.Allerdings muss ein Anfänger erstmal auf
http://wiki.lazarus.freepascal.org/Theodp" onclick="window.open(this.href);return false;
kommen,offiziell ist das ja bei Lazarus nicht dabei?
Wenn du mal den Stecker ziehst ist es auch weg im SVN ist dein Code ja auch nicht.

Ja und? Soll ich mich jetzt entschuldigen, dass ich einen Lösungsvorschlag gemacht habe?

[creed steiger]

War ja nicht bös gemeint....
Ich kenn deine Beiträge und Lösungen als pragmatisch und wohldurchdacht.

Nur wie bringt man die Anfänger an den Klippen vorbei,bzw wie wird das in anderen IDE´s gemacht?
Oder sollten deine UTF-8 Tools nur mehr propagiert und sichtbarer gemacht werden?

[theo]

Oder sollten deine UTF-8 Tools nur mehr propagiert und sichtbarer gemacht werden?

Was hätte ich davon? Das ist mir total egal, ich wollte nur behilflich sein.
Das werde ich wohl in Zukunft unterlassen.

[carli]

Nur zu doof, dass dieser Code quadratische Komplexität hat.

Du hast immer einen flotten Spruch auf Lager, was?
Bin durchaus an besseren Vorschlägen interessiert.

for..in löst das Problem der quadratischen Komplexität beim Traversieren von UTF8-Strings.

Welcher Beitrag war das, der "nicht ging"?

[theo]

for..in löst das Problem der quadratischen Komplexität beim Traversieren von UTF8-Strings.

Kannst du mal ein Beispiel machen?

Welcher Beitrag war das, der "nicht ging"?

Der OP wollte das ß in die Menge aufnehmen. Wie machst du das?

[mse]

Der OP wollte das ß in die Menge aufnehmen. Wie machst du das?

Sets werden mit 16 Bit zu gross. Als Ersatz bietet sich case an:

Code: Alles auswählen

{$codepage utf8}
[...]
var
 ch1: unicodechar;
[...]
 case ch1 of
  'a'..'z','A','ä','ß': begin
  end;
[...]

[theo]

Sets werden mit 16 Bit zu gross. Als Ersatz bietet sich case an:

Danke mse, das weiss ich selber. Ich hätte die Antwort lieber von diesem großkotzigen carli gehört.
Der hat bestimmt noch einen Trick auf Lager.

[carli]

for..in löst das Problem der quadratischen Komplexität beim Traversieren von UTF8-Strings.

Kannst du mal ein Beispiel machen?

http://wiki.freepascal.org/for-in_loop" onclick="window.open(this.href);return false;
unterster Abschnitt

einfach for..in mit utf8string benutzen..

Welcher Beitrag war das, der "nicht ging"?

Der OP wollte das ß in die Menge aufnehmen. Wie machst du das?

hab ich nie behauptet, dass das mit set of geht. UnicodeChar ist einfach zu groß für ein set of.

[theo]

http://wiki.freepascal.org/for-in_loop" onclick="window.open(this.href);return false;
unterster Abschnitt

einfach for..in mit utf8string benutzen..

Kannst du da bitte mal ein vollständiges Beispiel machen, welches mit FPC 2.6.X läuft?

Und warum soll das schneller sein als mein Vorschlag?

hab ich nie behauptet, dass das mit set of geht.

Du hast jedenfalls die Beispiele gebracht. Du wusstest also, dass die im vorliegenden Fall nicht funktionieren? Merkwürdig.

[mschnell]

s:=TUTF8Scanner.Create('aböcdüefgöhß');

Ah, der berühmte Unicode-String Iterator

Wenn es dafür noch das passende Syntax-Cady gäbe, dass man einfach

Code: Alles auswählen

for myChar in 'aböcdüefgöhß'.NextPrintableChar do

schreiben könnte wäre das eine Lösung die annähernd die Brauchbarkeit des Vor-Unicode Lazarus entprechen würde.
Ok, Veteranen, müssen umlernen, aber es bleibt handhabbar.

-Michael
(Lustig dass diese Thread parallel zum Thread "FPC Unicode support" läuft der gnau ds zum Thema hat. )

[mschnell]

Wie lösen eigentlich anderes IDE´s/Sprachen das Problem mit den Kodierungen?

bevor die Unicode-Tauglichkeit eingeführt wurde war das kein Problem
In Delphi XE und bei mse sind Character 16 Bit. Damit gehen zwar vermutlich keine Sets, aber zumindest "case" funktioniert (auf Windows !) mit deutschen Zeichen ordentlich. Ob das bei ms auch auf Mac (da gibt es anscheinend irgendwelche sehr gewöhnungsbedürftige Unicode-Codierungen) funktioniert, weiß ich nicht.

Bei ANSI-C gibt es überhaupt keine Strings

-Michael

[mse]

Sets werden mit 16 Bit zu gross. Als Ersatz bietet sich case an:

Danke mse, das weiss ich selber.

Hast du "{$codepage utf8}" beachtet?

[mschnell]

Nur zu doof, dass dieser Code quadratische Komplexität hat.

Du hast immer einen flotten Spruch auf Lager, was?.

Er hat aber recht (was in diesem konkreten Beispiel natürlich keine Nachteiligen Auswirkungen hat, aber bei längeren Strings zur Katastrophe führt.)

Ein ordentlicher String Iterator würde das Problem ohne quadratische Komplexität (O(n) statt O(n²)) lösen (siehe "FPC Unicode Support" Thread).

-Michael

[theo]

Er hat aber recht

Warum?

[mschnell]

Wenn vor dem Abprüfen auch nur eines Zeichens, der String komplett umcodiert wird, werden schon da alle Zeichen bearbeitet. Das kann bei entsprechend schlecht konditionierten Aufgaben zu O(n²) führen. Bei einfachen Beispielen (alle Zeichens des Strings angucken) ist es nur in etwa eine Verdoppelung des Aufwands.

-Michael