Original von Amin Negm-Awad
So etwas wie

NSString* text = [NSString stringWithFormat:@"%c%d", '\\', 65];

funktioniert nicht. Es führt zu \65 (nicht der Ersatz von \65 = 'A'), weil der Compiler das nie sieht.

Nun verstehe ich deine Argumentation nicht.
Natürlich führt das zu \65. Du übergibst ja erst via Escape-Sequenz das \ und anschließend die 65. Was sollte da anderes rauskommen als \65?

Wenn du willst, dass \65 als Zeichen interpretiert wird, musst du schon \65 als Zeichen übergeben.

NSString* text = [NSString stringWithFormat:@"%c", \65];

Alles Andere ist ja albern.
(War es auch schon vor über 14 Stunden, ich weiß.)

Original von Amin Negm-Awad
Vorschläge, die bei der Generierung darauf basieren können daher nicht funktionieren. Übrigens auch bei Stoßtrupp nicht. Schon bei Dennis 1972 funktionierte entsprechendes nicht. Man müsste den String durch den Compiler jagen.

Wo wurde denn etwas Anderes vorgeschlagen, als zur Generierung des anzuzeigenden Zeichens einfach das anzuzeigende Zeichen einzugeben?

Original von Amin Negm-Awad
Dann gibt es den Formatstring. Der wird zur Laufzeit interpretiert. Daher funktioniert ein %C mit anschließendem Code. Diese Interpretation wird von bestimmten Methoden gemacht, die das spezifizieren. Und diese Methoden erwarten eine Ganzzahl als Parameter, keinen String mit einer Zahl. Daher kann das mit @"1234"m @"\1234", @"&#1234" usw. immer noch nicht funktionieren.

Wie ich schon schrieb:
[NSString stringWithFormat:@"%c%c", \xDE, \xAD];
Klappt, läuft, funktioniert.

Original von Amin Negm-Awad
Das ist eigentlich ganz einfach und stand schon vor 14 Stunden in diesem Thread. Aber dann kamen diejenigen, die es besser wissen …

Ich denke nicht, dass es um 'besser wissen' geht. Eher um 'was zur Hölle passiert da?'

Offenbar liefern
[NSString stringWithFormat:@"%c%c", \xDE, \xAD];
[NSString stringWithString:@"\xDE\xAD"];
@"\xDE\xAD";
[[NSMutableString mutableString] appendString:@"\xDE\xAD"];
[[NSMutableString mutableString] appendFormat:@"%c%c", \xDE, \xAD];
immer dasselbe Ergebnis: die Unicode-Zeichen für \xDE und \xAD.

Ich verstehe nicht, wie der OP eine Zeichenkette erzeugen konnte, ohne dass diese Ersetzung durchgeführt wurde. Ich vermute, dass das für zermelo auch ein Rätsel ist.
Offenbar scheint es für den OP aber völlig logisch, dass die von seinem Algorithmus zurückgegebene Zeichenkette dargestellt "\xDE\xAD" lautet.

Und hier fehlt mir die Vorstellungskraft, wie so etwas passieren kann.
(außer, man arbeitet mit Dingen wie [NSString stringWithFormat:@"%c%d", '\\', 65];, aber das ist dann ja schon mutwillig.)

Original von Lucas de Vil

Original von Amin Negm-Awad
So etwas wie

NSString* text = [NSString stringWithFormat:@"%c%d", '\\', 65];

funktioniert nicht. Es führt zu \65 (nicht der Ersatz von \65 = 'A'), weil der Compiler das nie sieht.

Nun verstehe ich deine Argumentation nicht.
Natürlich führt das zu \65. Du übergibst ja erst via Escape-Sequenz das \ und anschließend die 65. Was sollte da anderes rauskommen als \65?

Das sage ich ja. Und das sagte ich bereits auf der ersten Seite:
osxentwicklerforum.de/thread.php?threadid=11059#post105566

