Wenn der Compiler Spaß macht...

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2020 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • Wenn der Compiler Spaß macht...

    Ich habe es gerade geschafft, mit Swift (Xcode 7.3; Swift 2.2) folgenden Compiler-Error zu erzeugen:

    Quellcode

    1. Playground execution failed: play.playground:33:21: error: 'subscript' is unavailable: Indexing a String's UTF16View requires a String.UTF16View.Index, which can be constructed from Int when Foundation is imported
    2. if c == delimiter.utf16[0] { break }
    3. ^~~~~~~~~~~~~~~~~~
    4. Swift.String:24:16: note: 'subscript' has been explicitly marked unavailable here
    5. public subscript (i: Int) -> CodeUnit { get }
    6. ^

    Das finde ich besonders humorvoll. Aus zwei Gründen.

    1.) In Swift soll der Index in einem CollectionType ja gerade etwas anderes als ein völlig freischwebender Integer-Wert sein. Wieso sagt mir der Compiler dann, ich soll einen Index aus solch einem Integer erzeugen!?

    2.) Foundation ist Objective-C basiert. Warum soll ich letztendlich Objective-C-API einbinden, um etwas anzusprechen, was es nur in Swift gibt!? ?(

    Vielleicht verstehe ich da auch was falsch, aber ich fand's gerade ganz amüsant. Das Problem im Code werde ich schon noch lösen...

    Hat sonst jemand noch kurzweilige Compilermeldungen zu bieten..?
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • @ #1 Ich Dummerchen! Ich bin ja derjenige, der den Integer überhaupt erst ins Spiel gebracht hat. In Swift muß es natürlich (?) statt delimiter.utf16[0] delimiter.utf16[delimiter.utf16.startIndex] heißen. Wie konnte ich nur? Das ist ja viel klarer, prägnanter und... *reicht eine Tüte Ironie rum*
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • Gute Frage. An anderer Stelle brauche ich den zugrunde liegenden Codepoint als Zahlenwert. Da frage ich mich, ob der UTF16-View oder UnicodeScalars besser geeignet sind... Hier an dieser Stelle brauche ich das eigentlich noch nicht. Da könnte ich tatsächlich mit dem Character-View arbeiten.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    nur mal so nebenbei: warum gibts kein uttf32-view?
    Gibt es doch in gewisser Weise. Die value-Property eines UnicodeScalar-Typs liefert den unicode code point als UInt32 zurück.
    haha, war klar dass ich das übersehen hab :-/ Sonntag lässt grüßen...
    Wo wir beim Thema UnicodeScalar waren...

    Ich sehe gerade in der Swift-Doku:

    typealias CWideChar = UnicodeScalar

    The C++ 'wchar_t' type.
    Interessant. Kannte ich auch noch nicht. Man lernt nie aus...

    Da gibt es auch noch:

    [*]typealias CChar16 = UInt16
    [*]
    The C++11 'char16_t' type, which has UTF-16 encoding.

    [*]typealias CChar32 = UnicodeScalar
    [*]
    The C++11 'char32_t' type, which has UTF-32 encoding.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von torquato ()

  • macmoonshine schrieb:

    tsunamix schrieb:

    Interessant. Kannte ich auch noch nicht. Man lernt nie aus...
    Meinst du damit wchar_t (wchar.h) Der ist sogar Standard-C (POSIX). Letztendlich sind ja Unicode-Zeichen auch nur (32-Bit) Ints. ;)
    Wobei die Breite sehr schwammig definiert ist.
    wchar_t war mir natürlich ein Beriff. Hallo!? :S
    Diese typealias-Definitionen und Entsprechungen in Swift, die waren mir so aber noch nicht untergekommen. Ich dachte das paßt jetzt ganz gut, weil gritsch ja nach UTF-32 in Swift gefragt hatte.


    PS: Wenn man sich mit Ostasiatischen Zeichen auseinandersetzt, dann kann man das 'auch nur' auch wieder... *seufz* mit CJK und Unicode läuft da irgendwas nicht so... :/
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • tsunamix schrieb:

    wchar_t war mir natürlich ein Beriff. Hallo!? :S
    Deswegen frug ich ja auch, wobei das Fragezeichen irgendwo zwischen Hirn und Forum verloren ging. ;)


    tsunamix schrieb:

    PS: Wenn man sich mit Ostasiatischen Zeichen auseinandersetzt, dann kann man das 'auch nur' auch wieder... *seufz* mit CJK und Unicode läuft da irgendwas nicht so...
    Ja, die wchar-Sachen sind in der Praxis relativ unbrauchbar. Viele Rumschraubereien an Locales usw., um danach festzustellen, dass das auf dem Zielsystem dann doch nicht wie gewünscht klappt. +puke+ Wobei das ja genau genommen kein Unicode-Problem ist.

    Dann lieber direkt die ICU verwenden. :)
    „Meine Komplikation hatte eine Komplikation.“
  • Ich dachte da mehr an sowas wie die Han-Vereinheitlichung (han unification).

    Beispiel 海 (Japanisch 'umi', "Meer"):

    In der 1. Tabelle des Links wird das Zeichen (U+6D77) je nach Sprache unterschiedlich interpretiert und dargestellt.

    Im Quelltext sieht das dann so aus:

    HTML-Quellcode

    1. <tr>
    2. <td style="font-size: medium; font-family: sans-serif;">U+6D77</td>
    3. <td lang="zh" xml:lang="zh">海</td>
    4. <td lang="zh-Hans" xml:lang="zh-Hans">海</td>
    5. <td lang="zh-Hant" xml:lang="zh-Hant">海</td>
    6. <td lang="ja" xml:lang="ja">海</td>
    7. <td lang="ko" xml:lang="ko">海</td>
    8. </tr>
    Ein und derselbe Codepoint. Wenn ich hier jetzt 海 schreibe, denke ich ans Japanische, aber wie es verstanden und dargestellt wird, hängt vom Browser und OS ab. Gut möglich, daß das bei vielen hier Chinesisch dargestellt wird. Auf Android ist m.W. Chinesisch Standard, früher dominierte allgemein Japanisch.

    Was passiert nun, wenn ein Japanischer Text ein Chinesisches Zitat enthält? Ist es Aufgabe eines Strings, eine Sprachanalyse durchzuführen..? Bzw. wenn eine separate Analyse noch notwendig ist, erfüllt die Zeichenkette dann noch ihren Zweck?

    In anderen Fällen haben die Zeichenvarianten ganz klar unterschiedliche Codepoints. Z.B. 計 (U+8A08) Japanisch und Traditionelles Chinesisch und 计 (U+8BA1) Vereinfachtes Chinesisch. Das sind die gleichen Zeichen, nur nicht die selben.

    Bei 海 wirds absurd. Ich weiß zwar nicht, wie es vom Browser interpretiert und dargestellt wird, aber die Variante gibt es trotzdem noch als zusätzlichen Codepoint: 海 (U+FA45).

    Das ganze ist durchaus ein Unicode Problem. Mal werden Zeichenvarianten unter dem selben Codepoint implizit als Sprachvarianten aufgefaßt und die Interpretation unterliegt dem Font, also der Darstellung. Manchmal sind Varianten explizit erfaßt. Und das Sahnehäubchen: Manchmal gibt's beides! Siehe 海. WTF!?

    Klar. Das Problem entsteht, weil die Sprachen und die Zeichen der Sprachen so ihre Problematik mitbringen, aber ich bin mir sicher, man hätte es auch anders lösen können. Ich bin mir aber nicht sicher, ob dann noch 32 Bit ausgereicht hätten...
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?