Er hat aber so etwas versucht: Er hat die Nummer in einem String zusammengesetzt und dann erwartet, dass dieser interpretiert wird. Das funktioniert eben nicht.

Original von Lucas de VilWenn du willst, dass \65 als Zeichen interpretiert wird, musst du schon \65 als Zeichen übergeben.

Eben!

Und genau das hatte ich auch schon geschrieben:
Darstellung von unicode-Schriftzeichen

Original von Lucas de Vil
NSString* text = [NSString stringWithFormat:@"%c", \65];

Alles Andere ist ja albern.
(War es auch schon vor über 14 Stunden, ich weiß.)

Er hat es aber eben so versucht: Er hat (dort mit &#, der Vorschlag mit \x kam ja von zermelo) zur Laufzeit zusammengebaut. Das kann nicht funktionieren, weil das vom Compiler interperteiert wird, zur Laufzeit aber kein Compiler mehr existiert.

Original von Lucas de Vil

Original von Amin Negm-Awad
Vorschläge, die bei der Generierung darauf basieren können daher nicht funktionieren. Übrigens auch bei Stoßtrupp nicht. Schon bei Dennis 1972 funktionierte entsprechendes nicht. Man müsste den String durch den Compiler jagen.

Wo wurde denn etwas Anderes vorgeschlagen, als zur Generierung des anzuzeigenden Zeichens einfach das anzuzeigende Zeichen einzugeben?

Das wurde hoffentlich gar nicht vorgeschlagen, weil zur Laufzeit nichts eingegeben wird. Die Generierung erflgt aber zur Laufzeit.

Wie willst du denn etwas in deine Source eingeben, wenn das Programm bereits läuft? Willst du einen gcc mitliefern?

Original von Lucas de Vil

Original von Amin Negm-Awad
Dann gibt es den Formatstring. Der wird zur Laufzeit interpretiert. Daher funktioniert ein %C mit anschließendem Code. Diese Interpretation wird von bestimmten Methoden gemacht, die das spezifizieren. Und diese Methoden erwarten eine Ganzzahl als Parameter, keinen String mit einer Zahl. Daher kann das mit @"1234"m @"\1234", @"&#1234" usw. immer noch nicht funktionieren.

Wie ich schon schrieb:
[NSString stringWithFormat:@"%c%c", \xDE, \xAD];
Klappt, läuft, funktioniert.

Ja, das funktioniert. Und wenn du mal auf Seite 1 dieses Threads schaust, siehst du, dass diese Lösung bereits in den erstenAntworten von mir stand und in der ersten Antwort von macmoonshine. Da hast du dich noch gar nicht an der Diskussion beteiligt, auch zermelo nicht. Der wusste es dann nur besser, *nachdem* bereits die Lösung im Thread stand. *Er* wollte dann mit \x arbeiten.

Original von Lucas de Vil

Original von Amin Negm-Awad
Das ist eigentlich ganz einfach und stand schon vor 14 Stunden in diesem Thread. Aber dann kamen diejenigen, die es besser wissen …

Ich denke nicht, dass es um 'besser wissen' geht. Eher um 'was zur Hölle passiert da?'

Offenbar liefern
[NSString stringWithFormat:@"%c%c", \xDE, \xAD];
[NSString stringWithString:@"\xDE\xAD"];
@"\xDE\xAD";
[[NSMutableString mutableString] appendString:@"\xDE\xAD"];
[[NSMutableString mutableString] appendFormat:@"%c%c", \xDE, \xAD];
immer dasselbe Ergebnis: die Unicode-Zeichen für \xDE und \xAD.

Ich verstehe nicht, wie der OP eine Zeichenkette erzeugen konnte, ohne dass diese Ersetzung durchgeführt wurde. Ich vermute, dass das für zermelo auch ein Rätsel ist.

Du weit nicht, wie man einen String mit Zahlen erzeugt? Soooo schwer ist das ja nun nicht.

Übrigens ist es auch gleichgültig, wie er es geschafft hat, er hat es geschafft. Das stand bereits im OP, also lange bevor du oder zermelo an der Diskussion teilnahmen.

Original von Lucas de VilOffenbar scheint es für den OP aber völlig logisch, dass die von seinem Algorithmus zurückgegebene Zeichenkette dargestellt "\xDE\xAD" lautet.

Und hier fehlt mir die Vorstellungskraft, wie so etwas passieren kann.
(außer, man arbeitet mit Dingen wie [NSString stringWithFormat:@"%c%d", '\\', 65];, aber das ist dann ja schon mutwillig.)

Wieso ist das unverständlich?

Er dachte sich, dass der String auf &#x lauten muss, damit er dann entsprechend interpretiert wird. Also macht er sich so einen String. Mutmaßlich so etwas wie in diese Richtung:
[NSString stingWithFormat:@"&#x%X;", myCode ];

zermelo machte daraus sinngemäß folgende Erzeugung:
[NSString stingWithFormat:@"\\%d;", myCode ];

Beides funktioniert offenkundig nicht. Bei b) liegt es daran, dass das der Compiler nicht sieht, bei a) ebenfalls, wobei noch hinzukommt, dass der Compiler die Ampersand-Notation ohnehin nicht übersetzt.

+++

Ganz einfach: Schreibe ein Programm, das Strings aus $irgendwelchen Unicodes generiert. Meinetwegen nimmst du die zufällig oder lässt sie den Benutzer als Zahl eingeben.

Nirgendwo in diesemProgramm wird \ auftauchen. Es wird auch nirgendwo &#; auftauchen. Es wird %C auftauchen. Und das steht bereits auf Seite 1 dieses Threads.

Original von Amin Negm-Awad
...

Lieber Amin. Ich habe nicht behauptet, es "besser" zu wissen. Ich habe gefragt bzw. vorgeschlagen, dass u.U. auch eine \101 Notation zum
gewuenschten Ziel fuehren kann. Das nicht funktioniert ist mir klar und Du beleidigst meine Intelligenz mit dieser Behauptung.
Die Escape-Notation hatte ich fuer den Fall gedacht, dass alle Zeichen vorher konstant und bekannt sinid, wie in meinem Beispiel etwas weiter oben. Arithmetik auf Unicode-Zeichen hatte ich nicht vermutet; wer soetwas will, kommt natuerlich mit dem Escapen nicht weiter.

Habe einen Algorithmus der asiatische Schriftzeichen produziert, er generiert unicode in folgender Form : བ་

Ich sehe da keinen Interpretationsspielraum. Generiert heißt für mich generiert.

Übrigens hast du das hier geschrieben:

Ich habe versucht, mich der Diskussion anzuschliessen. Ich denke, für das ursprüngliche Problem, &#...; in ein Unicode-String umzuwandeln gibt es nur die eine, bereits genannte Lösung.

Es gab nie ein Problem, &# in einen Unicode-String umzuwandeln. Das war einfalscher Ansatz. Das &# war bereits das Problem. Auch dies steht bereits alles auf Seite 1 dieses Threads, den du offenkundig nicht gelesen hast.

Aber vielleicht machst du dir jetzt noch einmal die Mühe, den OP zu lesen und dann hier deine \x-Lösung zu posten.

Original von Amin Negm-Awad
Aber vielleicht machst du dir jetzt noch einmal die Mühe, den OP zu lesen und dann hier deine \x-Lösung zu posten.

Das fuehrt hier doch alles zu nichts... plonk.

Original von zermelo

Original von Amin Negm-Awad
Aber vielleicht machst du dir jetzt noch einmal die Mühe, den OP zu lesen und dann hier deine \x-Lösung zu posten.

Das fuehrt hier doch alles zu nichts... plonk.

Ah, bei dem Vorschlag, doch einfach mal den Code zu zeigen, wird die Diskussion abgebrochen.

Original von Amin Negm-Awad
Ja, das funktioniert. Und wenn du mal auf Seite 1 dieses Threads schaust, siehst du, dass diese Lösung bereits in den erstenAntworten von mir stand und in der ersten Antwort von macmoonshine. Da hast du dich noch gar nicht an der Diskussion beteiligt, auch zermelo nicht. Der wusste es dann nur besser, *nachdem* bereits die Lösung im Thread stand. *Er* wollte dann mit \x arbeiten.

Ich kenne die ersten Seiten dieses Threads. Sowohl in der Brettansicht als auch in der Baumansicht.
Das war auch gar nicht mein Verständnisproblem.

Original von Amin Negm-Awad

Original von Lucas de Vil
Ich verstehe nicht, wie der OP eine Zeichenkette erzeugen konnte, ohne dass diese Ersetzung durchgeführt wurde. Ich vermute, dass das für zermelo auch ein Rätsel ist.

Du weit nicht, wie man einen String mit Zahlen erzeugt? Soooo schwer ist das ja nun nicht.

Okay, gut, unglücklich ausgedrückt.
Ich besitze schon das Grundverständnis, um mittels Escape-Sequenzen Zeichenketten zu erzeugen, die wie "\xDE\xAD" dargestellt werden.
@"\\xDE\\xAD" zum Beispiel.

Mein Unverständnis bezieht sich nicht auf die Art der Durchführung, sondern auf die Intention der Durchführung. Mir ist nicht klar, welchen Grund er dafür hat.

Original von Amin Negm-Awad
Übrigens ist es auch gleichgültig, wie er es geschafft hat, er hat es geschafft. Das stand bereits im OP, also lange bevor du oder zermelo an der Diskussion teilnahmen.

Wegen oben genanntem Unverständnis, dass der Algorithmus Zeichenketten zurückgibt, die einfach so als "&#F45" dargestellt werden, fehlte mir die Information, dass er es geschafft hat, einen Algorithmus zu kreieren, der einfach so als String "&#F45" zurückgibt.
Ich ging davon aus, der zurückgegebene String interpretiere &#F45, habe aber keinen Gedanken daran verschwendet, dass er diesen tatsächlich darstellt.

Original von Amin Negm-Awad

Original von Lucas de Vil
Offenbar scheint es für den OP aber völlig logisch, dass die von seinem Algorithmus zurückgegebene Zeichenkette dargestellt "\xDE\xAD" lautet.

Und hier fehlt mir die Vorstellungskraft, wie so etwas passieren kann.
(außer, man arbeitet mit Dingen wie [NSString stringWithFormat:@"%c%d", '\\', 65];, aber das ist dann ja schon mutwillig.)

Wieso ist das unverständlich?

Er dachte sich, dass der String auf &#x lauten muss, damit er dann entsprechend interpretiert wird. Also macht er sich so einen String. Mutmaßlich so etwas wie in diese Richtung:
[NSString stingWithFormat:@"&#x%X;", myCode ];

Das wäre dann aber mutwillig. Damit rechne ich doch nicht.

Original von Amin Negm-Awad
zermelo machte daraus sinngemäß folgende Erzeugung:
[NSString stingWithFormat:@"\\%d;", myCode ];

Wat? Wo?
zermelo hat es die ganze Zeit hard codiert.
Von so einem Blödsinn, auch sinngemäß, kann ich nichts in seinen Beiträgen erkennen.

Ich spreche dir nicht das Verständnis für C ab. Das hast du gelernt.

zermelo und auch du haben in einem Thread, der von der Generierung von Zeichen sprach – dich hatte ich sogar noch einmal extra auf der ersten Seite darauf hingewiesen – von \x gesprochen. ich weiß nicht, ob das hart kodiert sein soll. Dagegen spricht, dass es in diesem Thread nicht darum geht, etwas hart zu kodieren, sondern zu generieren. Deshalb vermute ich auch nicht, dass es hart kodiert sein soll, sondern generiert. Weil: Davon handelte der gesamte Thread ohne Ausnahme.